Bilješka. prev.: Autor originalnog članka je Théo Chamley, Google Cloud Solutions Architect. U ovom postu za blog Google Cloud daje sažetak detaljnijeg vodiča svoje tvrtke pod nazivom "" U njemu su Googleovi stručnjaci prikupili najbolju praksu za rad spremnika u kontekstu korištenja Google Kubernetes Enginea i više, dotičući se širokog raspona tema: od sigurnosti do nadzora i zapisivanja. Dakle, koje su najvažnije prakse spremnika prema Googleu?
(Usluga temeljena na Kubernetesu za pokretanje kontejnerskih aplikacija na Google Cloudu - cca. prijevod) je jedan od najboljih načina za pokretanje radnih opterećenja koja se moraju skalirati. će osigurati besprijekoran rad većine aplikacija ako su spremnici. Ali ako želite da vašom aplikacijom bude lako upravljati i želite u potpunosti iskoristiti prednosti Kubernetesa, morate slijediti najbolju praksu. Oni će pojednostaviti rad aplikacije, njeno praćenje i otklanjanje pogrešaka, a također će povećati sigurnost.
U ovom ćemo članku proći kroz popis stvari koje biste trebali znati i učiniti za učinkovito pokretanje spremnika na Kubernetesu. Oni koji žele ići dublje u detalje trebaju pročitati materijal , a također obratite pozornost na naše o sastavljanju kontejnera.
1. Koristite izvorne mehanizme zapisivanja spremnika
Ako se aplikacija izvodi na Kubernetes klasteru, nije potrebno puno za zapisnike. Centralizirani sustav zapisivanja vjerojatno je već ugrađen u klaster koji koristite. U slučaju korištenja Kubernetes Enginea, ovo je odgovorno . (Bilješka. prev.: A ako koristite vlastitu Kubernetes instalaciju, preporučujemo da pobliže pogledate naše rješenje otvorenog koda - .) Neka vam život bude jednostavan i koristite izvorne mehanizme za bilježenje spremnika. Pišite zapise u stdout i stderr - automatski će biti primljeni, spremljeni i indeksirani.
Ako želite, također možete pisati zapise na . Ovaj pristup će olakšati dodavanje metapodataka u njih. A s njima će Stackdriver Logging imati mogućnost pretraživanja kroz zapise pomoću ovih metapodataka.
2. Provjerite jesu li spremnici bez stanja i nepromjenjivi
Da bi spremnici ispravno funkcionirali u Kubernetes klasteru, moraju biti bez stanja i nepromjenjivi. Nakon što su ovi uvjeti ispunjeni, Kubernetes može raditi svoj posao, stvarajući i uništavajući entitete aplikacije kada i gdje je to potrebno.
bez države znači da je bilo koje stanje (trajni podaci bilo koje vrste) pohranjeno izvan spremnika. Za to se, ovisno o potrebama, mogu koristiti različite vrste vanjskih pohrana: , , , ili druge upravljane baze podataka. (Bilješka. prev.: Pročitajte više o tome u našem članku “".)
nepromjenljiv znači da se spremnik neće mijenjati tijekom svog životnog vijeka: nema ažuriranja, zakrpa, promjena konfiguracije. Ako trebate ažurirati kod aplikacije ili primijeniti zakrpu, izradite novu sliku i implementirajte je. Preporuča se premjestiti konfiguraciju spremnika (priključak za slušanje, opcije okruženja za vrijeme izvođenja, itd.) eksterno - na и . Mogu se ažurirati bez potrebe za izradom nove slike spremnika. Za jednostavno stvaranje cjevovoda sa sklopom slike, možete koristiti . (Bilješka. prev.: U te svrhe koristimo alat otvorenog koda .)
Primjer ažuriranja konfiguracije implementacije u Kubernetesu pomoću ConfigMapa montiranog u podove kao konfiguraciju
3. Izbjegavajte privilegirane spremnike
Vi ne pokrećete aplikacije kao root na svojim poslužiteljima, zar ne? Ako napadač uđe u aplikaciju, dobit će root pristup. Ista razmatranja vrijede za nepokretanje privilegiranih spremnika. Ako trebate promijeniti postavke na hostu, možete dati poseban spremnik sposobnosti koristeći opciju u Kubernetesu. Ako se trebate promijeniti sysctls, Kubernetes ima za ovo. Općenito, pokušajte maksimalno iskoristiti i bočne prikolice za obavljanje sličnih povlaštenih operacija. Ne moraju biti dostupni niti unutarnjem niti vanjskom prometu.
Ako upravljate klasterom, možete koristiti za ograničenja korištenja povlaštenih spremnika.
4. Izbjegavajte pokretanje kao root
O privilegiranim spremnicima već je bilo riječi, no bit će još bolje ako, uz to, ne pokrećete aplikacije unutar spremnika kao root. Ako napadač pronađe udaljenu ranjivost u aplikaciji s root pravima koja dopušta izvršavanje koda, nakon čega može napustiti spremnik kroz još nepoznatu ranjivost, dobit će root na hostu.
Najbolji način da to izbjegnete je da ništa ne pokrenete kao root. Da biste to učinili, možete koristiti direktivu USER в Dockerfile ili runAsUser u Kubernetesu. Administrator klastera također može konfigurirati ponašanje provedbe pomoću .
5. Neka aplikacija bude laka za praćenje
Poput zapisivanja, nadzor je sastavni dio upravljanja aplikacijama. Popularno rješenje za praćenje u Kubernetes zajednici je - sustav koji automatski detektira podove i usluge koje zahtijevaju nadzor. (Bilješka. prev.: Vidi također naš na temu nadzora pomoću Prometheusa i Kubernetesa.) sposoban je nadzirati Kubernetes klastere i uključuje vlastitu verziju Prometheusa za nadgledanje aplikacija.
Nadzorna ploča Kubernetes na Stackdriveru
Prometheus očekuje da aplikacija proslijedi metriku krajnjoj HTTP točki. Dostupno za ovo . Isti format koriste i drugi alati poput и .
6. Učinite zdravstveni status aplikacije dostupnim
Upravljanje aplikacijom u proizvodnji potpomognuto je njezinom sposobnošću da priopći svoje stanje cijelom sustavu. Je li aplikacija pokrenuta? Uredu je? Jeste li spremni primiti promet? Kako se on ponaša? Najčešći način rješavanja ovog problema je provođenje zdravstvenih pregleda (zdravstveni pregledi). Kubernetes ima dvije vrste: .
Za sondu živosti (provjere vitalnosti) aplikacija mora imati HTTP krajnju točku koja vraća odgovor "200 OK" ako je funkcionalna i njezine osnovne ovisnosti su zadovoljene. Za sondu spremnosti (provjere spremnosti servisa) aplikacija mora imati drugu krajnju točku HTTP-a koja vraća odgovor "200 OK" ako je aplikacija u ispravnom stanju, koraci inicijalizacije su dovršeni i bilo koji važeći zahtjev ne rezultira pogreškom. Kubernetes će samo usmjeravati promet u spremnik ako je aplikacija spremna prema ovim provjerama. Dvije krajnje točke mogu se spojiti ako nema razlike između stanja živosti i spremnosti.
Više o tome možete pročitati u povezanom članku Sandeepa Dinesha, Googleovog zagovornika programera: “".
7. Pažljivo odaberite verziju slike
Većina javnih i privatnih slika koristi sustav označavanja sličan onom opisanom u . Ako slika koristi sustav blizak , potrebno je voditi računa o specifičnostima označavanja. Na primjer, oznaka latest može često prelaziti sa slike na sliku - ne možete se pouzdati ako trebate predvidljive i ponovljive gradnje i instalacije.
Možete koristiti oznaku X.Y.Z (gotovo su uvijek nepromijenjeni), ali u ovom slučaju pratite sve zakrpe i ažuriranja slike. Ako slika koju koristite ima oznaku X.Y, ovo je dobra opcija za zlatnu sredinu. Odabirom iste automatski dobivate zakrpe, a istovremeno se oslanjate na stabilnu verziju aplikacije.
PS od prevoditelja
Pročitajte i na našem blogu:
- «»;
- «»;
- «»;
- «» (recenzija i video izvješće);
- «» (recenzija i video izvješće);
- «» (recenzija i video izvješće);
- «» (recenzija i video izvješće);
- «".
Izvor: www.habr.com