🥇7 beste praktijken voor het beheer van containers volgens Google

Opmerking vertaler.: De auteur van het originele artikel is Théo Chamley, cloud solutions architect bij Google. In deze blogpost voor Google Cloud presenteert hij een korte samenvatting van een gedetailleerde handleiding van zijn bedrijf, getiteld "Best Practices for Operating Containers». Hierin hebben Google-experts de beste praktijken voor het beheren van containers verzameld in de context van het gebruik van Google Kubernetes Engine en meer, met een breed scala aan onderwerpen van veiligheid tot monitoring en logging. Wat zijn volgens Google de belangrijkste praktijken bij het werken met containers?

Kubernetes Engine (een op Kubernetes gebaseerde service voor het uitvoeren van containerized applicaties in Google Cloud — opmerking van de vertaler.) — is een van de beste manieren om workloads te draaien die schaling vereisen. Kubernetes Het zorgt voor een probleemloze werking van de meeste applicaties, mits ze containerized zijn. Maar als je wilt dat de applicatie gemakkelijk te beheren is en je wilt profiteren van alle voordelen van Kubernetes, moet je de beste praktijken volgen. Deze vergemakkelijken het beheer van de applicatie, de monitoring en debugging, en verhogen ook de veiligheid.

In dit artikel bespreken we de lijst met wat je moet weten en doen voor een effectieve werking van containers in Kubernetes. Voor diegenen die dieper op de details willen ingaan, is het aan te raden om het materiaal Best Practices for Operating Containers, alsook onze eerder gepubliceerde post over het bouwen van containers.

1. Gebruik de ingebouwde mechanismen van containers voor logging

Als de applicatie draait in een Kubernetes-cluster, is er niet veel nodig voor logs. Een gecentraliseerd logging systeem is waarschijnlijk al ingebouwd in het gebruikte cluster. In het geval van Kubernetes Engine is dit verantwoordelijk voor Stackdriver Logging. (Opmerking vertaler.: En als je een eigen installatie van Kubernetes gebruikt, raden we onze Open Source-oplossing aan — loghouse.) Vercompliceer je leven niet en gebruik de ingebouwde logging mechanismen van containers. Schrijf logs naar stdout en stderr — ze worden automatisch ontvangen, opgeslagen en geïndexeerd.

Indien gewenst kun je ook logs schrijven naar het JSON-formaat.. Deze aanpak maakt het gemakkelijk om metadata toe te voegen. Samen met deze metadata komt in Stackdriver Logging de mogelijkheid om logs te doorzoeken met behulp van deze metadata.

2. Zorg ervoor dat containers stateless en immutable zijn

Voor een correcte werking van containers in een Kubernetes-cluster moeten ze stateless en immutable zijn. Wanneer aan deze voorwaarden is voldaan, kan Kubernetes zijn werk doen door applicatie-entities te creëren en te vernietigen waar en wanneer dat nodig is.

