Bones Pràctiques amb Kubernetes

Bones pràctiques per treballar amb Kubernetes

A mesura que aneu treballant amb Kubernetes, us adonareu que hi ha maneres millors i pitjors de fer les coses. Aquí us explico algunes pràctiques recomanades que us estalviaran molts problemes a llarg termini.

Especificant versions concretes de les imatges

Quan definiu un contenidor, podeu sentir-vos temptats a usar l'etiqueta "latest" per la imatge, pensant que així sempre tindreu la versió més recent. Però això és una mala idea en la majoria de casos. El problema és que "latest" pot canviar en qualsevol moment, i això pot fer que el vostre Deployment es trenqui sense que hagueu canviat res al vostre codi.

Imagineu que desplegeu avui amb nginx:latest i tot funciona perfectament. Demà, els desenvolupadors de NGINX llancen una nova versió amb canvis importants. Si Kubernetes necessita recrear un pod (per exemple, perquè un node ha fallat), descarregarà aquesta nova versió i el vostre pod pot deixar de funcionar correctament. Com que vosaltres no heu canviat res, serà molt difícil de depurar.

Per això, és molt millor especificar versions concretes, com nginx:1.27. D'aquesta manera, sabeu exactament quina versió esteu executant, i els pods es recreen sempre amb la mateixa versió. Quan volgueu actualitzar, ho feu conscientemente, canviant el número de versió i testejant els canvis.

Definint límits de recursos

Cada pod hauria de tenir definits els seus límits de CPU i memòria. Això pot semblar una complicació innecessària quan comenceu, però és crucial per a la estabilitat del clúster. Sense límits, un pod defectuós podria monopolitzar tots els recursos d'un node i afectar altres aplicacions.

Hi ha dos tipus de valors que podeu definir: requests i limits. Els requests són els recursos mínims que el pod necessita per funcionar correctament. Kubernetes usa aquests valors per decidir on col·locar el pod. Si cap node té prou recursos disponibles per satisfer els requests, el pod no es desplegarà fins que s'alliberin recursos.

Els limits són el màxim que el pod pot utilitzar. Si un pod intenta utilitzar més CPU del límit, Kubernetes l'estrangularà (el farà anar més lent). Si intenta utilitzar més memòria del límit, Kubernetes matarà el contenidor i el reiniciarà. Això pot semblar dur, però és millor que permetre que un sol pod es mengi tota la memòria del node.

Utilitzant health checks

Els health checks són proves que Kubernetes executa periòdicament per saber si els vostres pods estan funcionant correctament. Hi ha dos tipus principals: liveness probes i readiness probes.

La liveness probe (prova de vida) comprova si el contenidor està viu. Si aquesta prova falla repetidament, Kubernetes assumeix que el contenidor s'ha penjat i el reinicia. Això és útil per recuperar-se de situacions on l'aplicació entra en un estat corrupte del qual no pot sortir sola.

La readiness probe (prova de preparació) comprova si el pod està llest per rebre trànsit. És important perquè algunes aplicacions necessiten temps per inicialitzar-se: poden necessitar carregar dades de la base de dades, escalfar cachés, o fer altres tasques abans d'estar llestes per servir peticions. Durant aquest temps, el pod està funcionant (passa la liveness probe) però no hauria de rebre trànsit encara. Si la readiness probe falla, Kubernetes temporalment deixa d'enviar trànsit a aquest pod, però no el reinicia.

Organitzant amb namespaces

Els namespaces són una manera de dividir el vostre clúster en entorns virtuals separats. Per defecte, tots els recursos es creen al namespace "default", però podeu crear els vostres propis namespaces per organitzar millor les coses.

Per exemple, podríeu tenir un namespace "development" per a proves, un "staging" per a testing pre-producció, i un "production" per a l'entorn real. Dins de cada namespace, podeu tenir policies de xarxa diferents, límits de recursos diferents, i permisos d'accés diferents. Això ajuda a mantenir les coses organitzades i evitar accidents com esborrar accidentalment recursos de producció quan pensàveu que estàveu a development.

Gestionant secrets de forma segura

Mai, mai, mai poseu contrasenyes o altres dades sensibles directament als fitxers YAML del vostre codi. És una pràctica de seguretat terrible que pot tenir conseqüències greus. En comptes d'això, utilitzeu els Secrets de Kubernetes, que són recursos específics per emmagatzemar informació sensible.

Els Secrets es poden crear des de fitxers o amb la línia de comandes, i després els vostres pods hi poden accedir muntant-los com a volums o com a variables d'entorn. Kubernetes emmagatzema els Secrets de forma xifrada (en versions recents) i només els proporciona als pods que realment els necessiten.

Usant etiquetes consistents

Les etiquetes són la manera principal d'organitzar i seleccionar recursos a Kubernetes. És important usar-les de forma consistent. Per exemple, podríeu tenir sempre una etiqueta "app" que identifica l'aplicació, una etiqueta "environment" que diu si és dev, staging o production, i una etiqueta "version" per indicar la versió.

Amb etiquetes ben definides, podeu fer consultes molt potents com "mostra'm tots els pods de l'aplicació web que estiguin en l'entorn de producció", o "elimina tots els recursos de la versió antiga que ja no necessitem".

Documentant els fitxers YAML

Els fitxers YAML admeten comentaris, i hauríeu d'usar-los generosament. Quan torneu a mirar un fitxer després de sis mesos, us agraireu haver escrit comentaris explicant per què vau configurar alguna cosa d'una manera particular. És especialment important documentar decisions que poden no ser òbvies, com valors específics de recursos o anotacions especials.

Separant configuració i codi

Les bones pràctiques de desenvolupament modernes diuen que la configuració hauria d'estar separada del codi. A Kubernetes, això es fa amb ConfigMaps. En lloc de codificar en dur valors de configuració a la vostra imatge de Docker, els poseu en un ConfigMap que podeu canviar fàcilment sense haver de reconstruir la imatge.

Per exemple, si la vostra aplicació necessita saber la URL de la base de dades, poseu aquesta URL en un ConfigMap. D'aquesta manera, podeu tenir el mateix codi funcionant en diferents entorns només canviant el ConfigMap.