🥇7 najboljih praksi za korištenje kontejnera prema Googleu

Napomena za prijevod.: Autor originalnog članka je Théo Chamley, arhitekt cloud rješenja u Googleu. U ovom blog postu Google Clouda predstavio je sažetak detaljnog priručnika njegove tvrtke pod nazivom „Najbolje prakse za upravljanje kontejnerima“. U njemu su stručnjaci Googlea prikupili najbolje prakse za upravljanje kontejnerima u kontekstu korištenja Google Kubernetes Engine i ne samo toga, obuhvaćajući širok spektar tema: od sigurnosti do nadzora i logiranja. Dakle, koje su prakse u radu s kontejnerima najvažnije prema Googleu?

Kubernetes Engine (usluga temelji se na Kubernetesu za pokretanje kontejneriziranih aplikacija u Google Cloud — napomena prev.) — jedan je od najboljih načina za pokretanje radnih opterećenja koja zahtijevaju skalabilnost. Kubernetes osigurat će besprijekorno funkcioniranje većine aplikacija kada su kontejnerizirane. No, ako želite da aplikacijom bude lako upravljati i želite iskoristiti sve prednosti Kubernetesa, potrebno je slijediti najbolje prakse. One će pojednostaviti upravljanje aplikacijom, njezin nadzor i dijagnostiku, a također će povećati sigurnost.

U ovom članku proći ćemo kroz popis onoga što trebate znati i raditi za učinkovito funkcioniranje kontejnera u Kubernetesu. Onima koji žele dublje roniti u detalje preporučujemo da pročitaju materijal Najbolje prakse za upravljanje kontejnerima, a također obratite pozornost na naš raniji post o sastavljanju kontejnera.

1. Koristite izvorne mehanizme kontejnera za logiranje

Ako je aplikacija pokrenuta u Kubernetes klasteru, ne treba vam mnogo za logove. Centralizirani sustav logiranja vjerojatno je već integriran u korišteni klaster. U slučaju korištenja Kubernetes Engine-a, za to je odgovoran Stackdriver Logging. (Napomena za prijevod.: A u slučaju korištenja vlastite instalacije Kubernetesa, preporučujemo da razmotrite naše Open Source rješenje — loghouse.) Ne komplicirajte si život i koristite izvorne mehanizme logiranja kontejnera. Pišite logove u stdout i stderr — oni će automatski biti prikupljeni, pohranjeni i indeksirani.

Ako želite, možete također pisati logove u JSON formatu. Ovaj pristup omogućuje jednostavno dodavanje metapodataka. A zajedno s njima, u Stackdriver Loggingu bit će moguća pretraga logova koristeći te metapodatke.

2. Osigurajte da su kontejneri stateless i immutable

Za ispravno funkcioniranje kontejnera u Kubernetes klasteru, oni moraju biti stateless i immutable. Kada su ti uvjeti ispunjeni, Kubernetes može obavljati svoj posao stvarajući i uništavajući entitete aplikacije kada i gdje je to potrebno.

