🥇7 bästa metoder för containeranvändning enligt Google

Obs. övers.: Författaren till den ursprungliga artikeln är Théo Chamley, arkitekt för molnlösningar på Google. I denna publikation för Google Clouds blogg presenterade han en kort sammanfattning av en mer detaljerad guide från hans företag, kallad "Best Practices for Operating Containers». I den har Googles experter sammanställt bästa praxis för drift av containrar i samband med användningen av Google Kubernetes Engine och mer, berörande ett brett spektrum av ämnen: från säkerhet till övervakning och loggning. Så, vilka metoder anser Google vara de viktigaste för arbete med containrar?

Kubernetes Engine (Kubernetes-baserad tjänst för att köra containeriserade tillämpningar i Google Cloud — anm. övers.) — är ett av de bästa sätten att köra arbetsbelastningar som kräver skalning. Kubernetes Det kommer att säkerställa smidig funktion av de flesta applikationer, förutsatt att de är containeriserade. Men om du vill att applikationen ska vara lätt att hantera och vill dra nytta av alla fördelar med Kubernetes, måste du följa bästa praxis. Dessa kommer att förenkla driften av applikationen, dess övervakning och felsökning, samt öka säkerheten.

I denna artikel kommer vi att gå igenom vad man bör veta och göra för att säkerställa effektiv funktion av containrar i Kubernetes. För den som vill fördjupa sig i detaljerna rekommenderar vi att läsa materialet Best Practices for Operating Containers, samt ta en titt på vårt tidigare inlägg om container-byggande.

1. Använd inbyggda mekanismer för containrar för loggning

Om applikationen körs i en Kubernetes-kluster, behövs det inte så mycket för loggarna. Ett centralt loggningssystem är troligtvis redan inbyggt i den använda klustern. Vid användning av Kubernetes Engine ansvarar Stackdriver Logging. (Obs. övers.: Och vid användning av en egen installation av Kubernetes rekommenderar vi att du kollar in vår Open Source-lösning — loghouse.) Komplikera inte ditt liv och använd inbyggda mekanismer för loggning av containrar. Skriv loggar till stdout och stderr — de kommer automatiskt att hämtas, sparas och indexeras.

Om du vill kan du också skriva loggar till JSON-format.. Denna metod gör det enkelt att lägga till metadata. Och tillsammans med dem kommer Stackdriver Logging att möjliggöra sökning i loggarna med hjälp av dessa metadata.

2. Se till att containrarna är stateless och immutabla

För att containrar i ett Kubernetes-kluster ska fungera korrekt måste de vara stateless och immutable. När dessa villkor är uppfyllda kan Kubernetes utföra sitt arbete genom att skapa och förstöra applikationsenheter när och där det behövs.