Stateless betekent dat elke staat (doorlopende gegevens van welke aard dan ook) buiten de container wordt opgeslagen. Hiervoor kunnen, afhankelijk van de behoeften, verschillende soorten externe opslag worden gebruikt: Cloud Storage, Persistent Disks, Redis, Cloud SQL of andere beheerde databases. (Opmerking vertaler.: Lees hier meer over in ons artikel "Operators voor Kubernetes: hoe stateful applicaties te draaien».)

Immutable betekent dat de container tijdens zijn levenscyclus niet zal worden gemodificeerd: geen updates, patches of configuratiewijzigingen. Als je de applicatiecode of een patch wilt bijwerken, maak dan een nieuw beeld en implementeer het. Het is aan te raden om de configuratie van de container (poort om naar te luisteren, opties voor de uitvoeringsomgeving, enz.) extern te houden — in de Secrets en ConfigMaps. Deze kunnen worden bijgewerkt zonder dat het nodig is om een nieuw containerbeeld te bouwen. Voor het eenvoudig maken van pipelines voor het bouwen van beelden kan je gebruiken maken van Cloud Build. (Opmerking vertaler.: Hiervoor gebruiken we de open-source tool dapp.)

Voorbeeld van het bijwerken van de configuratie van een Deployment in Kubernetes met behulp van ConfigMap, gemonteerd in pods als configuratie.

3. Vermijd het gebruik van privileged containers

Je draait geen applicaties onder root op je servers, toch? Als een kwaadwillende toegang krijgt tot de applicatie, heeft hij root-rechten. Dezelfde overwegingen gelden om geen privileged containers te draaien. Als het nodig is om instellingen op de host te wijzigen, kan je de container specifieke capabilities toekennen via de optie securityContext in Kubernetes. Als het nodig is om sysctls, heeft Kubernetes een speciale annotatie hiervoor. Probeer in het algemeen zoveel mogelijk gebruik te maken van init- en sidecar-containers voor dergelijke privileged operaties. Ze hebben geen beschikbaarheid nodig voor interne of externe verkeer.

Als je een cluster beheert, kun je gebruik maken van Pod Security Policy voor beperkingen op het gebruik van privileged containers.

4. Vermijd het draaien onder root

Er is al gesproken over privileged containers, maar het zou nog beter zijn als je ervoor zorgt dat je geen applicaties onder root draait binnen de container. Als een aanvaller een externe kwetsbaarheid met code-uitvoering vindt in een applicatie met root-rechten, en vervolgens de container kan verlaten via een nog onbekende kwetsbaarheid, krijgt hij root-toegang op de host.

De beste manier om dit te voorkomen is om niets onder root te draaien. Hiervoor kun je de directive USER in Dockerfile of runAsUser in Kubernetes gebruiken. De clusterbeheerder kan ook geforceerd gedrag instellen met behulp van Pod Security Policy.

5. Maak de applicatie eenvoudig te monitoren

Net als logging is monitoring een essentieel onderdeel van het beheren van de applicatie. Een populaire oplossing voor monitoring in de Kubernetes-gemeenschap is Prometheus — een systeem dat automatisch pods en services ontdekt die monitoring vereisen. (Opmerking vertaler.: Zie ook ons gedetailleerd verslag over monitoring met Prometheus en Kubernetes.) Stackdriver kan Kubernetes-clusters monitoren en bevat zijn eigen versie van Prometheus voor het monitoren van applicaties.

Het Kubernetes-monitoringpaneel in Stackdriver

Prometheus verwacht dat de applicatie metrics doorgeeft via een HTTP endpoint. Hiervoor zijn er Prometheus clientbibliotheken. Een vergelijkbaar formaat wordt gebruikt door andere tools zoals OpenCensus en Istio.

6. Maak de applicatiestatus beschikbaar

Het beheren van een productie-applicatie helpt door aan de hele systeem te rapporteren over zijn status. Is de applicatie actief? Is alles in orde? Is het klaar om verkeer te ontvangen? Hoe presteert het? De meest voorkomende manier om dit probleem aan te pakken is door health checks (gezondheidscontroles). Kubernetes heeft twee soorten: liveness en readiness probes.

Voor liveness probe (levensvatbaarheid controle) moet de applicatie een HTTP endpoint hebben dat een "200 OK"-antwoord retourneert als het functioneert en zijn belangrijkste afhankelijkheden zijn voldaan. Voor readiness probe (gereedheid controle) De applicatie moet een andere HTTP-eindpunt hebben die een "200 OK"-antwoord teruggeeft als de applicatie gezond is, de initialisatiestappen zijn uitgevoerd en elk geldig verzoek geen fout oplevert. Kubernetes zal verkeer naar de container alleen doorsturen wanneer de applicatie klaar is volgens deze controles. Twee eindpunten kunnen worden samengevoegd als er geen verschil is tussen de liveness- en readiness-statussen.

Meer hierover is te lezen in het bijbehorende artikel van Sandeep Dinesh, Developer Advocate bij Google: "Kubernetes best practices: Het instellen van gezondheidschecks met readiness- en liveness-probes».

7. Kies zorgvuldig de versie van het image

De meeste publieke en private images gebruiken een tagging-systeem dat lijkt op dat in Best Practices for Building Containers. Als het image een systeem toepast dat lijkt op semantische versiebeheer, moet je rekening houden met de specifieke tagging. Bijvoorbeeld, de tag latest kan vaak van image naar image verplaatst worden — je kunt er niet op vertrouwen als je voorspelbare en reproduceerbare builds en installaties nodig hebt.

Je kunt de tag X.Y.Z gebruiken (ze zijn bijna altijd onveranderlijk), maar houd in dat geval alle patches en updates van het image in de gaten. Als het gebruikte image een tag heeft van X.Y, is dit een goede middenweg. Door deze te kiezen, krijg je automatisch patches en baseer je je tegelijkertijd op een stabiele versie van de applicatie.