Notă. transl.: Autorul articolului original este Théo Chamley, arhitect Google Cloud Solutions. În această postare pentru blogul Google Cloud, el oferă un rezumat al ghidului mai detaliat al companiei sale, numit „" În cadrul acestuia, experții Google au colectat cele mai bune practici pentru operarea containerelor în contextul utilizării Google Kubernetes Engine și altele, atingând o gamă largă de subiecte: de la securitate la monitorizare și înregistrare. Deci, care sunt cele mai importante practici privind containerele conform Google?
(Serviciu bazat pe Kubernetes pentru rularea aplicațiilor containerizate pe Google Cloud - aproximativ traducere) este una dintre cele mai bune modalități de a rula sarcini de lucru care trebuie să se extindă. va asigura buna functionare a majoritatii aplicatiilor daca sunt containerizate. Dar dacă doriți ca aplicația dvs. să fie ușor de gestionat și doriți să profitați din plin de Kubernetes, trebuie să urmați cele mai bune practici. Acestea vor simplifica funcționarea aplicației, monitorizarea și depanarea acesteia și, de asemenea, vor crește securitatea.
În acest articol, vom parcurge o listă de lucruri pe care ar trebui să le știți și să le faceți pentru a rula containerele în mod eficient pe Kubernetes. Cei care doresc să aprofundeze detaliile ar trebui să citească materialul , și, de asemenea, să acorde o atenție la noastre despre asamblarea containerelor.
1. Folosiți mecanisme native de înregistrare a containerelor
Dacă aplicația rulează pe un cluster Kubernetes, nu este nevoie de mult pentru jurnale. Un sistem de înregistrare centralizat este probabil deja încorporat în clusterul pe care îl utilizați. În cazul utilizării Kubernetes Engine, acesta este responsabil . (Notă. transl.: Și dacă utilizați propria instalație Kubernetes, vă recomandăm să aruncați o privire mai atentă la soluția noastră Open Source - .) Păstrați-vă viața simplă și utilizați mecanisme native de înregistrare a containerelor. Scrieți jurnalele în stdout și stderr - acestea vor fi primite, salvate și indexate automat.
Dacă doriți, puteți, de asemenea, să scrieți jurnalele în . Această abordare va facilita adăugarea de metadate la ele. Și cu ele, Stackdriver Logging va avea capacitatea de a căuta prin jurnale folosind aceste metadate.
2. Asigurați-vă că containerele sunt apatride și imuabile
Pentru ca containerele să funcționeze corect într-un cluster Kubernetes, acestea trebuie să fie apatride și imuabile. Odată îndeplinite aceste condiții, Kubernetes își poate face treaba, creând și distrugând entități de aplicație când și unde este nevoie.
apatrid înseamnă că orice stare (date persistente de orice fel) este stocată în afara containerului. Pentru aceasta, în funcție de necesități, pot fi utilizate diferite tipuri de stocare externă: , , , sau alte baze de date gestionate. (Notă. transl.: Citiți mai multe despre asta în articolul nostru „".)
Imuabil înseamnă că containerul nu va fi modificat pe durata de viață: fără actualizări, patch-uri, modificări de configurare. Dacă trebuie să actualizați codul aplicației sau să aplicați un patch, creați o nouă imagine și implementați-o. Este recomandat să mutați configurația containerului (portul de ascultare, opțiunile de mediu de rulare etc.) extern - către и . Acestea pot fi actualizate fără a fi nevoie să construiți o nouă imagine de container. Pentru a crea cu ușurință conducte cu asamblarea imaginilor, puteți utiliza . (Notă. transl.: Folosim un instrument Open Source în aceste scopuri .)
Un exemplu de actualizare a configurației de implementare în Kubernetes folosind ConfigMap montat în pod-uri ca configurație
3. Evitați containerele privilegiate
Nu rulați aplicații ca root pe serverele dvs., nu? Dacă un atacator intră în aplicație, va obține acces root. Aceleași considerații se aplică și pentru a nu rula containere privilegiate. Dacă trebuie să modificați setările pe gazdă, puteți da specificul containerului capacități folosind opțiunea în Kubernetes. Dacă trebuie să te schimbi sysctls, Kubernetes are pentru aceasta. În general, încercați să profitați la maximum și containere sidecar pentru a efectua operațiuni privilegiate similare. Nu trebuie să fie accesibile traficului intern sau extern.
Dacă administrați un cluster, puteți utiliza pentru restricții privind utilizarea containerelor privilegiate.
4. Evitați să rulați ca root
S-a discutat deja despre containerele privilegiate, dar va fi și mai bine dacă, pe lângă aceasta, nu rulați aplicații în interiorul containerului ca root. Dacă un atacator găsește o vulnerabilitate la distanță într-o aplicație cu drepturi root care permite executarea codului, după care poate părăsi containerul printr-o vulnerabilitate încă necunoscută, va câștiga root pe gazdă.
Cel mai bun mod de a evita acest lucru este să nu rulați nimic ca root în primul rând. Pentru a face acest lucru, puteți utiliza directiva USER в Dockerfile sau runAsUser în Kubernetes. Administratorul clusterului poate configura, de asemenea, comportamentul de aplicare folosind .
5. Faceți aplicația ușor de monitorizat
La fel ca înregistrarea în jurnal, monitorizarea este o parte integrantă a gestionării aplicațiilor. O soluție de monitorizare populară în comunitatea Kubernetes este - un sistem care detectează automat pod-urile și serviciile care necesită monitorizare. (Notă. transl.: Vezi și noastre pe tema monitorizării folosind Prometheus și Kubernetes.) este capabil să monitorizeze clusterele Kubernetes și include propria sa versiune de Prometheus pentru monitorizarea aplicațiilor.
Tabloul de bord Kubernetes pe Stackdriver
Prometheus se așteaptă ca aplicația să trimită valori către punctul final HTTP. Disponibil pentru asta . Același format este folosit de alte instrumente precum и .
6. Faceți disponibilă starea de sănătate a aplicației
Managementul aplicațiilor în producție este ajutat de capacitatea sa de a comunica starea sa întregului sistem. Aplicația rulează? Este in regula? Sunteți gata să primiți trafic? Cum se comporta? Cea mai comună modalitate de a rezolva această problemă este implementarea controalelor de sănătate (controale de sănătate). Kubernetes are două tipuri: .
Pentru sonda de viață (verificări de vitalitate) aplicația trebuie să aibă un punct final HTTP care returnează un răspuns „200 OK” dacă este funcțională și dependențele sale de bază sunt satisfăcute. Pentru sonda de pregătire (verificări de pregătire a serviciului) aplicația trebuie să aibă un alt punct final HTTP care returnează un răspuns „200 OK” dacă aplicația este într-o stare sănătoasă, pașii de inițializare au fost finalizați și orice cerere validă nu are ca rezultat o eroare. Kubernetes va direcționa traficul către container numai dacă aplicația este pregătită conform acestor verificări. Două puncte finale pot fi îmbinate dacă nu există nicio diferență între starea de viață și starea de pregătire.
Puteți citi mai multe despre acest lucru în articolul conex de la Sandeep Dinesh, Developer Advocate de la Google: „".
7. Alegeți cu atenție versiunea imaginii
Majoritatea imaginilor publice și private folosesc un sistem de etichetare similar cu cel descris în . Dacă imaginea folosește un sistem apropiat de , este necesar să se țină cont de specificul etichetării. De exemplu, etichetați latest se poate deplasa frecvent de la o imagine la alta - nu poate fi invocat daca aveti nevoie de constructii si instalatii previzibile si repetabile.
Puteți folosi eticheta X.Y.Z (sunt aproape întotdeauna neschimbate), dar în acest caz, urmăriți toate patch-urile și actualizările imaginii. Dacă imaginea pe care o utilizați are o etichetă X.Y, aceasta este o opțiune bună pentru media de aur. Alegându-l, primești automat patch-uri și în același timp te bazezi pe versiunea stabilă a aplicației.
PS de la traducator
Citește și pe blogul nostru:
- «»;
- «»;
- «»;
- «» (recenzie și raport video);
- «» (recenzie și raport video);
- «» (recenzie și raport video);
- «» (recenzie și raport video);
- «".
Sursa: www.habr.com