Stateless znači da se bilo kakvo stanje (trajni podaci bilo koje vrste) pohranjuju izvan kontejnera. Za to, ovisno o potrebama, mogu se koristiti različite vrste vanjskih pohrana: Cloud Storage, Persistent Disks, Redis, Cloud SQL ili druge upravljane baze podataka. (Napomena za prijevod.: Više o tome možete pročitati i u našem članku "Operatori za Kubernetes: kako pokretati stateful aplikacije».)

Immutable znači da se kontejner neće modificirati tijekom svog života: nikakva ažuriranja, zakrpe, promjene u konfiguraciji. Ako trebate ažurirati kod aplikacije ili primijeniti zakrpu, izradite novu sliku i implementirajte je. Preporučuje se prebacivanje konfiguracije kontejnera (port za slušanje, opcije izvršnog okruženja itd.) izvan - u Secrets i ConfigMaps. Njih je moguće ažurirati bez potrebe za izradom nove slike kontejnera. Za jednostavno kreiranje pipelinea za izradu slika može se koristiti Cloud Build. (Napomena za prijevod.: Za te svrhe koristimo Open Source alat dapp.)

Primjer ažuriranja konfiguracije Deployment-a u Kubernetesu pomoću ConfigMap-a, montiranog u podove kao konfiguraciju

3. Izbjegavajte privilegirane kontejnere

Zar ne pokrećete aplikacije pod root-om na svojim poslužiteljima? Ako napadač provali u aplikaciju, dobit će pristup s root pravima. Ista razmatranja vrijede i za izbjegavanje pokretanja privilegiranih kontejnera. Ako su potrebne promjene postavki na hostu, možete dodijeliti kontejneru određene capabilities putem opcije securityContext u Kubernetesu. Ako je potrebna izmjena sysctls, Kubernetes ima odvojenu anotaciju za to. Uglavnom, nastojte maksimalno koristiti init- i sidecar kontejnerske operacije za obavljanje sličnih privilegiranih operacija. Oni ne zahtijevaju dostupnost ni za unutarnji ni za vanjski promet.

Ako administrirate klaster, možete iskoristiti Pod Security Policy za ograničenja u primjeni privilegiranih kontejnera.

4. Izbjegavajte pokretanje pod root

O privilegiranim kontejnerima se već govorilo, ali bi bilo još bolje ako u dodatku tome ne pokrećete aplikacije unutar kontejnera kao root. Ako napadač pronađe udaljenu ranjivost u aplikaciji sa root pravima koja mu omogućava izvršavanje koda, a zatim uspije napustiti kontejner zbog za sada nepoznate ranjivosti, tada će dobiti root pristup na hostu.

Najbolji način da to izbjegnete je, prije svega, ne pokretati ništa kao root. Za to možete iskoristiti direktivu USER u Dockerfile ili runAsUser u Kubernetesu. Administrator klastera također može postaviti obavezno ponašanje pomoću Pod Security Policy.

5. Učinite aplikaciju jednostavnom za praćenje

Kao i logiranje, praćenje je neizostavni dio upravljanja aplikacijom. Popularno rješenje za praćenje u Kubernetes zajednici je Prometheus — sustav koji automatski otkriva podove i servise koji trebaju praćenje. (Napomena za prijevod.: Poglejte naš detaljni izvještaj o praćenju s Prometheusom i Kubernetesom.) Stackdriver može pratiti Kubernetes klastere i uključuje svoju verziju Prometheusa za praćenje aplikacija.

Kubernetes nadzorna ploča u Stackdriveru

Očekuje se da aplikacija izloži metrike na HTTP endpointu. Za to su dostupne Prometheus klijentske biblioteke. Isti format koriste i drugi alati poput OpenCensus i Istio.

6. Učinite stanje aplikacije dostupnim

Upravljanje aplikacijom u produkciji pomaže njezina sposobnost da izvještava o svom stanju cijelom sustavu. Je li aplikacija pokrenuta? Je li sve u redu? Spremna je za primanje prometa? Kako se ponaša? Najčešći način rješavanja ovog problema je implementacija provjera zdravlja (health checks). U Kubernetesu postoje dva njihova tipa: liveness i readiness probes.

Za liveness probe (provjera životne sposobnosti) aplikacija mora imati HTTP endpoint koji vraća odgovor «200 OK», ako funkcioniše i ako su njegove ključne zavisnosti zadovoljene. Za readiness probe (provjera spremnosti za uslugu) Aplikacija mora imati drugi HTTP endpoint koji vraća odgovor "200 OK" ako je aplikacija u zdravom stanju, koraci inicijalizacije su izvršeni i svaki ispravan zahtjev ne uzrokuje grešku. Kubernetes će usmjeravati promet na kontejner samo ako je aplikacija spremna prema tim provjerama. Dva endpointa mogu biti spojena ako nema razlike između stanja održivosti (liveness) i spremnosti (readiness).

Više o tome možete pročitati u odgovarajućem članku Sandeepa Dinesha, razvojnog advokata iz Googlea: "Kubernetes najbolje prakse: Postavljanje provjera zdravstvenog stanja s provjerama spremnosti i održivosti».

7. Pažljivo birajte verziju slike

Većina javnih i privatnih slika koristi sustav označavanja koji nalikuje onome opisanom u Najbolje prakse za izgradnju kontejnera. Ako slika primjenjuje sustav koji je blizak semantičkom verzioniranju, potrebno je razmotriti specifičnosti označavanja. Na primjer, oznaka najnovije može se često premještati s slike na sliku — na nju se ne može osloniti ako su vam potrebne predvidive i ponovljive građe i instalacije.

Možete koristiti oznaku X.Y.Z (ona je gotovo uvijek nepromijenjena), no u tom slučaju pratite sve ispravke i ažuriranja slike. Ako odabrana slika ima oznaku X.Y, to je dobra opcija zlatne sredine. Odabirom nje automatski dobivate ispravke dok se oslanjate na stabilnu verziju aplikacije.