Os sistemas distribuídos poden ser difíciles de xestionar porque teñen moitos elementos en movemento e cambiantes que todos necesitan funcionar correctamente para que o sistema funcione. Se un dos elementos falla, o sistema debe detectalo, evitalo e arranxalo, e todo isto debe facerse de forma automática. Nesta serie de prácticas recomendadas de Kubernetes, aprenderemos a configurar as probas de preparación e vivacidade para comprobar o estado dun clúster de Kubernetes.
A comprobación de saúde é unha forma sinxela de informar ao sistema se a instancia da aplicación se está executando ou non. Se a túa instancia de aplicación está inactiva, outros servizos non deberían acceder a ela nin enviarlle solicitudes. Pola contra, a solicitude debe enviarse a outra instancia da aplicación que xa estea en execución ou que se lanzará máis tarde. Ademais, o sistema debería restaurar a funcionalidade perdida da súa aplicación.
De forma predeterminada, Kubernetes comezará a enviar tráfico a un pod cando todos os contedores dos pods estean en execución e reiniciará os contenedores cando fallan. Este comportamento predeterminado do sistema pode ser o suficientemente bo para comezar, pero pode mellorar a fiabilidade da implantación do seu produto mediante comprobacións de cordura personalizadas.
Afortunadamente, Kubernetes fai que isto sexa bastante sinxelo, polo que non hai escusa para ignorar estas comprobacións. Kubernetes ofrece dous tipos de comprobacións de saúde e é importante comprender as diferenzas na forma en que se usa cada unha.
A proba de preparación está deseñada para indicarlle a Kubernetes que a túa aplicación está lista para xestionar o tráfico. Antes de permitir que un servizo envíe tráfico a un pod, Kubernetes debe verificar que a comprobación de preparación teña éxito. Se a proba de preparación falla, Kubernetes deixará de enviar tráfico ao pod ata que pase a proba.
A proba de Liveness indica a Kubernetes se a túa aplicación está activa ou morta. No primeiro caso, Kubernetes deixarao só, no segundo eliminará a vaina morta e substituirase por unha nova.
Imaxinemos un escenario no que a túa aplicación tarda 1 minuto en quentar e lanzar. O teu servizo non comezará a funcionar ata que a aplicación estea completamente cargada e funcionando, aínda que o fluxo de traballo xa comezou. Tamén terás problemas se queres ampliar esta implementación a varias copias, porque esas copias non deberían recibir tráfico ata que estean completamente listas. Non obstante, de forma predeterminada, Kubernetes comezará a enviar tráfico tan pronto como se inicien os procesos dentro do contedor.
Ao usar a proba de preparación, Kubernetes agardará ata que a aplicación estea a executarse completamente antes de permitir que o servizo envíe tráfico á nova copia.
Imaxinemos outro escenario no que a aplicación se colga durante moito tempo, deixando de atender solicitudes. A medida que o proceso continúa a executarse, Kubernetes asumirá de forma predeterminada que todo está ben e seguirá enviando solicitudes ao pod que non funciona. Pero ao usar Liveness, Kubernetes detectará que a aplicación xa non está atendendo solicitudes e reiniciará o pod morto de forma predeterminada.
Vexamos como se proba a preparación e a viabilidade. Hai tres métodos de proba: HTTP, Command e TCP. Podes usar calquera deles para comprobar. A forma máis común de probar un usuario é unha sonda HTTP.
Aínda que a túa aplicación non sexa un servidor HTTP, aínda podes crear un servidor HTTP lixeiro dentro da túa aplicación para interactuar coa proba de Liveness. Despois diso, Kubernetes comezará a facer ping ao pod e, se a resposta HTTP está no intervalo de 200 ou 300 ms, indicará que o pod está saudable. En caso contrario, o módulo marcarase como "non saudable".
Para as probas de comandos, Kubernetes executa o comando dentro do teu contedor. Se o comando volve cun código de saída cero, entón o contedor marcarase como saudable; se non, ao recibir un número de estado de saída do 1 ao 255, o contedor marcarase como "enfermo". Este método de proba é útil se non pode ou non quere executar un servidor HTTP, pero pode executar un comando que comprobará o estado da súa aplicación.
O mecanismo de verificación final é a proba TCP. Kubernetes tentará establecer unha conexión TCP no porto especificado. Se isto se pode facer, o recipiente considérase saudable; se non, considérase inviable. Este método pode ser útil se está a usar un escenario no que as probas cunha solicitude HTTP ou a execución de comandos non funcionan moi ben. Por exemplo, os principais servizos de verificación mediante TCP serían gRPC ou FTP.
As probas pódense configurar de varias maneiras con diferentes parámetros. Podes especificar a frecuencia con que se deben executar, cales son os limiares de éxito e fracaso e canto tempo hai que esperar ás respostas. Para obter máis información, consulte a documentación das probas de preparación e vivacidade. Non obstante, hai un punto moi importante na configuración da proba de Liveness: a configuración inicial do retardo da proba initialDelaySeconds. Como mencionei, o fallo desta proba fará que o módulo se reinicie. Polo tanto, cómpre asegurarse de que as probas non se inician ata que a aplicación estea lista para funcionar, se non, comezará a reiniciarse. Recomendo usar o tempo de inicio do P99 ou o tempo medio de inicio da aplicación do búfer. Lembra axustar este valor xa que o tempo de inicio da túa aplicación vaise máis rápido ou máis lento.
A maioría dos expertos confirmarán que os controles de saúde son obrigatorios para calquera sistema distribuído e Kubernetes non é unha excepción. O uso das comprobacións de estado do servizo garante un funcionamento fiable e sen problemas de Kubernetes e resulta sen esforzo para os usuarios.
Para continuar moi pronto...
Algúns anuncios 🙂
Grazas por estar connosco. Gústanche os nosos artigos? Queres ver máis contido interesante? Apóyanos facendo un pedido ou recomendando a amigos, , un análogo único de servidores de nivel de entrada, que inventamos nós para ti: (dispoñible con RAID1 e RAID10, ata 24 núcleos e ata 40 GB DDR4).
Dell R730xd 2 veces máis barato no centro de datos Equinix Tier IV en Amsterdam? Só aquí nos Países Baixos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - desde $ 99! Ler sobre
Fonte: www.habr.com