{"id":39016,"date":"2019-10-31T22:27:21","date_gmt":"2019-10-31T19:27:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google\/"},"modified":"2019-10-31T22:27:21","modified_gmt":"2019-10-31T19:27:21","slug":"7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google","title":{"rendered":"7 beste praktijken voor containerbeheer volgens Google","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Opmerking vertaler.<\/b>: De auteur van het originele artikel is Th\u00e9o 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<\/a><\/noindex>\u00bb. 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?<\/i><\/p>\n

\"7<\/a><\/noindex><\/p>\n

Kubernetes Engine<\/a><\/noindex> (een op Kubernetes gebaseerde service voor het uitvoeren van containerized applicaties in Google Cloud \u2014 opmerking van de vertaler.<\/b>)<\/i> \u2014 is een van de beste manieren om workloads te draaien die schaling vereisen. Kubernetes<\/a><\/noindex> 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.<\/p>\n

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<\/a><\/noindex>, alsook onze eerder gepubliceerde post<\/a><\/noindex> over het bouwen van containers.<\/p>\n

1. Gebruik de ingebouwde mechanismen van containers voor logging<\/h2>\n

\nAls 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<\/a><\/noindex>. (Opmerking vertaler.<\/b>: En als je een eigen installatie van Kubernetes gebruikt, raden we onze Open Source-oplossing aan \u2014 loghouse<\/a><\/noindex>.)<\/i> Vercompliceer je leven niet en gebruik de ingebouwde logging mechanismen van containers. Schrijf logs naar stdout en stderr \u2014 ze worden automatisch ontvangen, opgeslagen en ge\u00efndexeerd.<\/p>\n

Indien gewenst kun je ook logs schrijven naar het JSON-formaat.<\/a><\/noindex>. 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.<\/p>\n

2. Zorg ervoor dat containers stateless en immutable zijn<\/h2>\n

\nVoor 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\u00ebren en te vernietigen waar en wanneer dat nodig is.<\/p>\n

Stateless<\/i> 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<\/a><\/noindex>, Persistent Disks<\/a><\/noindex>, Redis<\/a><\/noindex>, Cloud SQL<\/a><\/noindex> of andere beheerde databases. (Opmerking vertaler.<\/b>: Lees hier meer over in ons artikel \"Operators voor Kubernetes: hoe stateful applicaties te draaien<\/a><\/noindex>\u00bb.)<\/i><\/p>\n

Immutable<\/i> 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 \u2014 in de Secrets<\/a><\/noindex> en ConfigMaps<\/a><\/noindex>. 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<\/a><\/noindex>. (Opmerking vertaler.<\/b>: Hiervoor gebruiken we de open-source tool dapp<\/a><\/noindex>.)<\/i><\/p>\n

\"7
\nVoorbeeld van het bijwerken van de configuratie van een Deployment in Kubernetes met behulp van ConfigMap, gemonteerd in pods als configuratie.<\/i><\/p>\n

3. Vermijd het gebruik van privileged containers<\/h2>\n

\nJe runt je applicaties niet onder root op je servers, toch? Als een aanvaller in de applicatie doordringt, krijgt hij toegang met root-rechten. Diezelfde overwegingen gelden ook voor het niet draaien van geprivilegieerde containers. Als je instellingen op de host moet aanpassen, kun je specifieke rechten aan de container geven. capabilities<\/i> toekennen via de optie securityContext<\/code><\/a><\/noindex> in Kubernetes. Als het nodig is om sysctls<\/i>, heeft Kubernetes een speciale annotatie<\/a><\/noindex> hiervoor. Probeer in het algemeen zoveel mogelijk gebruik te maken van init-<\/a><\/noindex> en sidecar-containers voor dergelijke privileged operaties. Ze hebben geen beschikbaarheid nodig voor interne of externe verkeer.<\/p>\n

Als je een cluster beheert, kun je gebruik maken van Pod Security Policy<\/a><\/noindex> voor beperkingen op het gebruik van privileged containers.<\/p>\n

4. Vermijd het draaien onder root<\/h2>\n

\nOver geprivilegieerde containers is al gesproken, maar het zou nog beter zijn als je bovendien geen applicaties onder root binnen de container draait. Als een aanvaller een remote vulnerability met root-rechten in de applicatie vindt, kan hij via een nog onbekende kwetsbaarheid uit de container ontsnappen en root-toegang op de host krijgen.<\/p>\n

De beste manier om dit te voorkomen is om in de eerste plaats niets onder root uit te voeren. Hiervoor kun je gebruikmaken van de directive. USER<\/code> in Dockerfile<\/code> of runAsUser<\/code> in Kubernetes gebruiken. De clusterbeheerder kan ook geforceerd gedrag instellen met behulp van Pod Security Policy<\/a><\/noindex>.<\/p>\n

5. Maak de applicatie eenvoudig te monitoren<\/h2>\n

\nNet als logging is monitoring een essentieel onderdeel van het beheren van de applicatie. Een populaire oplossing voor monitoring in de Kubernetes-gemeenschap is Prometheus<\/a><\/noindex> \u2014 een systeem dat automatisch pods en services ontdekt die monitoring vereisen. (Opmerking vertaler.<\/b>: Zie ook ons gedetailleerd verslag<\/a><\/noindex> over monitoring met Prometheus en Kubernetes.)<\/i> Stackdriver<\/a><\/noindex> kan Kubernetes-clusters monitoren en bevat zijn eigen versie van Prometheus voor het monitoren van applicaties.<\/p>\n

\"7
\nHet Kubernetes-monitoringpaneel in Stackdriver<\/i><\/p>\n

Prometheus verwacht dat de applicatie metrics doorgeeft via een HTTP endpoint. Hiervoor zijn er Prometheus clientbibliotheken<\/a><\/noindex>. Een vergelijkbaar formaat wordt gebruikt door andere tools zoals OpenCensus<\/a><\/noindex> en Istio<\/a><\/noindex>.<\/p>\n

6. Maak de applicatiestatus beschikbaar<\/h2>\n

\nHet 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)<\/i>. Kubernetes heeft twee soorten: liveness en readiness probes<\/a><\/noindex>.<\/p>\n

Voor liveness probe (levensvatbaarheid controle)<\/i> 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)<\/i> De applicatie moet een andere HTTP endpoint hebben die '200 OK' retourneert als de applicatie gezond is, de initialisatie-stappen zijn uitgevoerd en elke correcte aanvraag geen fout oplevert. Kubernetes zal het verkeer naar de container alleen omleiden als de applicatie in overeenstemming met deze controles klaar is. Twee endpoints kunnen worden samengevoegd als er geen verschil is tussen de levensvatbaarheid (liveness) en gereedheid (readiness) toestanden.<\/p>\n

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<\/a><\/noindex>\u00bb.<\/p>\n

7. Kies zorgvuldig de versie van het image<\/h2>\n

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

Je kunt de tag X.Y.Z<\/code> 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<\/code>, 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.<\/p>\n

P.S. van de vertaler<\/h2>\n

\nLees ook op onze blog:<\/p>\n