Kubernetes és una eina fantàstica per executar contenidors Docker en un entorn de producció en clúster. Tanmateix, hi ha problemes que Kubernetes no pot resoldre. Per a desplegaments de producció freqüents, necessitem un desplegament blau/verd totalment automatitzat per evitar temps d'inactivitat en el procés, que també ha de gestionar les sol·licituds HTTP externes i realitzar descàrregues SSL. Això requereix la integració amb un equilibrador de càrrega com ara ha-proxy. Un altre repte és l'escala semiautomàtica del propi clúster de Kubernetes quan s'executa en un entorn de núvol, per exemple, reduir parcialment el clúster a la nit.
Tot i que Kubernetes no té aquestes funcions fora de la caixa, proporciona una API que podeu utilitzar per resoldre problemes similars. Les eines per al desplegament automatitzat de Blue/Green i l'escalat d'un clúster Kubernetes es van desenvolupar com a part del projecte Cloud RTI, que es va crear basant-se en codi obert.
Aquest article, una transcripció de vídeo, us mostra com configurar Kubernetes juntament amb altres components de codi obert per crear un entorn llest per a la producció que accepti codi d'un commit git sense temps d'inactivitat a la producció.
Per tant, un cop tingueu accés a les vostres aplicacions des del món exterior, podeu començar a configurar completament l'automatització, és a dir, portar-la a l'etapa on podeu realitzar una confirmació git i assegurar-vos que aquesta confirmació git acabi en producció. Naturalment, quan implementem aquests passos, quan implementem el desplegament, no volem trobar temps d'inactivitat. Per tant, qualsevol automatització a Kubernetes comença amb l'API.
Kubernetes no és una eina que es pugui utilitzar de manera productiva des de la caixa. Per descomptat, podeu fer-ho, utilitzar kubectl i així successivament, però tot i així l'API és el més interessant i útil d'aquesta plataforma. Si utilitzeu l'API com a conjunt de funcions, podeu accedir a gairebé qualsevol cosa que vulgueu fer a Kubernetes. El propi kubectl també utilitza l'API REST.
Això és REST, de manera que podeu utilitzar qualsevol llenguatge o eina per treballar amb aquesta API, però les biblioteques personalitzades us facilitaran molt la vida. El meu equip va escriure dues biblioteques d'aquest tipus: una per a Java/OSGi i una per a Go. El segon no s'utilitza sovint, però en qualsevol cas teniu aquestes coses útils a la vostra disposició. Són un projecte de codi obert amb llicència parcial. Hi ha moltes biblioteques d'aquest tipus per a diferents idiomes, de manera que podeu triar les que més us convinguin.
Per tant, abans de començar a automatitzar el desplegament, heu d'assegurar-vos que el procés no estarà subjecte a cap temps d'inactivitat. Per exemple, el nostre equip realitza desplegaments de producció a la meitat del dia quan la gent està utilitzant les aplicacions al màxim, per la qual cosa és important evitar retards en aquest procés. Per evitar temps d'inactivitat, s'utilitzen 2 mètodes: desplegament blau/verd o actualització continua. En aquest últim cas, si teniu 5 rèpliques de l'aplicació en execució, s'actualitzen seqüencialment una darrere l'altra. Aquest mètode funciona molt bé, però no és adequat si teniu diferents versions de l'aplicació que s'executen simultàniament durant el procés de desplegament. En aquest cas, podeu actualitzar la interfície d'usuari mentre el backend està executant la versió antiga i l'aplicació deixarà de funcionar. Per tant, des del punt de vista de la programació, treballar en aquestes condicions és força difícil.
Aquesta és una de les raons per les quals preferim utilitzar el desplegament blau/verd per automatitzar el desplegament de les nostres aplicacions. Amb aquest mètode, us heu d'assegurar que només una versió de l'aplicació estigui activa a la vegada.
El mecanisme de desplegament blau/verd té aquest aspecte. Rebem trànsit de les nostres aplicacions mitjançant ha-proxy, que el reenvia a rèpliques en execució de l'aplicació de la mateixa versió.
Quan es fa un nou desplegament, fem servir Deployer, que rep els nous components i desplega la nova versió. El desplegament d'una nova versió d'una aplicació significa que es "aixeca" un nou conjunt de rèpliques, després del qual aquestes rèpliques de la nova versió es llancen en un pod nou i separat. Tanmateix, ha-proxy no en sap res i encara no els dirigeix cap càrrega de treball.
Per tant, en primer lloc, cal realitzar una comprovació del rendiment de les noves versions de la comprovació de l'estat per assegurar-se que les rèpliques estan preparades per atendre la càrrega.
Tots els components de desplegament han de suportar algun tipus de control de salut. Aquesta pot ser una comprovació de trucada HTTP molt senzilla, quan rebeu un codi amb l'estat 200, o una comprovació més aprofundida, en la qual comproveu la connexió de les rèpliques amb la base de dades i altres serveis, l'estabilitat de les connexions de l'entorn dinàmic. , i si tot comença i funciona correctament. Aquest procés pot ser bastant complex.
Després que el sistema verifiqui que totes les rèpliques actualitzades funcionen, Deployer actualitzarà la configuració i passarà la configuració correcta, que tornarà a configurar ha-proxy.
Només després d'això, el trànsit es dirigirà al pod amb rèpliques de la nova versió i el pod antic desapareixerà.
Aquest mecanisme no és una característica de Kubernetes. El concepte de desplegament blau/verd ha existit des de fa molt de temps i sempre ha utilitzat un equilibrador de càrrega. Primer, dirigeixes tot el trànsit a la versió antiga de l'aplicació i, després de l'actualització, el transfereixes completament a la nova versió. Aquest principi s'utilitza no només a Kubernetes.
Ara us presentaré un nou component de desplegament: Deployer, que realitza comprovacions de salut, reconfigura els servidors intermediaris, etc. Aquest és un concepte que no s'aplica al món exterior i que existeix dins de Kubernetes. Us mostraré com podeu crear el vostre propi concepte Deployer mitjançant eines de codi obert.
Per tant, el primer que fa Deployer és crear un controlador de replicació RC mitjançant l'API de Kubernetes. Aquesta API crea pods i serveis per a un posterior desplegament, és a dir, crea un clúster completament nou per a les nostres aplicacions. Tan bon punt RC estigui convençut que les rèpliques han començat, realitzarà una comprovació de la seva funcionalitat. Per fer-ho, Deployer utilitza l'ordre GET /health. Executa els components d'exploració adequats i comprova tots els elements que admeten el funcionament del clúster.
Després que tots els pods hagin informat del seu estat, Deployer crea un nou element de configuració: emmagatzematge distribuït etcd, que Kubernetes utilitza internament, inclòs l'emmagatzematge de la configuració de l'equilibrador de càrrega. Escrivim dades a etcd, i una petita eina anomenada confd monitors etcd per a dades noves.
Si detecta algun canvi a la configuració inicial, genera un nou fitxer de configuració i el transfereix a ha-proxy. En aquest cas, ha-proxy es reinicia sense perdre cap connexió i adreça la càrrega a nous serveis que permeten que la nova versió de les nostres aplicacions funcioni.
Com podeu veure, malgrat l'abundància de components, aquí no hi ha res complicat. Només heu de prestar més atenció a l'API i etcd. Vull parlar-vos del desplegador de codi obert que nosaltres mateixos fem servir: Amdatu Kubernetes Deployer.
És una eina per orquestrar desplegaments de Kubernetes i té les característiques següents:
- Desplegament blau/verd;
- configurar un equilibrador de càrrega extern;
- gestió del descriptor de desplegament;
- gestionar el desplegament real;
- comprovar la funcionalitat dels controls de salut durant el desplegament;
- implementació de variables d'entorn en pods.
Aquest Deployer es construeix a la part superior de l'API de Kubernetes i proporciona una API REST per gestionar les manetes i els desplegaments, així com una API de Websocket per a la transmissió de registres durant el procés de desplegament.
Col·loca les dades de configuració de l'equilibrador de càrrega a etcd, de manera que no cal que utilitzeu ha-proxy amb suport predefinit, sinó que utilitzeu fàcilment el vostre propi fitxer de configuració de l'equilibrador de càrrega. Amdatu Deployer està escrit a Go, com el mateix Kubernetes, i té la llicència d'Apache.
Abans de començar a utilitzar aquesta versió del desplegador, vaig utilitzar el descriptor de desplegament següent, que especifica els paràmetres que necessito.
Un dels paràmetres importants d'aquest codi és habilitar el senyalador "useHealthCheck". Hem d'especificar que s'ha de realitzar una comprovació de seny durant el procés de desplegament. Aquesta configuració es pot desactivar quan el desplegament utilitza contenidors de tercers que no s'han de verificar. Aquest descriptor també indica el nombre de rèpliques i l'URL d'interfície que necessita ha-proxy. Al final hi ha la marca d'especificació del pod "podspec", que truca a Kubernetes per obtenir informació sobre la configuració del port, la imatge, etc. Aquest és un descriptor JSON bastant senzill.
Una altra eina que forma part del projecte de codi obert Amdatu és Deploymentctl. Té una interfície d'usuari per configurar desplegaments, emmagatzema l'historial de desplegaments i conté webhooks per a les devolucions de trucades d'usuaris i desenvolupadors de tercers. És possible que no utilitzeu la interfície d'usuari, ja que Amdatu Deployer és una API REST, però aquesta interfície us pot facilitar el desplegament sense implicar cap API. Deploymentctl està escrit a OSGi/Vertx mitjançant Angular 2.
Ara demostraré l'anterior a la pantalla amb una gravació prèviament gravada perquè no hagis d'esperar. Desplegarem una senzilla aplicació Go. No us preocupeu si no heu provat Go abans, és una aplicació molt senzilla, així que hauríeu de poder esbrinar-la.
Aquí estem creant un servidor HTTP que només respon a /health, de manera que aquesta aplicació només prova la comprovació de salut i res més. Si la comprovació passa, s'utilitza l'estructura JSON que es mostra a continuació. Conté la versió de l'aplicació que desplegarà el desplegador, el missatge que veieu a la part superior del fitxer i el tipus de dades booleà, tant si la nostra aplicació funciona com si no.
Vaig enganyar una mica amb l'última línia, perquè vaig col·locar un valor booleà fix a la part superior del fitxer, que en el futur m'ajudarà a desplegar fins i tot una aplicació "no saludable". Ens ocuparem d'això més endavant.
Així que comencem. En primer lloc, comprovem la presència de pods en execució mitjançant l'ordre ~ kubectl get pods i, basant-nos en l'absència de resposta de l'URL del frontend, ens assegurem que no s'estan realitzant desplegaments.
A continuació, a la pantalla, veureu la interfície Deploymentctl que he esmentat, en la qual s'estableixen els paràmetres de desplegament: espai de noms, nom de l'aplicació, versió de desplegament, nombre de rèpliques, URL de front-end, nom del contenidor, imatge, límits de recursos, número de port per a la comprovació de salut, etc. Els límits de recursos són molt importants, ja que permeten utilitzar el màxim de maquinari possible. Aquí també podeu veure el registre de desplegament.
Si ara repeteixes l'ordre ~ kubectl get pods, podràs veure que el sistema "es congela" durant 20 segons, durant els quals es reconfigura el proxy ha. Després d'això, el pod s'inicia i la nostra rèplica es pot veure al registre de desplegament.
Vaig retallar l'espera de 20 segons del vídeo, i ara podeu veure a la pantalla que s'ha desplegat la primera versió de l'aplicació. Tot això es va fer utilitzant només la IU.
Ara provem la segona versió. Per fer-ho, canvio el missatge de l'aplicació de "Hola, Kubernetes!" a "Hola, Deployer!", el sistema crea aquesta imatge i la col·loca al registre de Docker, després de la qual cosa només cal que tornem a fer clic al botó "Desplega" a la finestra Deploymentctl. En aquest cas, el registre de desplegament s'inicia automàticament de la mateixa manera que va passar quan es va desplegar la primera versió de l'aplicació.
L'ordre ~ kubectl get pods mostra que actualment hi ha 2 versions de l'aplicació en execució, però la interfície mostra que encara estem executant la versió 1.
L'equilibrador de càrrega espera que finalitzi la comprovació de l'estat abans de redirigir el trànsit a la versió nova. Al cap de 20 segons, canviem a curl i veiem que ara tenim la versió 2 de l'aplicació desplegada i la primera s'ha eliminat.
Aquest va ser el desplegament d'una aplicació "saludable". A veure què passa si per a una nova versió de l'aplicació canvio el paràmetre Healthy de true a false, és a dir, intento desplegar una aplicació no saludable que ha fallat la comprovació de salut. Això pot passar si es van cometre alguns errors de configuració a l'aplicació en l'etapa de desenvolupament i es va enviar a producció d'aquesta forma.
Com podeu veure, el desplegament segueix tots els passos anteriors i ~kubectl get pods mostra que tots dos pods s'estan executant. Però a diferència del desplegament anterior, el registre mostra l'estat del temps d'espera. És a dir, pel fet que la comprovació de salut ha fallat, la nova versió de l'aplicació no es pot desplegar. Com a resultat, veus que el sistema ha tornat a utilitzar la versió antiga de l'aplicació i la nova versió simplement s'ha desinstal·lat.
El millor d'això és que, fins i tot si teniu un gran nombre de sol·licituds simultànies a l'aplicació, ni tan sols notaran el temps d'inactivitat mentre implementeu el procediment de desplegament. Si proveu aquesta aplicació utilitzant el marc de Gatling, que li envia tantes sol·licituds com sigui possible, no s'eliminarà cap d'aquestes sol·licituds. Això vol dir que els nostres usuaris ni tan sols notaran les actualitzacions de versions en temps real. Si falla, es continuarà treballant amb la versió antiga; si té èxit, els usuaris canviaran a la versió nova.
Només hi ha una cosa que pot fallar: si la comprovació de salut té èxit, però l'aplicació falla tan bon punt s'aplica la càrrega de treball, és a dir, el col·lapse només es produirà un cop finalitzada la implementació. En aquest cas, haureu de tornar manualment a la versió antiga. Per tant, vam veure com utilitzar Kubernetes amb les eines de codi obert dissenyades per a això. El procés de desplegament serà molt més fàcil si incorporeu aquestes eines a les vostres canalitzacions de compilació/implementació. Al mateix temps, per iniciar el desplegament, podeu utilitzar la interfície d'usuari o automatitzar completament aquest procés mitjançant, per exemple, commit to master.
El nostre servidor de compilació crearà una imatge de Docker, l'enviarà a Docker Hub o al registre que utilitzeu. Docker Hub admet webhook, de manera que podem activar el desplegament remot mitjançant Deployer de la manera que es mostra més amunt. D'aquesta manera podeu automatitzar completament el desplegament de la vostra aplicació a la producció potencial.
Passem al següent tema: escalar el clúster de Kubernetes. Tingueu en compte que l'ordre kubectl és una ordre d'escala. Amb més ajuda, podem augmentar fàcilment el nombre de rèpliques al nostre clúster existent. Tanmateix, a la pràctica, normalment volem augmentar el nombre de nodes en lloc de beines.
Al mateix temps, durant l'horari laboral és possible que hàgiu d'augmentar, i a la nit, per reduir el cost dels serveis d'Amazon, potser haureu de reduir el nombre d'instàncies d'aplicació en execució. Això no vol dir que n'hi haurà prou amb escalar només el nombre de beines, perquè encara que un dels nodes estigui inactiu, encara haureu de pagar a Amazon. És a dir, juntament amb l'escalada de les beines, haureu d'escalar el nombre de màquines utilitzades.
Això pot ser un repte perquè tant si fem servir Amazon com un altre servei al núvol, Kubernetes no sap res sobre el nombre de màquines que s'utilitzen. Falta una eina que us permeti escalar el sistema a nivell de node.
Així que haurem de tenir cura tant dels nodes com dels pods. Podem escalar fàcilment el llançament de nous nodes mitjançant l'API d'AWS i les màquines del grup Scaling per configurar el nombre de nodes de treball de Kubernetes. També podeu utilitzar cloud-init o un script similar per registrar nodes al clúster de Kubernetes.
La nova màquina s'inicia al grup Scaling, s'inicia com a node, es registra al registre del mestre i comença a funcionar. Després d'això, podeu augmentar el nombre de rèpliques per utilitzar-les als nodes resultants. La reducció de l'escala requereix més esforç, ja que cal assegurar-se que aquest pas no condueixi a la destrucció d'aplicacions que ja s'executen després d'apagar les màquines "innecessàries". Per evitar aquest escenari, heu de configurar els nodes a l'estat "no programable". Això vol dir que el planificador predeterminat ignorarà aquests nodes en programar pods de DaemonSet. El planificador no suprimirà res d'aquests servidors, però tampoc hi llançarà cap contenidor nou. El següent pas és expulsar el node de drenatge, és a dir, transferir els pods en execució d'aquest a una altra màquina, o a altres nodes que tinguin capacitat suficient per a això. Un cop us hàgiu assegurat que ja no hi ha contenidors en aquests nodes, podeu eliminar-los de Kubernetes. Després d'això, simplement deixaran d'existir per a Kubernetes. A continuació, heu d'utilitzar l'API d'AWS per desactivar nodes o màquines innecessàries.
Podeu utilitzar Amdatu Scalerd, una altra eina d'escala de codi obert similar a l'API d'AWS. Proporciona una CLI per afegir o eliminar nodes d'un clúster. La seva característica interessant és la possibilitat de configurar el planificador mitjançant el següent fitxer json.
El codi que es mostra redueix la capacitat del clúster a la meitat durant el període nocturn. Configura tant el nombre de rèpliques disponibles com la capacitat desitjada del clúster d'Amazon. L'ús d'aquest programador reduirà automàticament el nombre de nodes a la nit i els augmentarà al matí, estalviant el cost d'utilitzar nodes d'un servei al núvol com Amazon. Aquesta funció no està integrada a Kubernetes, però utilitzar Scalerd us permetrà escalar aquesta plataforma com vulgueu.
M'agradaria assenyalar que molta gent em diu: "Tot està bé, però què passa amb la meva base de dades, que normalment és estàtica?" Com podeu executar alguna cosa com això en un entorn dinàmic com Kubernetes? Al meu entendre, no hauríeu de fer això, no hauríeu d'intentar executar un magatzem de dades a Kubernetes. Això és tècnicament possible, i hi ha tutorials a Internet sobre aquest tema, però us complicarà seriosament la vida.
Sí, hi ha un concepte de botigues persistents a Kubernetes i podeu provar d'executar magatzems de dades com Mongo o MySQL, però aquesta és una tasca força intensa. Això es deu al fet que els magatzems de dades no admeten completament la interacció amb un entorn dinàmic. La majoria de bases de dades requereixen una configuració important, inclosa la configuració manual del clúster, no els agrada l'escala automàtica i altres coses semblants.
Per tant, no us hauríeu de complicar la vida intentant executar un magatzem de dades a Kubernetes. Organitzeu el seu treball de la manera tradicional utilitzant serveis familiars i simplement proporcioneu a Kubernetes la possibilitat d'utilitzar-los.
Per concloure el tema, m'agradaria presentar-vos la plataforma Cloud RTI basada en Kubernetes, en la qual està treballant el meu equip. Proporciona registre centralitzat, monitorització d'aplicacions i clústers, i moltes altres funcions útils que seran útils. Utilitza diverses eines de codi obert com Grafana per mostrar el seguiment.
Hi havia una pregunta sobre per què utilitzar l'equilibrador de càrrega ha-proxy amb Kubernetes. Bona pregunta perquè actualment hi ha 2 nivells d'equilibri de càrrega. Els serveis de Kubernetes encara resideixen en adreces IP virtuals. No els podeu utilitzar per a ports en màquines host externes perquè si Amazon sobrecarrega el seu amfitrió al núvol, l'adreça canviarà. És per això que col·loquem ha-proxy davant dels serveis, per crear una estructura més estàtica perquè el trànsit es comuniqui perfectament amb Kubernetes.
Una altra bona pregunta és com podeu fer-vos càrrec dels canvis d'esquema de la base de dades quan feu un desplegament blau/verd? El fet és que, independentment de l'ús de Kubernetes, canviar l'esquema de la base de dades és una tasca difícil. Heu d'assegurar-vos que l'esquema antic i el nou siguin compatibles, després podeu actualitzar la base de dades i, a continuació, actualitzar les aplicacions. Podeu intercanviar la base de dades en calent i després actualitzar les aplicacions. Conec persones que han engegat un clúster de bases de dades completament nou amb un esquema nou, aquesta és una opció si teniu una base de dades sense esquema com Mongo, però de totes maneres no és una tasca fàcil. Si no teniu més preguntes, gràcies per la vostra atenció!
Alguns anuncis 🙂
Gràcies per quedar-te amb nosaltres. T'agraden els nostres articles? Vols veure més contingut interessant? Doneu-nos suport fent una comanda o recomanant als amics, , un anàleg únic dels servidors d'entrada, que vam inventar per a vosaltres: (disponible amb RAID1 i RAID10, fins a 24 nuclis i fins a 40 GB DDR4).
Dell R730xd 2 vegades més barat al centre de dades Equinix Tier IV a Amsterdam? Només aquí als Països Baixos! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB - a partir de 99 $! Llegeix sobre
Font: www.habr.com