🥇7 cele mai bune practici pentru operarea containerelor conform Google

Nota traducătorului.: Autorul articolului original este Théo Chamley, arhitect de soluții cloud la Google. În această publicare pe blogul Google Cloud, el a prezentat un rezumat concis dintr-un ghid mai detaliat al companiei sale, intitulat „Cele mai bune practici pentru operarea containerelor”. În el, specialiștii Google au adunat cele mai bune practici pentru exploatarea containerelor în contextul utilizării Google Kubernetes Engine și nu numai, acoperind o gamă largă de teme: de la securitate până la monitorizare și înregistrare. Așadar, care sunt practicile cele mai importante în lucru cu containere, potrivit Google?

Google Kubernetes Engine (serviciul bazat pe Kubernetes pentru rularea aplicațiilor containerizate în Google Cloud — notă de traducere.) — este una dintre cele mai bune modalități de a rula sarcini de lucru care necesită scalare. Kubernetes va asigura funcționarea fără probleme a majorității aplicațiilor, dacă acestea sunt containerizate. Dar, dacă doriți ca aplicația să fie ușor de gestionat și să profitați de toate avantajele Kubernetes, trebuie să urmați cele mai bune practici. Acestea vor simplifica exploatarea aplicației, monitorizarea și depanarea acesteia, precum și vor îmbunătăți securitatea.

În acest articol, vom trece în revistă lista a ceea ce trebuie să știți și să faceți pentru o funcționare eficientă a containerelor în Kubernetes. Cei care doresc să înțeleagă mai în detaliu ar trebui să citească materialul Cele mai bune practici pentru operarea containerelor, iar de asemenea să acorde atenție postării noastre anterioare despre construirea containerelor.

1. Utilizați mecanismele native ale containerelor pentru înregistrare

Dacă aplicația este rulată într-un cluster Kubernetes, nu este nevoie de prea mult pentru înregistrări. Un sistem de înregistrare centralizat este probabil deja integrat în clusterul utilizat. În cazul utilizării Google Kubernetes Engine, aceasta este responsabilitatea Stackdriver Logging. (Nota traducătorului.: În cazul utilizării unei instalări proprii de Kubernetes, vă recomandăm să luați în considerare soluția noastră Open Source — loghouse.) Nu vă complicați viața și folosiți mecanismele native ale jurnalizării containerelor. Scrieți înregistrările în stdout și stderr — ele vor fi obținute, salvate și indexate automat.

Dacă doriți, puteți, de asemenea, să scrieți înregistrările în format JSON. Această abordare va permite adăugarea ușoară de metadate. Și împreună cu acestea, în Stackdriver Logging va apărea posibilitatea de căutare a înregistrărilor folosind aceste metadate.

2. Asigurați-vă că containerele sunt stateless și immutable

Pentru un funcționare corectă a containerelor într-un cluster Kubernetes, acestea trebuie să fie stateless și immutable. Când aceste condiții sunt îndeplinite, Kubernetes își va putea îndeplini sarcinile, creând și distrugând entități ale aplicației ori de câte ori și unde este necesar.

Stateless înseamnă că orice stare (date persistente de orice fel) este stocată în afara containerului. În acest sens, în funcție de necesități, pot fi utilizate diferite tipuri de stocări externe: Cloud Storage, Discuri Persistente, Redis, Cloud SQL sau alte baze de date gestionate. (Nota traducătorului.: Aflați mai multe despre acest subiect în articolul nostru „Operatori pentru Kubernetes: cum să lancezi aplicații stateful».)

Immutable înseamnă că containerul nu va fi modificat pe parcursul vieții sale: nicio actualizare, niciun patch, fără modificări ale configurației. Dacă doriți să actualizați codul aplicației sau să aplicați un patch, creați o nouă imagine și desfășurați-o. Se recomandă extragerea configurației containerului (portul de ascultare, opțiunile mediului de execuție etc.) în afara acestuia — în Secrets și ConfigMaps. Acestea pot fi actualizate fără a fi necesară construirea unei noi imagini a containerului. Pentru a simplifica crearea de pipeline-uri pentru construcția imaginilor, se poate utiliza Cloud Build. (Nota traducătorului.: Pentru aceste scopuri, folosim instrumentul Open Source dapp.)

Exemplu de actualizare a configurației Deployment în Kubernetes folosind ConfigMap, montat în poduri ca un config

3. Evitați containerele privilegiate