Stateless betyder att allt tillstånd (permanenta data av något slag) lagras utanför containern. För detta ändamål kan olika typer av externa lagringslösningar användas beroende på behov: Cloud Storage, Persistent Disks, Redis, Cloud SQL eller andra hanterade databaser. (Obs. övers.: Läs mer om detta i vår artikel "Operatörer för Kubernetes: hur man kör stateful-applikationer».)

Immutable betyder att containern inte kommer att modifieras under sin livslängd: inga uppdateringar, patchar eller ändringar i konfigurationen. Om du behöver uppdatera applikationens kod eller applicera en patch, skapa en ny bild och distribuera den. Det rekommenderas att flytta containerns konfiguration (port för lyssning, körmiljöalternativ, osv.) utanför — till Secrets och ConfigMaps. Dessa kan uppdateras utan att behöva bygga en ny containerbild. För att enkelt skapa pipeline för bildbyggande kan man använda Cloud Build. (Obs. övers.: Vi använder ett Open Source-verktyg för dessa ändamål dapp.)

Exempel på att uppdatera en Deployment-konfiguration i Kubernetes med hjälp av en ConfigMap som är monterad i pods som konfiguration

3. Undvik privilegierade containrar

Du kör väl inte applikationer under root på dina servrar, eller hur? Om en angripare kommer in i applikationen får de åtkomst med root-rättigheter. Detsamma gäller för att inte köra privilegierade containrar. Om det krävs att ändra inställningar på värden kan man ge containern specifika capabilities med alternativet securityContext i Kubernetes. Om det krävs att ändra sysctls, har Kubernetes en separat annotation för detta. Överlag, försök att maximalt utnyttja init- och sidecar-containrar för att utföra sådana privilegierade operationer. De behöver inte vara tillgängliga för varken intern eller extern trafik.

Om du administrerar en kluster kan du använda Pod Security Policy för begränsningar i tillämpningen av privilegierade containrar.

4. Undvik att köra som root

Det har redan sagts mycket om privilegierade containrar, men det blir ännu bättre om du dessutom undviker att köra applikationer under root i containern. Om en angripare hittar en fjärrsårbarhet med kodexekvering i en applikation som körs med root-rättigheter och därmed lyckas ta sig utanför containern genom en ännu okänd sårbarhet, kan de få root-åtkomst till värden.

Det bästa sättet att undvika detta är att inte köra något under root från första början. För detta kan du använda direktivet USER på Dockerfile eller runAsUser i Kubernetes. Klusteradministratören kan också konfigurera tvångsbeteende med hjälp av Pod Security Policy.

5. Gör applikationen lätt övervakad

Precis som loggning är övervakning en oumbärlig del av applikationshantering. En populär lösning för övervakning i Kubernetes-gemenskapen är Prometheus — ett system som automatiskt upptäcker pods och tjänster som behöver övervakas. (Obs. övers.: Se även vår detaljerade rapport om ämnet övervakning med Prometheus och Kubernetes.) Stackdriver kan övervaka Kubernetes-kluster och inkluderar sin egen version av Prometheus för applikationsövervakning.

Kubernetes övervakningspanel i Stackdriver

Prometheus förväntar sig att applikationen exponerar metrik på en HTTP-endpoint. För detta finns tillgängliga Prometheus klientbibliotek. Ett liknande format används av andra verktyg som OpenCensus och Istio.

6. Gör applikationens hälsotillstånd tillgängligt

Hantera en applikation i produktion underlättas av dess förmåga att rapportera sitt tillstånd till hela systemet. Är applikationen igång? Är den i ordning? Är den redo att ta emot trafik? Hur beter den sig? Den vanligaste lösningen för detta problem är att implementera hälsokontroller (health checks). Kubernetes har två typer av dessa: liveness och readiness probes.

För liveness probe (livsräknare) måste applikationen ha en HTTP-endpoint som returnerar svaret '200 OK' om den fungerar och dess grundläggande beroenden är tillfredsställda. För readiness probe (beredskapskontroll) Applikationen måste ha en annan HTTP-endpoint som returnerar svaret "200 OK" om applikationen är i ett friskt tillstånd, initialiseringsstegen har genomförts och alla korrekta förfrågningar inte leder till ett fel. Kubernetes kommer att dirigera trafik till containern endast när applikationen är redo enligt dessa kontroller. Två endpoints kan slås samman om det inte finns någon skillnad mellan livbarhet (liveness) och beredskap (readiness) tillstånd.

Mer om detta kan läsas i den relevanta artikeln av Sandeep Dinesh, Developer Advocate från Google: "Kubernetes bästa metoder: Ställa in hälsokontroller med beredskaps- och livbarhetsprober».

7. Var noga med att välja rätt bildversion

De flesta offentliga och privata bilder använder ett taggningssystem som liknar det som beskrivs i Best Practices for Building Containers. Om bilden tillämpar ett system som liknar semantisk versionering, måste man ta hänsyn till specifiken i taggningen. Till exempel kan taggen latest ofta flyttas från bild till bild - man kan inte förlita sig på den om man behöver förutsägbara och reproducerbara byggnader och installationer.

Du kan använda taggen X.Y.Z (de är nästan alltid oförändrade), men i så fall, håll koll på alla patchar och uppdateringar av bilden. Om den använda bilden har taggen X.Y, är det ett bra kompromissalternativ. Genom att välja det får du automatiskt patchar och förlitar dig samtidigt på en stabil version av applikationen.