🥇7 bedste praksisser for containerudnyttelse ifølge Google

Bem. overs.: Forfatteren af den originale artikel er Théo Chamley, cloud-løsningarkitekt hos Google. I dette blogindlæg for Google Cloud præsenterede han et kort resumé af en mere detaljeret vejledning fra hans virksomhed, kaldet "Bedste praksis for drift af containere». I den har Google-specialister samlet de bedste praksisser for drift af containere i konteksten af brugen af Google Kubernetes Engine og mere, berørt et bredt spektrum af emner: fra sikkerhed til overvågning og logføring. Så hvilke praksisser i arbejdet med containere er mest vigtige ifølge Google?

Kubernetes Engine (en Kubernetes-baseret service til at køre containeriserede applikationer i Google Cloud — ft. overs.) — er en af de bedste måder at køre arbejdsbyrder, der har brug for skalering. Kubernetes vil sikre problemfri drift for de fleste applikationer, hvis de er containeriserede. Men hvis du ønsker, at applikationen skal være nem at administrere og ønsker at drage fordel af alle fordelene ved Kubernetes, er det nødvendigt at følge bedste praksis. De vil forenkle driften af applikationen, dens overvågning og fejlfinding samt øge sikkerheden.

I denne artikel gennemgår vi listen over det, du bør vide og gøre for effektiv drift af containere i Kubernetes. For dem, der ønsker at dykke ned i detaljerne, er det værd at læse materialet Bedste praksis for drift af containere, samt tage et kig på vores tidligere indlæg om bygning af containere.

1. Brug indfødte mekanismer til containerlogføring

Hvis applikationen kører i et Kubernetes-kluster, kræves der ikke meget til logs. Et centraliseret logføringssystem er sandsynligvis allerede indbygget i det anvendte kluster. I tilfælde af brug af Kubernetes Engine varetages dette af Stackdriver Logging. (Bem. overs.: Ved brug af en egen installation af Kubernetes anbefaler vi at se nærmere på vores Open Source-løsning — loghouse.) Gør ikke livet sværere for dig selv og brug de indfødte mekanismer til containerlogføring. Skriv logs til stdout og stderr — de vil automatisk blive opsamlet, gemt og indekseret.

Hvis ønskes, kan du også skrive logs til JSON-format. Denne tilgang vil gøre det nemt at tilføje metadata. Sammen med dem vil der i Stackdriver Logging være mulighed for at søge i logs ved hjælp af disse metadata.

2. Sørg for at containerne er stateless og immutable

For the correct functioning of containers in a Kubernetes cluster, they must be stateless and immutable. When these conditions are met, Kubernetes will be able to perform its tasks by creating and destroying application entities as needed.

Stateless means that any state (permanent data of any kind) is stored outside the container. For this purpose, depending on needs, different types of external storage can be employed: Cloud Storage, Persistent Disks, Redis, Cloud SQL or other managed databases. (Bem. overs.: You can read more about this in our article “Operatorer til Kubernetes: hvordan man kører stateful-applikationer.».)

Immutable means that the container will not be modified during its lifetime: no updates, patches, or configuration changes. If you need to update the application code or apply a patch, create a new image and deploy it. It is recommended to move container configuration (listening port, execution environment options, etc.) outside to Secrets og ConfigMaps. They can be updated without the need to build a new container image. For simple image building pipelines, you can use Cloud Build. (Bem. overs.: We use the open-source tool dapp.)

Example of updating Deployment configuration in Kubernetes using a ConfigMap mounted in pods as config.

3. Avoid privileged containers

You don’t run applications as root on your servers, right? If an attacker gains access to the application, they will have root privileges. The same considerations apply to not running privileged containers. If you need to change settings on the host, you can give the container specific capabilities using the option securityContext in Kubernetes. If you need to change sysctls, Kubernetes has a separate annotation for this. In general, try to maximize the use of init- and sidecar containers for performing such privileged operations. They do not require availability for internal or external traffic.

If you administer a cluster, you can use Pod Security Policy for restrictions on the use of privileged containers.

4. Avoid running as root

Der er allerede sagt noget om privilegerede containere, men det vil være endnu bedre, hvis du ikke kører applikationer inden i containeren som root. Hvis en angriber finder en fjern sårbarhed med kodeeksekvering i applikationen med root-rettigheder, og derefter kan forlade containerens rammer gennem en endnu ukendt sårbarhed, vil de få root-adgang på værten.

Den bedste måde at undgå dette på er primært ikke at køre noget som root. Dette kan opnås ved at bruge direktivet USER i Dockerfile eller runAsUser i Kubernetes. Clusteradministratoren kan også konfigurere tvingende adfærd ved hjælp af Pod Security Policy.

5. Gør applikationen let at overvåge

Ligesom logning er overvågning en integreret del af applikationsstyring. En populær løsning til overvågning i Kubernetes-fællesskabet er Prometheus — et system, der automatisk opdager pods og tjenester, der kræver overvågning. (Bem. overs.: Se også vores detaljerede rapport om overvågning ved hjælp af Prometheus og Kubernetes.) Stackdriver kan overvåge Kubernetes-klynger og inkluderer sin egen version af Prometheus til overvågning af applikationer.

Kubernetes-overvågningspanelet i Stackdriver

For at Prometheus kan fungere korrekt, skal applikationen eksponere metrics på et HTTP-endpoint. Der er tilgængelige Prometheus-klientbiblioteker. Det samme format bruges af andre værktøjer som OpenCensus og Istio.

6. Gør applikationens sundhedstilstand tilgængelig

Forvaltningen af en applikation i produktion understøttes af dens evne til at rapportere sin tilstand til hele systemet. Kører applikationen? Er den i orden? Klar til at modtage trafik? Hvordan opfører den sig? Den mest almindelige måde at løse dette problem på er implementeringen af sundhedschecks (health checks). Kubernetes har to typer af dem: liveness og readiness probes.

For liveness probe (livability checks) skal applikationen have et HTTP-endpoint, der returnerer svaret "200 OK", hvis det fungerer, og dets grundlæggende afhængigheder er opfyldt. For readiness probe (service readiness check) Applikationen skal have en anden HTTP-endpoint, der returnerer svaret «200 OK», hvis applikationen er i en sund tilstand, initialiseringstrinene er gennemført, og enhver korrekt anmodning ikke fører til en fejl. Kubernetes vil dirigere trafikken til containeren kun, når applikationen er klar i henhold til disse tjek. De to endpoints kan kombineres, hvis der ikke er nogen forskel mellem livsgyldigheds- (liveness) og klarheds- (readiness) tilstandene.

Læs mere om dette i den relevante artikel af Sandeep Dinesh, Developer Advocate fra Google: «Kubernetes bedste praksis: Opsætning af sundhedstjek med klarheds- og livsgyldighedsprober».

7. Vælg omhyggeligt billedversionen

De fleste offentlige og private billeder bruger et taggingsystem, der ligner det, der er beskrevet i Best Practices for Building Containers. Hvis billedet anvender et system tæt på semantisk versionering, skal der tages hensyn til specifikationen af tagningen. For eksempel kan tagget latest ofte flytte fra billede til billede — det kan ikke stole på, hvis du har brug for forudsigelige og reproducerbare builds og installationer.

Du kan bruge tagget X.Y.Z (de er næsten altid uændrede), men i så fald skal du holde øje med alle patches og opdateringer til billedet. Hvis det anvendte billede har tagget X.Y, er det et godt valg af gylden mellemvej. Ved at vælge det får du automatisk patches og samtidig baserer dig på en stabil version af applikationen.