Nota. transl.: L'autor de l'article original és Théo Chamley, arquitecte de solucions al núvol de Google. En aquesta publicació per al bloc de Google Cloud, proporciona un resum de la guia més detallada de la seva empresa, anomenada "" En ella, els experts de Google van recopilar les millors pràctiques per operar contenidors en el context de l'ús de Google Kubernetes Engine i molt més, tractant una àmplia gamma de temes: des de la seguretat fins a la supervisió i el registre. Aleshores, quines són les pràctiques de contenidors més importants segons Google?
(Servei basat en Kubernetes per executar aplicacions en contenidors a Google Cloud - aprox. transl.) és una de les millors maneres d'executar càrregues de treball que necessiten escalar. garantirà el bon funcionament de la majoria de les aplicacions si estan en contenidors. Però si voleu que la vostra aplicació sigui fàcil de gestionar i voleu treure el màxim profit de Kubernetes, heu de seguir les pràctiques recomanades. Simplificaran el funcionament de l'aplicació, el seu seguiment i depuració, i també augmentaran la seguretat.
En aquest article, repassarem una llista de coses que hauríeu de saber i fer per executar contenidors de manera eficaç a Kubernetes. Aquells que vulguin aprofundir en els detalls haurien de llegir el material , i també presta atenció al nostre sobre el muntatge de contenidors.
1. Utilitzeu mecanismes de registre de contenidors natius
Si l'aplicació s'executa en un clúster de Kubernetes, no es necessita gaire per als registres. És probable que un sistema de registre centralitzat ja estigui integrat al clúster que utilitzeu. En el cas d'utilitzar Kubernetes Engine, aquest és el responsable . (Nota. transl.: I si utilitzeu la vostra pròpia instal·lació de Kubernetes, us recomanem que feu una ullada a la nostra solució de codi obert: .) Mantingueu la vostra vida senzilla i utilitzeu mecanismes de registre de contenidors natius. Escriviu registres a stdout i stderr: es rebran, es desaran i indexaran automàticament.
Si ho desitja, també podeu escriure registres . Aquest enfocament farà que sigui fàcil afegir-hi metadades. I amb ells, Stackdriver Logging tindrà la possibilitat de cercar registres mitjançant aquestes metadades.
2. Assegureu-vos que els contenidors són sense estat i immutables
Perquè els contenidors funcionin correctament en un clúster de Kubernetes, han de ser sense estat i immutables. Un cop es compleixen aquestes condicions, Kubernetes pot fer la seva feina, creant i destruint entitats d'aplicació quan i on sigui necessari.
Apàtrides significa que qualsevol estat (dades persistents de qualsevol tipus) s'emmagatzema fora del contenidor. Per a això, segons les necessitats, es poden utilitzar diferents tipus d'emmagatzematge extern: , , , o altres bases de dades gestionades. (Nota. transl.: Llegeix més sobre això al nostre article "".)
immutable significa que el contenidor no es modificarà durant la seva vida: no hi ha actualitzacions, pegats, canvis de configuració. Si necessiteu actualitzar el codi de l'aplicació o aplicar un pedaç, creeu una imatge nova i implementeu-la. Es recomana moure la configuració del contenidor (port d'escolta, opcions d'entorn d'execució, etc.) externament a и . Es poden actualitzar sense haver de construir una nova imatge de contenidor. Per crear pipelines fàcilment amb el muntatge d'imatges, podeu utilitzar . (Nota. transl.: Utilitzem una eina de codi obert per a aquests propòsits .)
Un exemple d'actualització de la configuració de desplegament a Kubernetes mitjançant ConfigMap muntat en pods com a configuració
3. Evita els contenidors privilegiats
No executeu aplicacions com a root als vostres servidors, oi? Si un atacant entra a l'aplicació, obtindrà accés root. Les mateixes consideracions s'apliquen per no executar contenidors privilegiats. Si necessiteu canviar la configuració de l'amfitrió, podeu especificar el contenidor capacitats utilitzant l'opció a Kubernetes. Si cal canviar sysctls, Kubernetes té per això. En general, intenteu treure el màxim profit i contenidors sidecar per realitzar operacions privilegiades similars. No cal que siguin accessibles ni al trànsit intern ni extern.
Si administreu un clúster, podeu utilitzar per les restriccions a l'ús de contenidors privilegiats.
4. Eviteu executar-vos com a root
Ja s'han parlat dels contenidors privilegiats, però encara serà millor si, a més d'això, no executeu aplicacions dins del contenidor com a root. Si un atacant troba una vulnerabilitat remota en una aplicació amb drets d'arrel que permet l'execució de codi, després de la qual pot sortir del contenidor a través d'una vulnerabilitat encara desconeguda, obtindrà l'arrel a l'amfitrió.
La millor manera d'evitar-ho és no executar res com a root en primer lloc. Per fer-ho, podeu utilitzar la directiva USER в Dockerfile o runAsUser a Kubernetes. L'administrador del clúster també pot configurar el comportament d'aplicació mitjançant .
5. Feu que l'aplicació sigui fàcil de controlar
Igual que el registre, la supervisió és una part integral de la gestió d'aplicacions. Una solució de monitorització popular a la comunitat de Kubernetes és - un sistema que detecta automàticament pods i serveis que requereixen supervisió. (Nota. transl.: Vegeu també el nostre sobre el tema del seguiment amb Prometheus i Kubernetes.) és capaç de supervisar clústers de Kubernetes i inclou la seva pròpia versió de Prometheus per al seguiment d'aplicacions.
Tauler de control de Kubernetes a Stackdriver
Prometheus espera que l'aplicació reenviï mètriques al punt final HTTP. Disponible per a això . El mateix format és utilitzat per altres eines com и .
6. Feu que l'estat de salut de l'aplicació estigui disponible
La gestió d'aplicacions en producció es veu ajudada per la seva capacitat de comunicar el seu estat a tot el sistema. S'està executant l'aplicació? Està bé? Estàs preparat per rebre trànsit? Com s'està comportant? La manera més habitual de resoldre aquest problema és implementar controls de salut (controls de salut). Kubernetes té dos tipus: .
Per a la sonda de vivacitat (controls de vitalitat) l'aplicació ha de tenir un punt final HTTP que retorni una resposta "200 OK" si és funcional i es compleixen les seves dependències bàsiques. Per a la sonda de preparació (controls de preparació del servei) l'aplicació ha de tenir un altre punt final HTTP que retorni una resposta "200 OK" si l'aplicació es troba en un estat correcte, els passos d'inicialització s'han completat i qualsevol sol·licitud vàlida no dóna lloc a un error. Kubernetes només encaminarà el trànsit al contenidor si l'aplicació està preparada segons aquestes comprovacions. Es poden fusionar dos punts finals si no hi ha diferència entre els estats de vivacitat i de preparació.
Podeu llegir més sobre això a l'article relacionat de Sandeep Dinesh, defensor dels desenvolupadors de Google: "».
7. Trieu la versió d'imatge amb cura
La majoria d'imatges públiques i privades utilitzen un sistema d'etiquetatge similar al descrit a . Si la imatge utilitza un sistema proper a , cal tenir en compte les especificitats de l'etiquetatge. Per exemple, etiquetar latest es pot moure amb freqüència d'una imatge a una altra; no es pot confiar en si necessiteu compilacions i instal·lacions previsibles i repetibles.
Podeu utilitzar l'etiqueta X.Y.Z (gairebé sempre no canvien), però en aquest cas, feu un seguiment de tots els pegats i actualitzacions de la imatge. Si la imatge que utilitzeu té una etiqueta X.Y, aquesta és una bona opció per a la mitjana daurada. En triar-lo, rebeu automàticament pegats i al mateix temps confieu en la versió estable de l'aplicació.
PS del traductor
Llegeix també al nostre blog:
- «»;
- «»;
- «»;
- «» (revisió i vídeo reportatge);
- «» (revisió i vídeo reportatge);
- «» (revisió i vídeo reportatge);
- «» (revisió i vídeo reportatge);
- «».
Font: www.habr.com