Un punto importante no funcionamento dos sistemas distribuídos é a xestión de fallos. Kubernetes axuda con isto empregando controladores que supervisan o estado do teu sistema e reinician os servizos que deixaron de funcionar. Non obstante, Kubernetes pode deter as túas aplicacións por forza para garantir o estado xeral do sistema. Nesta serie, analizaremos como podes axudar a Kubernetes a facer o seu traballo de forma máis eficiente e reducir o tempo de inactividade das aplicacións.
Antes dos contedores, a maioría das aplicacións funcionaban en máquinas virtuais ou físicas. Se a aplicación fallaba ou conxelaba, tardou moito tempo en cancelar a tarefa en curso e volver cargar o programa. No peor dos casos, alguén tiña que resolver este problema manualmente pola noite, nas horas máis inoportunas. Se só 1-2 máquinas de traballo realizasen unha tarefa importante, tal interrupción era completamente inaceptable.
Polo tanto, en lugar de reinicios manuais, comezaron a utilizar a supervisión a nivel de proceso para reiniciar automaticamente a aplicación en caso de terminación anormal. Se o programa falla, o proceso de monitorización captura o código de saída e reinicia o servidor. Coa chegada de sistemas como Kubernetes, este tipo de resposta aos fallos do sistema simplemente integrouse na infraestrutura.
Kubernetes utiliza un bucle de eventos de observación-diferenza-tomar acción para garantir que os recursos permanecen saudables mentres viaxan desde os contedores ata os propios nodos.
Isto significa que xa non precisa executar manualmente o seguimento do proceso. Se un recurso falla na comprobación de estado, Kubernetes simplemente aprovisionalo automaticamente cun substituto. Non obstante, Kubernetes fai moito máis que supervisar a túa aplicación para detectar fallos. Pode crear máis copias da aplicación para executala en varias máquinas, actualizar a aplicación ou executar varias versións da súa aplicación á vez.
Polo tanto, hai moitas razóns polas que Kubernetes pode cancelar un contedor perfectamente saudable. Por exemplo, se actualizas a túa implementación, Kubernetes deixará lentamente os pods antigos mentres inicia outros novos. Se apagas un nodo, Kubernetes deixará de executar todos os pods nese nodo. Finalmente, se un nodo queda sen recursos, Kubernetes pechará todos os pods para liberar eses recursos.
Polo tanto, é fundamental que a súa aplicación remate cun impacto mínimo para o usuario final e un tempo de recuperación mínimo. Isto significa que antes de apagarse, debe gardar todos os datos que se deben gardar, pechar todas as conexións de rede, completar o traballo restante e xestionar outras tarefas urxentes.
Na práctica, isto significa que a súa aplicación debe ser capaz de xestionar a mensaxe SIGTERM, o sinal de terminación do proceso que é o sinal predeterminado para a utilidade de matar nos sistemas operativos Unix. Ao recibir esta mensaxe, a aplicación debería pecharse.
Unha vez que Kubernetes decide finalizar un pod, ocorren unha serie de eventos. Vexamos cada paso que fai Kubernetes ao apagar un contedor ou un pod.
Digamos que queremos finalizar unha das vainas. Neste momento, deixará de recibir tráfico novo: os contedores que se executan no pod non se verán afectados, pero bloquearase todo o tráfico novo.
Vexamos o gancho preStop, que é un comando especial ou solicitude HTTP que se envía aos contedores dun pod. Se a túa aplicación non se apaga correctamente ao recibir SIGTERM, podes usar preStop para apagala correctamente.
A maioría dos programas sairán con gracia cando reciben un sinal SIGTERM, pero se estás a usar código de terceiros ou algún sistema que non controlas por completo, o gancho preStop é unha boa forma de forzar un apagado elegante sen cambiar a aplicación.
Despois de executar este gancho, Kubernetes enviará un sinal SIGTERM aos contedores da vaina, facéndolles saber que pronto se desconectarán. Ao recibir este sinal, o teu código procederá ao proceso de apagado. Este proceso pode incluír deter as conexións de longa duración, como unha conexión de base de datos ou un fluxo de WebSocket, gardar o estado actual e similares.
Aínda que uses un gancho preStop, é moi importante comprobar que ocorre exactamente coa túa aplicación cando lle envías un sinal SIGTERM e como se comporta, para que os eventos ou cambios no funcionamento do sistema causados por un apagado do pod non se produzan. unha sorpresa para ti.
Neste punto, Kubernetes agardará durante un período de tempo especificado, chamado terminationGracePeriodSecond, ou o período para apagar correctamente cando reciba un sinal SIGTERM, antes de emprender máis accións.
Por defecto, este período é de 30 segundos. É importante ter en conta que funciona en paralelo co gancho preStop e co sinal SIGTERM. Kubernetes non esperará a que rematen o gancho preStop e SIGTERM; se a súa aplicación pecha antes de que remate o TerminationGracePeriod, Kubernetes pasará inmediatamente ao seguinte paso. Polo tanto, comprobe que o valor deste período en segundos non sexa inferior ao tempo necesario para apagar correctamente o pod e, se supera os 30 segundos, aumente o período ata o valor desexado en YAML. No exemplo dado, son anos 60.
E, finalmente, o último paso é que se os contedores aínda están funcionando despois da terminaciónGracePeriod, enviarán un sinal SIGKILL e eliminaranse pola forza. Neste punto, Kubernetes tamén limpará todos os outros obxectos de pod.
Kubernetes finaliza os pods por moitos motivos, polo que asegúrate de que a túa aplicación remate con gracia en calquera caso para garantir un servizo estable.
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