Nederlands
Menu

Basis van cloud en containers

Bij een webapplicatie op Kubernetes is de controle van de liveness-probe zo gemaakt dat ze ook nagaat of de applicatie verbinding kan maken met de database waarvan ze afhangt. Welk probleem is met deze instelling het meest waarschijnlijk?

  1. AAls de database stopt, worden de Pods automatisch verplaatst naar de node waarop de database draait, waardoor de andere applicaties op die node trager worden
  2. BEen korte storing van de database laat de containers van alle Pods herhaaldelijk herstarten, waardoor het herstel ook na de terugkeer van de database wordt vertraagd
  3. CAls de liveness-probe faalt, wordt de Pod alleen uit de doelen van de Service gehaald; er ontstaat dus geen bijzonder probleem
Antwoord en toelichting tonen

Antwoord: B. Een korte storing van de database laat de containers van alle Pods herhaaldelijk herstarten, waardoor het herstel ook na de terugkeer van de database wordt vertraagd

Een liveness-probe is er om een container die zelf niet meer reageert (bijvoorbeeld door een deadlock), te herstellen door hem te herstarten. Als ze ook een afhankelijkheid controleert, falen bij het stoppen van de database de liveness-probes van alle Pods en worden de containers steeds opnieuw herstart, hoewel herstarten niets oplost. Tijdens het herstarten worden geen aanvragen verwerkt, en de wachttijd tot de volgende herstart kan bij herhaalde herstarts groeien; het herstel wordt dus ook na de terugkeer van de database vertraagd. Een liveness-probe hoort alleen te controleren of het proces zelf kan antwoorden, en de toestand van afhankelijkheden wordt zo nodig met readiness-probes of met de foutafhandeling van de applicatie behandeld.

Dit onderwerp oefenen Naar de onderwerppagina

Meer vragen over Basis van cloud en containers

  1. Een Kubernetes-HorizontalPodAutoscaler heeft een doel voor het CPU-gebruik van de Pods van 70% en een bereik van 1 tot 10 Pods. Op dit moment is het gemiddelde CPU-gebruik van 5 Pods 30%. Als het benodigde aantal Pods wordt berekend als ⌈huidig aantal × huidig gebruik ÷ doelgebruik⌉ (⌈ ⌉ betekent naar boven afronden), hoeveel Pods zijn er dan nodig?
  2. In een Deployment waarvan de containers van de Pods de bovenstaande instellingen hebben, draaien vier Pods die elk 400m (0,4 cores) CPU gebruiken. Het doel voor het CPU-gebruik van de HorizontalPodAutoscaler is 60%, en het benodigde aantal Pods wordt berekend als ⌈huidig aantal × huidig gebruik ÷ doelgebruik⌉. Hoeveel Pods zijn er nodig?
  3. Welke beschrijving van de requests en limits voor resources die in Kubernetes voor een container worden ingesteld, is juist?
  4. Een node heeft als toewijsbare resources 4 CPU-cores en 8 GiB geheugen. Voor de container van elke Pod zijn als requests 500m CPU en 1,5 GiB geheugen en als limits 1 CPU-core en 2 GiB geheugen ingesteld. Er zijn geen andere Pods en geen reserveringen voor het systeem. Hoeveel Pods kunnen er maximaal op deze node worden geplaatst?
  5. Er wordt een beheerde databasedienst in de cloud gebruikt (een dienst waarbij de aanbieder de databasesoftware beheert). Wat blijft volgens het model van gedeelde verantwoordelijkheid in het algemeen de verantwoordelijkheid van de gebruiker?