Els sistemes distribuïts poden ser difícils de gestionar perquè tenen molts elements mòbils i canviants que han de funcionar correctament perquè el sistema funcioni. Si algun dels elements falla, el sistema l'ha de detectar, saltar-lo i arreglar-lo, i tot això s'ha de fer automàticament. En aquesta sèrie de bones pràctiques de Kubernetes, aprendrem a configurar proves de preparació i vivacitat per provar l'estat d'un clúster de Kubernetes.
Health Check és una manera senzilla de fer saber al sistema si la vostra instància d'aplicació s'està executant o no. Si la vostra instància d'aplicació està inactiva, altres serveis no hi haurien d'accedir ni enviar-li sol·licituds. En canvi, la sol·licitud s'ha d'enviar a una altra instància de l'aplicació que ja s'està executant o que s'iniciarà més endavant. A més, el sistema hauria de restaurar la funcionalitat perduda de la vostra aplicació.
De manera predeterminada, Kubernetes començarà a enviar trànsit a un pod quan s'estiguin executant tots els contenidors dels pods i reiniciarà els contenidors quan es bloquegin. Aquest comportament predeterminat del sistema pot ser prou bo per començar, però podeu millorar la fiabilitat del desplegament del vostre producte utilitzant comprovacions personalitzades.
Afortunadament, Kubernetes fa que això sigui bastant fàcil de fer, de manera que no hi ha excusa per ignorar aquestes comprovacions. Kubernetes ofereix dos tipus de controls de salut, i és important entendre les diferències en com s'utilitza cadascun.
La prova de preparació està dissenyada per dir a Kubernetes que la vostra aplicació està preparada per gestionar el trànsit. Abans de permetre que un servei enviï trànsit a un pod, Kubernetes ha de verificar que la comprovació de preparació té èxit. Si la prova de Preparació falla, Kubernetes deixarà d'enviar trànsit al pod fins que la prova passi.
La prova de Liveness indica a Kubernetes si la vostra aplicació està activa o inactiva. En el primer cas, Kubernetes el deixarà sol, en el segon esborrarà el pod mort i el substituirà per un de nou.
Imaginem un escenari en què la vostra aplicació triga 1 minut a escalfar-se i llançar-se. El vostre servei no començarà a funcionar fins que l'aplicació estigui completament carregada i en funcionament, tot i que el flux de treball ja s'ha iniciat. També tindreu problemes si voleu ampliar aquest desplegament a diverses còpies, perquè aquestes còpies no haurien de rebre trànsit fins que no estiguin completament a punt. Tanmateix, de manera predeterminada, Kubernetes començarà a enviar trànsit tan bon punt comencen els processos dins del contenidor.
Quan utilitzeu la prova de preparació, Kubernetes esperarà fins que l'aplicació s'executi completament abans de permetre que el servei enviï trànsit a la còpia nova.
Imaginem un altre escenari en què l'aplicació es penja durant molt de temps, deixant de sol·licitar servei. A mesura que el procés continua executant-se, Kubernetes assumirà per defecte que tot està bé i continuarà enviant sol·licituds al pod que no funciona. Però quan utilitzeu Liveness, Kubernetes detectarà que l'aplicació ja no atén sol·licituds i reiniciarà el pod mort de manera predeterminada.
Vegem com es posen a prova la preparació i la viabilitat. Hi ha tres mètodes de prova: HTTP, Command i TCP. Podeu utilitzar qualsevol d'ells per comprovar-ho. La forma més habitual de provar un usuari és una sonda HTTP.
Encara que la vostra aplicació no sigui un servidor HTTP, podeu crear un servidor HTTP lleuger dins de la vostra aplicació per interactuar amb la prova de Liveness. Després d'això, Kubernetes començarà a fer ping al pod, i si la resposta HTTP es troba en l'interval de 200 o 300 ms, indicarà que el pod està en bon estat. En cas contrari, el mòdul es marcarà com a "poc saludable".
Per a les proves d'ordres, Kubernetes executa l'ordre dins del contenidor. Si l'ordre torna amb un codi de sortida zero, el contenidor es marcarà com a saludable, en cas contrari, en rebre un número d'estat de sortida de l'1 al 255, el contenidor es marcarà com a "malalt". Aquest mètode de prova és útil si no podeu o no voleu executar un servidor HTTP, però podeu executar una ordre que comprovarà la salut de la vostra aplicació.
El mecanisme de verificació final és la prova TCP. Kubernetes intentarà establir una connexió TCP al port especificat. Si això es pot fer, l'envàs es considera saludable; si no, es considera inviable. Aquest mètode pot ser útil si utilitzeu un escenari en què les proves amb una sol·licitud HTTP o l'execució d'ordres no funcionen molt bé. Per exemple, els principals serveis de verificació mitjançant TCP serien gRPC o FTP.
Les proves es poden configurar de diverses maneres amb diferents paràmetres. Podeu especificar amb quina freqüència s'han d'executar, quins són els llindars d'èxit i fracàs i quant de temps cal esperar per a les respostes. Per obtenir més informació, consulteu la documentació de les proves de Preparació i Viva. Tanmateix, hi ha un punt molt important a l'hora de configurar la prova de Liveness: la configuració inicial del retard de prova initialDelaySeconds. Com he esmentat, el fracàs d'aquesta prova farà que el mòdul es reiniciï. Per tant, heu d'assegurar-vos que les proves no s'iniciïn fins que l'aplicació estigui a punt per funcionar, en cas contrari, començarà a reiniciar-se. Recomano utilitzar el temps d'inici P99 o el temps mitjà d'inici de l'aplicació des de la memòria intermèdia. Recordeu ajustar aquest valor a mesura que el temps d'inici de la vostra aplicació sigui més ràpid o més lent.
La majoria dels experts confirmaran que les comprovacions de salut són una comprovació obligatòria per a qualsevol sistema distribuït i que Kubernetes no és una excepció. L'ús de comprovacions d'estat del servei garanteix un funcionament fiable i sense problemes de Kubernetes i és fàcil per als usuaris.
Continuarà molt aviat...
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