Bemærk. overs.: Forfatteren til den originale artikel er Théo Chamley, Google Cloud Solutions Architect. I dette indlæg til Google Cloud-bloggen giver han et resumé af sin virksomheds mere detaljerede vejledning, kaldet "" I den indsamlede Google-eksperter bedste praksis for betjening af containere i forbindelse med brug af Google Kubernetes Engine og mere, idet de berørte en lang række emner: fra sikkerhed til overvågning og logning. Så hvad er de vigtigste containerpraksis ifølge Google?
(Kubernetes-baseret tjeneste til at køre containeriserede applikationer på Google Cloud - ca. oversættelse) er en af de bedste måder at køre arbejdsbelastninger, der skal skaleres. vil sikre problemfri funktion af de fleste applikationer, hvis de er containeriseret. Men hvis du ønsker, at din applikation skal være nem at administrere og vil drage fuld fordel af Kubernetes, skal du følge bedste praksis. De vil forenkle driften af applikationen, dens overvågning og fejlfinding og øger også sikkerheden.
I denne artikel gennemgår vi en liste over ting, du bør vide og gøre for at køre containere effektivt på Kubernetes. De, der ønsker at gå dybere i detaljer, bør læse materialet , og vær også opmærksom på vores om at samle containere.
1. Brug native containerlogningsmekanismer
Hvis applikationen kører på en Kubernetes-klynge, kræves der ikke meget til logfiler. Et centraliseret logningssystem er sandsynligvis allerede indbygget i den klynge, du bruger. I tilfælde af brug af Kubernetes Engine er dette ansvarligt . (Bemærk. overs.: Og hvis du bruger din egen Kubernetes-installation, anbefaler vi at kigge nærmere på vores Open Source-løsning - .) Hold dit liv enkelt og brug native container-logningsmekanismer. Skriv logs til stdout og stderr - de vil automatisk blive modtaget, gemt og indekseret.
Hvis det ønskes, kan du også skrive logs til . Denne tilgang vil gøre det nemt at tilføje metadata til dem. Og med dem vil Stackdriver Logging have mulighed for at søge gennem logfiler ved hjælp af disse metadata.
2. Sørg for, at beholdere er statsløse og uforanderlige
For at beholdere kan fungere korrekt i en Kubernetes-klynge, skal de være statsløse og uforanderlige. Når først disse betingelser er opfyldt, kan Kubernetes gøre sit arbejde og skabe og ødelægge applikationsenheder, når og hvor det er nødvendigt.
Statsløs betyder, at enhver tilstand (vedvarende data af enhver art) er lagret uden for containeren. Til dette, afhængigt af behov, kan forskellige typer eksternt lager bruges: , , , eller andre administrerede databaser. (Bemærk. overs.: Læs mere om dette i vores artikel ". ")
uforanderlige betyder, at beholderen ikke vil blive ændret i dens levetid: ingen opdateringer, patches, konfigurationsændringer. Hvis du har brug for at opdatere din applikationskode eller anvende en patch, skal du oprette et nyt billede og implementere det. Det anbefales at flytte containerkonfigurationen (lytteport, runtime-miljøindstillinger osv.) eksternt - til и . De kan opdateres uden at skulle bygge et nyt containerbillede. For nemt at skabe pipelines med billedsamling, kan du bruge . (Bemærk. overs.: Vi bruger et Open Source-værktøj til disse formål .)
Et eksempel på opdatering af installationskonfigurationen i Kubernetes ved hjælp af ConfigMap monteret i pods som en konfiguration
3. Undgå privilegerede containere
Du kører ikke applikationer som root på dine servere, vel? Hvis en angriber kommer ind i programmet, vil han få root-adgang. De samme overvejelser gælder for ikke at køre privilegerede containere. Hvis du har brug for at ændre indstillinger på værten, kan du give containeren specifik kapaciteter ved at bruge muligheden i Kubernetes. Hvis du skal skifte sysctls, Kubernetes har for det. Prøv generelt at få mest muligt ud af og sidevognscontainere til at udføre lignende privilegerede operationer. De behøver ikke at være tilgængelige for hverken intern eller ekstern trafik.
Hvis du administrerer en klynge, kan du bruge for begrænsninger i brugen af privilegerede containere.
4. Undgå at køre som root
Privilegerede containere er allerede blevet diskuteret, men det vil være endnu bedre, hvis man udover dette ikke kører applikationer inde i containeren som root. Hvis en angriber finder en ekstern sårbarhed i en applikation med root-rettigheder, der tillader kodeudførelse, hvorefter han er i stand til at forlade containeren gennem en endnu ukendt sårbarhed, vil han få root på værten.
Den bedste måde at undgå dette på er ikke at køre noget som root i første omgang. For at gøre dette kan du bruge direktivet USER в Dockerfile eller runAsUser i Kubernetes. Klyngeadministratoren kan også konfigurere håndhævelsesadfærd vha .
5. Gør applikationen nem at overvåge
Ligesom logning er overvågning en integreret del af applikationsstyring. En populær overvågningsløsning i Kubernetes-fællesskabet er - et system, der automatisk registrerer pods og tjenester, der kræver overvågning. (Bemærk. overs.: Se også vores om emnet overvågning ved hjælp af Prometheus og Kubernetes.) er i stand til at overvåge Kubernetes-klynger og inkluderer sin egen version af Prometheus til applikationsovervågning.
Kubernetes Dashboard på Stackdriver
Prometheus forventer, at applikationen videresender metrics til HTTP-slutpunktet. Tilgængelig til dette . Det samme format bruges af andre værktøjer som f.eks и .
6. Gør appens sundhedsstatus tilgængelig
Applikationsstyring i produktionen er hjulpet af dens evne til at kommunikere sin tilstand til hele systemet. Kører applikationen? Er det i orden? Er du klar til at modtage trafik? Hvordan opfører han sig? Den mest almindelige måde at løse dette problem på er at implementere sundhedstjek (sundhedstjek). Kubernetes har to typer: .
Til liveness-sonde (vitalitetstjek) applikationen skal have et HTTP-slutpunkt, der returnerer et "200 OK"-svar, hvis det er funktionelt, og dets grundlæggende afhængigheder er opfyldt. Til parathedssonde (tjek af serviceberedskab) applikationen skal have et andet HTTP-slutpunkt, der returnerer et "200 OK"-svar, hvis applikationen er i en sund tilstand, initialiseringstrinnene er gennemført, og enhver gyldig anmodning ikke resulterer i en fejl. Kubernetes dirigerer kun trafik til containeren, hvis applikationen er klar i henhold til disse kontroller. To endepunkter kan slås sammen, hvis der ikke er forskel mellem liveness- og parathedstilstandene.
Du kan læse mere om dette i den relaterede artikel fra Sandeep Dinesh, Developer Advocate fra Google: "'.
7. Vælg din billedversion med omhu
De fleste offentlige og private billeder bruger et tagging-system, der ligner det, der er beskrevet i . Hvis billedet bruger et system tæt på , er det nødvendigt at tage højde for de særlige forhold ved tagging. For eksempel tag latest kan flyttes ofte fra billede til billede - kan ikke stoles på, hvis du har brug for forudsigelige og gentagelige builds og installationer.
Du kan bruge mærket X.Y.Z (de er næsten altid uændrede), men i dette tilfælde skal du holde styr på alle patches og opdateringer til billedet. Hvis billedet du bruger har et tag X.Y, dette er en god mulighed for den gyldne middelvej. Ved at vælge det, modtager du automatisk patches og stoler samtidig på den stabile version af applikationen.
PS fra oversætteren
Læs også på vores blog:
- «";
- «";
- «";
- «» (anmeldelse og videorapport);
- «» (anmeldelse og videorapport);
- «» (anmeldelse og videorapport);
- «» (anmeldelse og videorapport);
- «'.
Kilde: www.habr.com