Nu rulați aplicațiile sub root pe serverele dumneavoastră, nu-i așa? Dacă un atacator intră în aplicație, va obține acces cu drepturi de root. Aceleași considerații se aplică și pentru a nu rula containere privilegiate. Dacă este necesară modificarea setărilor pe gazdă, se pot oferi containerului anumite capabilities prin opțiunea securityContext în Kubernetes. Dacă este nevoie să modificați sysctls, Kubernetes are o anotație separată pentru aceasta. În general, încercați să utilizați cât mai mult init- și containere sidecar pentru a efectua astfel de operațiuni privilegiate. Ele nu necesită accesibilitate pentru traficul intern sau extern.

Dacă administrați un cluster, puteți utiliza Politica de Securitate a Pod-urilor pentru limitările aplicării containerelor privilegiate.

4. Evitați rularea sub root

Despre containerele privilegiate s-a spus deja, dar va fi și mai bine dacă, pe lângă asta, nu veți rula aplicații sub root în interiorul containerului. Dacă un atacator găsește o vulnerabilitate de execuție a codului într-o aplicație cu privilegii root, iar apoi reușește să iasă din limitele containerului printr-o vulnerabilitate încă necunoscută, va obține acces root pe host.

Cea mai bună metodă de a evita aceasta este, în primul rând, să nu rulați nimic sub root. Pentru asta, se poate utiliza directiva USER în Dockerfile sau runAsUser în Kubernetes. Administratorul de cluster poate de asemenea să configureze un comportament forțat cu ajutorul Politica de Securitate a Pod-urilor.

5. Faceti aplicația ușor de monitorizat

La fel ca și logarea, monitorizarea este o parte esențială a managementului aplicației. O soluție populară pentru monitorizare în comunitatea Kubernetes este Prometheus — un sistem care descoperă automat podurile și serviciile ce necesită monitorizare. (Nota traducătorului.: Consultați și raportul nostru detaliat privind monitorizarea folosind Prometheus și Kubernetes.) Stackdriver este capabil să monitorizeze clustere Kubernetes și include versiunea sa de Prometheus pentru monitorizarea aplicațiilor.

Panoul de monitorizare Kubernetes din Stackdriver

Prometheus se așteaptă ca aplicația să expună metrici printr-un endpoint HTTP. Pentru aceasta sunt disponibile biblioteci client Prometheus. Același format este utilizat de alte instrumente precum OpenCensus și Istio.

6. Faceți disponibil statusul sănătății aplicației

Managementul aplicației în producție beneficiază de capacitatea acesteia de a raporta starea sa întregului sistem. Este aplicația pornită? Este funcțională? Este pregătită să primească trafic? Cum se comportă? Cea mai comună metodă de a aborda această problemă este implementarea verificărilor de sănătate (health checks). Kubernetes dispune de două tipuri de asemenea verificări: liveness și readiness probes.

Pentru liveness probe (verificări de viabilitate) aplicația trebuie să aibă un endpoint HTTP care returnează răspunsul „200 OK” dacă funcționează și dependențele sale principale sunt îndeplinite. Pentru readiness probe (verificări de pregătire pentru servire) Aplicația trebuie să aibă un alt endpoint HTTP care să returneze răspunsul „200 OK” dacă aplicația este în stare sănătoasă, pașii de inițializare sunt finalizați și orice cerere corectă nu duce la o eroare. Kubernetes va redirecționa traficul către container doar dacă aplicația este pregătită conform acestor verificări. Cele două endpoint-uri pot fi unite dacă nu există nicio diferență între stările de viabilitate (liveness) și pregătire (readiness).

Mai multe informații pot fi găsite în articolul corespunzător scris de Sandeep Dinesh, Developer Advocate de la Google: „Kubernetes best practices: Configurarea verificărilor de sănătate cu probe de readiness și liveness».

7. Alegeți cu atenție versiunea imaginii

Cele mai multe imagini publice și private utilizează un sistem de etichetare similar cu cel descris în Best Practices for Building Containers. Dacă imaginea aplică un sistem asemănător cu versionarea semantică, este necesar să țineți cont de specificitatea etichetării. De exemplu, eticheta latest poate migra frecvent de la o imagine la alta - nu se poate conta pe ea dacă aveți nevoie de construcții și instalări previzibile și reproducibile.

Puteți utiliza eticheta X.Y.Z (de obicei, acestea rămân neschimbate), însă în acest caz, urmăriți toate patch-urile și actualizările imaginii. Dacă imaginea utilizată are eticheta X.Y, acesta este o alegere bună de mijloc. Alegând-o, obțineți automat patch-uri și, în același timp, vă bazați pe o versiune stabilă a aplicației.