Merk. overs.: Forfatteren av den originale artikkelen er Théo Chamley, Google Cloud Solutions Architect. I dette innlegget for Google Cloud-bloggen gir han et sammendrag av selskapets mer detaljerte veiledning, kalt "" I den samlet Google-eksperter beste praksis for drift av containere i sammenheng med bruk av Google Kubernetes Engine og mer, og berører et bredt spekter av emner: fra sikkerhet til overvåking og logging. Så hva er de viktigste containerpraksisene ifølge Google?
(Kubernetes-basert tjeneste for å kjøre containeriserte applikasjoner på Google Cloud - ca. oversettelse) er en av de beste måtene å kjøre arbeidsmengder som må skaleres. vil sikre jevn funksjon av de fleste applikasjoner hvis de er containeriserte. Men hvis du vil at applikasjonen din skal være enkel å administrere og vil dra full nytte av Kubernetes, må du følge beste praksis. De vil forenkle driften av applikasjonen, dens overvåking og feilsøking, og også øke sikkerheten.
I denne artikkelen vil vi gå gjennom en liste over ting du bør vite og gjøre for å kjøre containere effektivt på Kubernetes. De som ønsker å gå dypere inn i detaljer bør lese materialet , og også ta hensyn til vår om montering av containere.
1. Bruk innfødte beholderloggingsmekanismer
Hvis applikasjonen kjører på en Kubernetes-klynge, er det ikke mye som trengs for logger. Et sentralisert loggingssystem er sannsynligvis allerede innebygd i klyngen du bruker. Ved bruk av Kubernetes Engine er dette ansvarlig . (Merk. overs.: Og hvis du bruker din egen Kubernetes-installasjon, anbefaler vi å se nærmere på vår åpen kildekode-løsning - .) Hold livet ditt enkelt og bruk innfødte beholderloggingsmekanismer. Skriv logger til stdout og stderr - de vil automatisk mottas, lagres og indekseres.
Om ønskelig kan du også skrive logger til . Denne tilnærmingen vil gjøre det enkelt å legge til metadata til dem. Og med dem vil Stackdriver Logging ha muligheten til å søke gjennom logger ved hjelp av disse metadataene.
2. Sørg for at beholderne er statsløse og uforanderlige
For at beholdere skal fungere riktig i en Kubernetes-klynge, må de være statsløse og uforanderlige. Når disse betingelsene er oppfylt, kan Kubernetes gjøre jobben sin, opprette og ødelegge applikasjonsenheter når og hvor det er nødvendig.
statsløs betyr at enhver tilstand (vedvarende data av noe slag) er lagret utenfor containeren. For dette, avhengig av behov, kan forskjellige typer ekstern lagring brukes: , , , eller andre administrerte databaser. (Merk. overs.: Les mer om dette i vår artikkel "".)
Uforanderlig betyr at beholderen ikke vil bli endret i løpet av levetiden: ingen oppdateringer, patcher, konfigurasjonsendringer. Hvis du trenger å oppdatere applikasjonskoden eller bruke en oppdatering, oppretter du et nytt bilde og distribuerer det. Det anbefales å flytte containerkonfigurasjonen (lytteport, kjøretidsmiljøalternativer osv.) eksternt - til и . De kan oppdateres uten å måtte bygge et nytt beholderbilde. For enkelt å lage rørledninger med bildemontering kan du bruke . (Merk. overs.: Vi bruker et åpen kildekode-verktøy for disse formålene .)
Et eksempel på oppdatering av distribusjonskonfigurasjonen i Kubernetes ved å bruke ConfigMap montert i pods som en konfigurasjon
3. Unngå privilegerte beholdere
Du kjører ikke applikasjoner som root på serverne dine, ikke sant? Hvis en angriper kommer inn i applikasjonen, vil han få root-tilgang. De samme hensynene gjelder for ikke å kjøre privilegerte containere. Hvis du trenger å endre innstillingene på verten, kan du gi beholderen spesifikke evner ved å bruke alternativet i Kubernetes. Hvis du trenger å endre sysctls, har Kubernetes for dette. Generelt, prøv å få mest mulig ut av og sidevognscontainere for å utføre lignende privilegerte operasjoner. De trenger ikke være tilgjengelige for verken intern eller ekstern trafikk.
Hvis du administrerer en klynge, kan du bruke for restriksjoner på bruk av privilegerte containere.
4. Unngå å kjøre som root
Privilegerte containere har allerede vært diskutert, men det vil være enda bedre hvis du i tillegg til dette ikke kjører applikasjoner inne i containeren som root. Hvis en angriper finner en ekstern sårbarhet i en applikasjon med root-rettigheter som tillater kjøring av kode, hvoretter han kan forlate containeren gjennom en foreløpig ukjent sårbarhet, vil han få root på verten.
Den beste måten å unngå dette på er å ikke kjøre noe som root i utgangspunktet. For å gjøre dette kan du bruke direktivet USER в Dockerfile eller runAsUser i Kubernetes. Klyngeadministratoren kan også konfigurere håndhevingsatferden ved å bruke .
5. Gjør applikasjonen enkel å overvåke
I likhet med logging er overvåking en integrert del av applikasjonsadministrasjon. En populær overvåkingsløsning i Kubernetes-fellesskapet er - et system som automatisk oppdager pods og tjenester som krever overvåking. (Merk. overs.: Se også vår om temaet overvåking ved bruk av Prometheus og Kubernetes.) er i stand til å overvåke Kubernetes-klynger og inkluderer sin egen versjon av Prometheus for applikasjonsovervåking.
Kubernetes Dashboard på Stackdriver
Prometheus forventer at applikasjonen videresender beregninger til HTTP-endepunktet. Tilgjengelig for dette . Det samme formatet brukes av andre verktøy som и .
6. Gjør appens helsestatus tilgjengelig
Applikasjonsadministrasjon i produksjon er hjulpet av dens evne til å kommunisere sin tilstand til hele systemet. Kjører applikasjonen? Er det ok? Er du klar til å motta trafikk? Hvordan oppfører han seg? Den vanligste måten å løse dette problemet på er å implementere helsesjekker (helsesjekker). Kubernetes har to typer: .
For liveness-sonde (vitalitetssjekker) applikasjonen må ha et HTTP-endepunkt som returnerer et "200 OK"-svar hvis det er funksjonelt og dets grunnleggende avhengigheter er tilfredsstilt. For beredskapssonde (kontroller av serviceberedskap) applikasjonen må ha et annet HTTP-endepunkt som returnerer et "200 OK"-svar hvis applikasjonen er i en sunn tilstand, initialiseringstrinnene er fullført og enhver gyldig forespørsel ikke resulterer i en feil. Kubernetes vil kun rute trafikk til containeren hvis applikasjonen er klar i henhold til disse kontrollene. To endepunkter kan slås sammen hvis det ikke er forskjell mellom liveness- og beredskapstilstandene.
Du kan lese mer om dette i den relaterte artikkelen fra Sandeep Dinesh, Developer Advocate fra Google: "'.
7. Velg bildeversjon med omhu
De fleste offentlige og private bilder bruker et merkesystem som ligner på det som er beskrevet i . Hvis bildet bruker et system nært , er det nødvendig å ta hensyn til detaljene ved tagging. For eksempel, tag latest kan flytte ofte fra bilde til bilde - kan ikke stole på hvis du trenger forutsigbare og repeterbare bygg og installasjoner.
Du kan bruke taggen X.Y.Z (de er nesten alltid uendret), men i dette tilfellet, hold styr på alle patcher og oppdateringer til bildet. Hvis bildet du bruker har en tag X.Y, dette er et godt alternativ for den gyldne middelvei. Ved å velge det, mottar du automatisk patcher og stoler samtidig på den stabile versjonen av applikasjonen.
PS fra oversetter
Les også på bloggen vår:
- «";
- «";
- «";
- «» (anmeldelse og videorapport);
- «» (anmeldelse og videorapport);
- «» (anmeldelse og videorapport);
- «» (anmeldelse og videorapport);
- «'.
Kilde: www.habr.com