Gestionant producció amb estil

Gestionant producció amb estil
Autors:

Als anys 90, quan va aparèixer la WWW, els recursos es publicaven a internet pujant els fitxers directament a un servidor mitjançant FTP i, si aquell tenia totes les dependències necessàries configurades per l’administrador de sistemes, la web es tornava accessible. Allò que semblava una meravella durant aquells anys, es va anar tornant una tasca molt complexa a mesura que els softwares anaven evolucionant i els anys passaven. Més dependències, més frameworks i moltes configuracions que s’havíen de portar per executar un servei donat. Es va anar popularitzant l’expressió d'”en la meva màquina funciona” per als desenvolupadors i la gent d’operacions tenia molts problemes de dependències per a desplegar aquestes noves versions de les aplicacions.

Per solucionar aquest problema, l’any 2013 va néixer Docker i la tecnologia dels contenidors, una forma de virtualització més lleugera (comparteix Kernel amb el host) que les màquines virtuals perquè no conté un hardware virtual com sí que fan les VM.

Un contenidor encapsula totes les dependències software i les configuracions que necessita un programa generant un entorn tancat perquè el programa funcioni adientment. D’aquesta forma, guanyem portabilitat, que és el principal avantatge de Docker. Això va simplificar moltíssim els desplegaments i es va començar a popularitzar la cultura dels microserveis, encapsular tota mena de programes en aquests contenidors per simplificar la seva gestió.

El problema és que quan això va ser adoptat per la indústria, la gestió manual dels contenidors, va tornar-se ineficient. Per exemple, és impossible pensar que Google només gestiona uns 10 contenidors, probablement en gestiona milions, i simplificar el desplegament era genial, però amb ell, va néixer una nova necessitat. Un software que gestionés tots els contenidors i que minimitzés tasques d’optimització i revisió manuals com millores en l’escalabilitat, revisés que no es produïssin fallades, o tingués en compte la comunicació entre aquests contenidors, aïllats per defecte.

Tots aquests aspectes van fomentar, l’any 2015, la creació, per part de Google, de Kubernetes, un orquestrador de contenidors que solucionava i simplificava tots aquells detalls. Aquest orquestrador funciona separant els components funcionals, per una banda, el Control Plane i per altra, els nodes Worker.

El Control Plane és l’encarregat del funcionament del clúster, té quatre peces fonamentals:

  • Etcd: emmagatzema la configuració (etcd).
  • Controller Manager: Conté tots els controladors, per exemple el dels nodes, encarregat de monitorar els workers i saber el seu estat, entre d’altres.
  • Scheduler: És l’encarregat de decidir quins contenidors van a cada node.
  • Kube-apiserver: L’Api que ofereix el Control Plane per gestionar tots aquests detalls.

Els nodes Workers, són els encarregats d’executar les càrregues de treball, es divideixen en tres parts. Podem tenir n workers i la funcionalitat del Control Plane és gestionar-los i dividir-los les càrregues de treball:

  • Kubelet: És un agent que corre en cada node i s’encarrega que els contenidors estiguin desplegats a unes instàncies anomenades “pods”. Una de les funcionalitats principals és la supervisió de la salut i correcta execució d’aquests contenidors.
  • Kube-proxy: És el responsable del networking dintre la xarxa Kubernetes. Redirigeix peticions, controla els permisos i aplica les polítiques pertinents per complir la comunicació desitjada.
  • Container runtime: És el motor d’execució de contenidors que utilitzem per a la virtualització, típicament containerd (Docker).

Les aplicacions per executar-se en Kubernetes han de ser descrites mitjançant un arxiu anomenat manifest. Existeixen un tipus de recursos que s’anomenen Deployments i que són els encarregats de definir la nostra aplicació.

Més enllà d’aquesta petita base, el networking per defecte és aïllat, igual que en Docker, per defecte només es poden accedir als continguts interns, en Kubernetes igual. Tot i això, hi ha mecanismes que indiquen al Proxy que ha de permetre un flux de comunicació determinat. Per això existeixen uns components anomenats Services, que tenen com a funció principal exposar una aplicació perquè pugui ser accessible des de fora del clúster (el cas del Load Balancer a la imatge de dalt).

Els principals avantatges de Kubernetes són la flexibilitat, la resiliència i l’alta disponibilitat que ofereix. Per exemple, quan detecta que un contenidor ha tingut una fallada, el torna a desplegar automàticament. Quan veu que un node Worker està molt carregat a nivell de recursos intenta (sempre que sigui possible) balancejar la càrrega entre els altres nodes del clúster, cosa que pot fer gràcies a la portabilitat dels contenidors, ja que és molt senzill moure un contenidor entre dos nodes.

Però una de les funcionalitats més importants de Kubernetes, i més tenint en compte l’auge del Cloud Computing, és l’alta escalabilitat que ofereix. Tenim components dintre Kubernetes que són capaços de monitoritzar la càrrega que està tenint un contenidor i en superar uns determinats límits de recursos marcats per l’administrador, escala l’aplicació generant una còpia del contenidor i dividint la càrrega entre els contenidors resultants. D’aquesta forma, alleugera la càrrega del primer contenidor i reparteix les peticions entre els dos.

Aquesta casuística s’ha tornat molt interessant en l’entorn Cloud, ja que un sistema pot eventualment, esdevenir tan escalable com vulguem. Si una aplicació té un pic de càrrega, Kubernetes de forma autònoma pot distribuir la càrrega entre el clúster per verificar el correcte funcionament de l’aplicació. Però donat el cas que tots els nodes del clúster estiguessin experimentant una càrrega que impedís el funcionament normal de l’aplicació, hi ha altres eines que permeten aprovisionar nodes de forma automàtica al clúster amb màquines de proveïdors Cloud per solucionar aquest pic sense downtimes.

En definitiva, els temps actuals han fet de Kubernetes no un gran avantatge en la infraestructura, sinó una necessitat degut a tots els avantatges que presenta, que solucionen problemàtiques quotidianes i com hem pogut veure en aquest article, alleugeren moltíssim la càrrega de feina dels administradors de sistemes i en entorns de grans empreses on aquesta complexitat es pot tornar gegant si no es té un mecanisme de gestió adient com aquest.