Hola, em dic Dmitry Krasnov. Durant més de cinc anys he estat administrant clústers de Kubernetes i construint arquitectures complexes de microserveis. A principis d'aquest any vam llançar un servei de gestió de clústers Kubernetes basat en Containerum. Aprofitant aquesta oportunitat, us explicaré què és Kubernetes i com difereix la integració amb un proveïdor del codi obert.
Per començar, què és . Aquest és un sistema per gestionar contenidors en un gran nombre d'amfitrions. Del grec, per cert, es tradueix com "pilot" o "timoner". Desenvolupat originalment per Google i després donat com a contribució tecnològica a la Cloud Native Computing Foundation, una organització internacional sense ànim de lucre que reuneix els principals desenvolupadors, usuaris finals i proveïdors de tecnologia de contenidors del món.
Gestionar un gran nombre de contenidors
Ara anem a esbrinar quin tipus de contenidors són. Aquesta és una aplicació amb tot el seu entorn, principalment les biblioteques de les quals depèn el programa. Tot això està empaquetat en arxius i presentat en forma d'imatge que es pot executar independentment del sistema operatiu, provat i més. Però hi ha un problema: gestionar els contenidors en un gran nombre d'amfitrions és molt difícil. Per això es va crear Kubernetes.
Una imatge de contenidor representa una aplicació més les seves dependències. L'aplicació, les seves dependències i la imatge del sistema de fitxers del sistema operatiu es troben en diferents parts de la imatge, les anomenades capes. Les capes es poden reutilitzar per a diferents contenidors. Per exemple, totes les aplicacions d'una empresa poden utilitzar la capa base d'Ubuntu. Quan s'executen contenidors, no cal emmagatzemar diverses còpies d'una única capa base a l'amfitrió. Això us permet optimitzar l'emmagatzematge i el lliurament d'imatges.
Quan volem executar una aplicació des d'un contenidor, les capes necessàries se superposen entre si i es forma un sistema de fitxers superposat. Es col·loca una capa d'enregistrament a la part superior, que s'elimina quan el contenidor s'atura. Això garanteix que quan s'executi el contenidor, l'aplicació sempre tindrà el mateix entorn, que no es pot canviar. Això garanteix la reproductibilitat de l'entorn en diferents sistemes operatius d'amfitrió. Tant si es tracta d'Ubuntu com de CentOS, l'entorn sempre serà el mateix. A més, el contenidor està aïllat de l'amfitrió mitjançant mecanismes integrats al nucli de Linux. Les aplicacions d'un contenidor no veuen fitxers, processos de l'amfitrió i contenidors veïns. Aquest aïllament de les aplicacions del sistema operatiu amfitrió proporciona una capa addicional de seguretat.
Hi ha moltes eines disponibles per gestionar contenidors en un host. El més popular d'ells és Docker. Permet oferir el cicle de vida complet dels contenidors. Tanmateix, només funciona en un amfitrió. Si necessiteu gestionar contenidors en diversos amfitrions, Docker pot convertir els enginyers en un infern. Per això es va crear Kubernetes.
La demanda de Kubernetes es deu precisament a la capacitat de gestionar grups de contenidors en diversos amfitrions com una mena d'entitat única. La popularitat del sistema ofereix l'oportunitat de crear DevOps o Operacions de Desenvolupament, en què Kubernetes s'utilitza per executar els processos d'aquest mateix DevOps.
Figura 1. Representació esquemàtica del funcionament de Kubernetes
Automatització total
DevOps és bàsicament l'automatització del procés de desenvolupament. A grans trets, els desenvolupadors escriuen codi que es penja al repositori. Aleshores, aquest codi es pot recollir automàticament immediatament en un contenidor amb totes les biblioteques, provar-lo i "desplegar-lo" a la següent fase: posada en escena, i immediatament a la producció.
Juntament amb Kubernetes, DevOps us permet automatitzar aquest procés perquè es produeixi pràcticament sense la participació dels mateixos desenvolupadors. A causa d'això, la compilació és significativament més ràpida, ja que el desenvolupador no ha de fer-ho al seu ordinador: simplement escriu un tros de codi, empeny el codi al dipòsit, després del qual s'inicia el pipeline, que pot incloure el procés. de construcció, prova i desplegament. I això passa amb cada commit, de manera que les proves es fan contínuament.
Al mateix temps, l'ús d'un contenidor us permet assegurar-vos que tot l'entorn d'aquest programa es llançarà en producció exactament en la forma en què es va provar. És a dir, no hi haurà problemes com "hi havia algunes versions a la prova, d'altres en producció, però quan les vam instal·lar, va caure tot". I com que avui tenim una tendència cap a l'arquitectura de microserveis, quan en comptes d'una gran aplicació n'hi ha centenars de petites, per poder administrar-les manualment es necessitarà una gran plantilla d'empleats. Per això fem servir Kubernetes.
Pros, pros, pros
Si parlem dels avantatges de Kubernetes com a plataforma, llavors té avantatges importants des del punt de vista de la gestió d'una arquitectura de microservei.
- Gestió de múltiples rèpliques. El més important és gestionar els contenidors en diversos hosts. Més important encara, gestioneu diverses rèpliques d'aplicacions en contenidors com una sola entitat. Gràcies a això, els enginyers no s'han de preocupar per cada contenidor individual. Si un dels contenidors falla, Kubernetes ho veurà i el reiniciarà.
- Xarxa de clústers. Kubernetes també té l'anomenada xarxa de clúster amb el seu propi espai d'adreces. Gràcies a això, cada pod té la seva pròpia adreça. Un subpod s'entén com la unitat estructural mínima d'un clúster en el qual es llancen directament els contenidors. A més, Kubernetes té una funcionalitat que combina un equilibrador de càrrega i Service Discovery. Això us permet desfer-vos de la gestió manual d'adreces IP i delegar aquesta tasca a Kubernetes. I les comprovacions automàtiques de salut ajudaran a detectar problemes i redirigir el trànsit als pods que funcionen.
- Gestió de la configuració. Quan es gestiona un gran nombre d'aplicacions, es fa difícil gestionar la configuració de l'aplicació. Per a això, Kubernetes disposa de recursos especials de ConfigMap. Us permeten emmagatzemar configuracions de manera centralitzada i exposar-les a pods quan executeu aplicacions. Aquest mecanisme ens permet garantir la coherència de la configuració en almenys deu o cent rèpliques d'aplicació.
- Volums persistents. Els contenidors són inherentment immutables i quan el contenidor s'atura, totes les dades escrites al sistema de fitxers es destruiran. Però algunes aplicacions emmagatzemen dades directament al disc. Per resoldre aquest problema, Kubernetes té una funcionalitat de gestió d'emmagatzematge en disc: volums persistents. Aquest mecanisme utilitza emmagatzematge extern per a les dades i pot transferir emmagatzematge persistent, bloc o fitxer a contenidors. Aquesta solució us permet emmagatzemar dades per separat dels treballadors, cosa que les estalvia si aquests mateixos treballadors s'avarian.
- Equilibrador de càrrega. Tot i que a Kubernetes gestionem entitats abstractes com Deployment, StatefulSet, etc., finalment els contenidors s'executen en màquines virtuals o servidors de maquinari normals. No són perfectes i poden caure en qualsevol moment. Kubernetes ho veurà i redirigirà el trànsit intern a altres rèpliques. Però què fer amb el trànsit que ve de fora? Si només dirigeixes el trànsit a un dels treballadors, si s'estavella, el servei no estarà disponible. Per resoldre aquest problema, Kubernetes disposa de serveis com Load Balancer. Estan dissenyats per configurar automàticament un equilibrador de núvol extern per a tots els treballadors del clúster. Aquest equilibrador extern dirigeix el trànsit extern als treballadors i supervisa el seu estat. Si un o més treballadors no estan disponibles, el trànsit es redirigeix a altres. Això us permet crear serveis d'alta disponibilitat mitjançant Kubernetes.
Kubernetes funciona millor quan s'executen arquitectures de microserveis. És possible implementar el sistema a l'arquitectura clàssica, però no té sentit. Si una aplicació no pot executar-se en diverses rèpliques, quina diferència hi fa, a Kubernetes o no?
Kubernetes de codi obert
Kubernetes de codi obert és una gran cosa: el vaig instal·lar i funciona. Podeu implementar-lo als vostres propis servidors de maquinari, a la vostra pròpia infraestructura, instal·lar mestres i treballadors en els quals s'executaran totes les aplicacions. I el més important, tot això és gratuït. Tanmateix, hi ha matisos.
- El primer és la demanda de coneixement i experiència dels administradors i enginyers que desplegaran i donaran suport a tot això. Com que el client rep total llibertat d'acció al clúster, ell mateix és responsable del rendiment del clúster. I aquí és molt fàcil trencar-ho tot.
- El segon és la manca d'integracions. Si executeu Kubernetes sense una plataforma de virtualització popular, no obtindreu tots els avantatges del programa. Com ara l'ús de volums persistents i serveis d'equilibri de càrrega.
Figura 2. Arquitectura k8s
Kubernetes del proveïdor
La integració amb un proveïdor de núvol ofereix dues opcions:
- En primer lloc, una persona pot simplement fer clic al botó "crear clúster" i obtenir un clúster ja configurat i llest per al seu ús.
- En segon lloc, el propi venedor instal·la el clúster i configura la integració amb el núvol.
Com passa aquí. L'enginyer que engega el clúster especifica quants treballadors necessita i amb quins paràmetres (per exemple, 5 treballadors, cadascun amb 10 CPU, 16 GB de RAM i, per exemple, 100 GB de disc). Després d'això, obté accés al clúster ja format. En aquest cas, els treballadors sobre els quals es llança la càrrega es transfereixen completament al client, però tot el pla de gestió roman sota la responsabilitat del venedor (si el servei es presta segons el model de servei gestionat).
Tanmateix, aquest esquema té els seus inconvenients. A causa del fet que el pla de gestió roman amb el venedor, el venedor no dóna accés total al client, i això redueix la flexibilitat a l'hora de treballar amb Kubernetes. De vegades passa que un client vol afegir alguna funcionalitat específica a Kubernetes, per exemple, l'autenticació mitjançant LDAP, però la configuració del pla de gestió no ho permet.
Figura 3. Exemple d'un clúster de Kubernetes d'un proveïdor de núvol
Què triar: codi obert o proveïdor
Aleshores, Kubernetes és de codi obert o específic del proveïdor? Si prenem Kubernetes de codi obert, l'usuari fa el que vol amb ell. Però hi ha una gran possibilitat de disparar-te al peu. Amb el venedor és més difícil, perquè tot està pensat i configurat per a l'empresa. El major desavantatge de Kubernetes de codi obert és la necessitat d'especialistes. Amb una opció de venedor, l'empresa s'allibera d'aquest mal de cap, però haurà de decidir si paga als seus especialistes o al venedor.
Bé, els pros són evidents, els contres també es coneixen. Una cosa és constant: Kubernetes soluciona molts problemes automatitzant la gestió de molts contenidors. I quin triar, codi obert o venedor: cadascú pren la seva pròpia decisió.
L'article va ser preparat per Dmitry Krasnov, arquitecte líder del servei Containerum del proveïdor #CloudMTS
Font: www.habr.com