Un punt important en el funcionament dels sistemes distribuïts és la gestió de fallades. Kubernetes ajuda amb això utilitzant controladors que supervisen l'estat del vostre sistema i reinicien els serveis que han deixat de funcionar. Tanmateix, Kubernetes pot aturar les vostres aplicacions de manera forçada per garantir la salut general del sistema. En aquesta sèrie, veurem com podeu ajudar Kubernetes a fer la seva feina de manera més eficient i reduir el temps d'inactivitat de les aplicacions.
Abans dels contenidors, la majoria de les aplicacions s'executaven en màquines virtuals o físiques. Si l'aplicació es va bloquejar o es va bloquejar, va trigar molt de temps a cancel·lar la tasca en curs i tornar a carregar el programa. En el pitjor dels casos, algú havia de resoldre aquest problema manualment a la nit, a les hores més inoportunes. Si només 1-2 màquines de treball fessin una tasca important, aquesta interrupció era completament inacceptable.
Per tant, en comptes de reinicis manuals, van començar a utilitzar la supervisió a nivell de procés per reiniciar automàticament l'aplicació en cas d'una terminació anormal. Si el programa falla, el procés de supervisió captura el codi de sortida i reinicia el servidor. Amb l'arribada de sistemes com Kubernetes, aquest tipus de resposta als errors del sistema simplement es va integrar a la infraestructura.
Kubernetes utilitza un bucle d'esdeveniments d'observació-diferència-acció-acció per garantir que els recursos es mantenen saludables mentre viatgen des dels contenidors als mateixos nodes.
Això vol dir que ja no cal que executeu manualment la supervisió del procés. Si un recurs falla la comprovació de salut, Kubernetes simplement el subministrarà automàticament amb un substitut. Tanmateix, Kubernetes fa molt més que supervisar la vostra aplicació per detectar errors. Pot crear més còpies de l'aplicació per executar-les en diverses màquines, actualitzar l'aplicació o executar diverses versions de l'aplicació simultàniament.
Per tant, hi ha moltes raons per les quals Kubernetes pot acabar amb un contenidor perfectament saludable. Per exemple, si actualitzeu la vostra implementació, Kubernetes aturarà lentament els pods antics mentre n'inicieu de nous. Si tanqueu un node, Kubernetes deixarà d'executar tots els pods d'aquest node. Finalment, si un node es queda sense recursos, Kubernetes tancarà tots els pods per alliberar aquests recursos.
Per tant, és fonamental que la vostra aplicació finalitzi amb un impacte mínim per a l'usuari final i un temps de recuperació mínim. Això vol dir que abans d'apagar-se, ha de desar totes les dades que cal desar, tancar totes les connexions de xarxa, completar el treball restant i gestionar altres tasques urgents.
A la pràctica, això vol dir que la vostra aplicació ha de ser capaç de gestionar el missatge SIGTERM, el senyal de finalització del procés que és el senyal predeterminat per a la utilitat de matança als sistemes operatius Unix. En rebre aquest missatge, l'aplicació s'hauria de tancar.
Una vegada que Kubernetes decideix finalitzar un pod, es produeixen diversos esdeveniments. Vegem cada pas que fa Kubernetes quan tanca un contenidor o beina.
Suposem que volem cancel·lar una de les beines. En aquest moment, deixarà de rebre trànsit nou; els contenidors que s'executen al pod no es veuran afectats, però tot el trànsit nou es bloquejarà.
Vegem el ganxo preStop, que és una ordre especial o una sol·licitud HTTP que s'envia als contenidors d'un pod. Si la vostra aplicació no es tanca correctament quan rebeu SIGTERM, podeu utilitzar preStop per tancar correctament.
La majoria dels programes sortiran amb gràcia quan rebin un senyal SIGTERM, però si utilitzeu codi de tercers o algun sistema que no controleu completament, el ganxo preStop és una manera fantàstica de forçar un tancament elegant sense canviar l'aplicació.
Després d'executar aquest ganxo, Kubernetes enviarà un senyal SIGTERM als contenidors del pod, fent-los saber que aviat es desconnectaran. En rebre aquest senyal, el vostre codi procedirà al procés d'apagada. Aquest procés pot incloure aturar qualsevol connexió de llarga durada, com ara una connexió de base de dades o un flux WebSocket, desar l'estat actual i similars.
Fins i tot si utilitzeu un ganxo preStop, és molt important comprovar què passa exactament amb la vostra aplicació quan li envieu un senyal SIGTERM i com es comporta, de manera que els esdeveniments o els canvis en el funcionament del sistema causats per l'aturada del pod no es produeixin. una sorpresa per a tu.
En aquest punt, Kubernetes esperarà un període de temps especificat, anomenat terminationGracePeriodSecond, o el període per tancar-se amb gràcia quan rep un senyal SIGTERM, abans de prendre més accions.
Per defecte, aquest període és de 30 segons. És important tenir en compte que funciona en paral·lel amb el ganxo preStop i el senyal SIGTERM. Kubernetes no esperarà que finalitzi el ganxo preStop i SIGTERM; si la vostra aplicació surt abans que finalitzi el TerminationGracePeriod, Kubernetes passarà immediatament al pas següent. Per tant, comproveu que el valor d'aquest període en segons no sigui inferior al temps necessari per apagar correctament el pod i, si supera els 30 segons, augmenta el període fins al valor desitjat a YAML. En l'exemple donat, és dels anys 60.
I, finalment, l'últim pas és que si els contenidors segueixen funcionant després de la terminació de GracePeriod, enviaran un senyal SIGKILL i s'eliminaran per la força. En aquest punt, Kubernetes també netejarà tots els altres objectes de pod.
Kubernetes finalitza els pods per molts motius, així que assegureu-vos que la vostra aplicació finalitzi amb gràcia en qualsevol cas per garantir un servei estable.
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