Kubernetes: a vida de uma lareira

Nota perev. : Este artigo pequeno (mas espaçoso!), Escrito por Michael Hausenblas, da equipe OpenShift da Red Hat, gostou tanto que foi adicionado à nossa base de conhecimento interna do Kubernetes quase imediatamente após sua descoberta. E como as informações apresentadas serão obviamente úteis para a comunidade de TI de língua russa, estamos felizes em publicar sua tradução.



Como você pode imaginar, o título desta publicação é uma referência ao desenho animado da Pixar de 1998, “A Bug's Life” (nas bilheterias russas, era chamado de “Adventures of Flick” ou “Life of an Insect” - aproximadamente tradução ) . Kubernetes tem muito em comum com trabalhadores e lares. Analisaremos cuidadosamente o ciclo de vida completo da lareira do ponto de vista prático - em particular, as maneiras pelas quais você pode influenciar o comportamento na inicialização e desligamento, bem como as abordagens corretas para verificar o status do aplicativo.

Independentemente de você ter criado sob você mesmo ou, melhor ainda, através de um controlador como Deployment , DaemonSet ou StatefulSet , under pode estar em uma das seguintes fases:

• Pendente : o servidor da API criou um recurso de pod e o salvou no etcd, mas ainda não foi planejado e as imagens de seus contêineres não foram recebidas do registro;
• Em execução (em funcionamento): under foi atribuído ao nó e todos os contêineres foram criados pelo kubelet ;
• Sucedido (concluído com sucesso): a operação de todos os contêineres da lareira foi concluída com êxito e eles não serão reiniciados;
• Falha : todos os contêineres na lareira pararam de funcionar e pelo menos um dos contêineres falhou;
• Desconhecido : o servidor de API não conseguiu consultar o status da lareira, geralmente devido a um erro ao interagir com o kubelet .

Ao executar o kubectl get pod , observe que a coluna STATUS pode mostrar outras (exceto essas cinco) mensagens - por exemplo, Init:0/1 ou CrashLoopBackOff . Isso ocorre porque a fase é apenas parte do estado geral da lareira. Uma boa maneira de descobrir o que exatamente aconteceu é executar o kubectl describe pod/$PODNAME e veja a entrada kubectl describe pod/$PODNAME Events: abaixo. Ela exibe uma lista de ações relevantes: que a imagem do contêiner foi recebida, foi planejada, o contêiner está em um estado "íntegro" .

Agora dê uma olhada em um exemplo específico do ciclo de vida de uma lareira do início ao fim, conforme mostrado no diagrama a seguir:



O que aconteceu aqui? Os passos são os seguintes:

1. Isso não é mostrado no diagrama, mas, no início, um infra-contêiner especial é iniciado e configura os espaços de nomes aos quais os contêineres restantes se unem.
2. O primeiro contêiner definido pelo usuário que inicia é o contêiner init ; pode ser usado para tarefas de inicialização.
3. Em seguida, o contêiner principal e o gancho pós-partida são lançados simultaneamente; no nosso caso, isso acontece após 4 segundos. Ganchos são definidos para cada contêiner.
4. Então, no sétimo segundo, os testes de vivacidade e prontidão entram em cena novamente para cada contêiner.
5. No 11º segundo, quando o abate é eliminado, um gancho de parada é acionado e o contêiner principal é eliminado após um período de carência . Observe que, na realidade, o processo de conclusão do pod é um pouco mais complicado.

Como cheguei à sequência acima e ao seu tempo? Para fazer isso, usamos a seguinte implantação , criada especificamente para rastrear a ordem dos eventos (não é muito útil por si só):

 kind: Deployment apiVersion: apps/v1beta1 metadata: name: loap spec: replicas: 1 template: metadata: labels: app: loap spec: initContainers: - name: init image: busybox command: ['sh', '-c', 'echo $(date +%s): INIT >> /loap/timing'] volumeMounts: - mountPath: /loap name: timing containers: - name: main image: busybox command: ['sh', '-c', 'echo $(date +%s): START >> /loap/timing; sleep 10; echo $(date +%s): END >> /loap/timing;'] volumeMounts: - mountPath: /loap name: timing livenessProbe: exec: command: ['sh', '-c', 'echo $(date +%s): LIVENESS >> /loap/timing'] readinessProbe: exec: command: ['sh', '-c', 'echo $(date +%s): READINESS >> /loap/timing'] lifecycle: postStart: exec: command: ['sh', '-c', 'echo $(date +%s): POST-START >> /loap/timing'] preStop: exec: command: ['sh', '-c', 'echo $(date +%s): PRE-HOOK >> /loap/timing'] volumes: - name: timing hostPath: path: /tmp/loap 

Observe que, para desligar o pod com força quando o contêiner principal estava funcionando, executei o seguinte comando:

 $ kubectl scale deployment loap --replicas=0 

Observamos uma sequência específica de eventos em ação e agora estamos prontos para seguir em frente - para práticas no campo do gerenciamento do ciclo de vida da lareira. Eles são os seguintes:

• Use recipientes init para preparar a lareira para a operação normal. Por exemplo, para obter dados externos, crie tabelas no banco de dados ou aguarde a disponibilidade do serviço do qual depende. Se necessário, você pode criar muitos contêineres init e todos eles devem ser concluídos com êxito antes do lançamento de contêineres regulares.
• Sempre adicione livenessProbe e readinessProbe . O primeiro é usado pelo kubelet 'ohm para entender se e quando reiniciar o contêiner e a implantação ' ohm para decidir se a atualização sem interrupção foi bem-sucedida. O segundo é usado pelo serviço para decidir a direção do tráfego para o submarino. Se essas amostras não forem definidas, o kubelet para ambas assume que elas foram concluídas com êxito. Isso leva a duas consequências: a) a política de reinicialização não pode ser aplicada; b) os contêineres na lareira recebem instantaneamente o tráfego do serviço que estão enfrentando e mesmo se ainda estiverem ocupados com o processo de inicialização.
• Use ganchos para inicializar adequadamente o contêiner e destruí-lo completamente. Por exemplo, isso é útil no caso de funcionamento de um aplicativo cujo código fonte você não tem acesso ou não pode modificar, mas que requer alguma inicialização ou preparação para a conclusão - por exemplo, limpando as conexões com o banco de dados. Observe que, ao usar o serviço , o desligamento do servidor de API, do controlador de terminal e do kube-proxy pode levar algum tempo (por exemplo, excluindo as entradas correspondentes das tabelas de ip). Portanto, o término do seu trabalho pode afetar as solicitações de aplicativos. Freqüentemente, para resolver esse problema, basta um gancho simples com uma chamada de suspensão.
• Para necessidades de depuração e para entender em geral por que parou de funcionar, o aplicativo pode gravar em /dev/termination-log , e você pode ver as mensagens usando o kubectl describe pod … Essas configurações padrão são alteradas por meio de terminationMessagePath e / ou usando terminationMessagePolicy na subespecificação - consulte a referência da API para obter mais detalhes.

Esta publicação não discute inicializadores (alguns detalhes sobre eles podem ser encontrados no final deste material - aprox. Transl. ) . Este é um conceito completamente novo introduzido no Kubernetes 1.7. Os inicializadores trabalham dentro do plano de controle (API Server) em vez de estarem no contexto kubelet e podem ser usados ​​para enriquecer os lares, por exemplo, com contêineres laterais ou imposição de políticas de segurança. Além disso, os PodPresets não foram considerados, que no futuro podem ser substituídos por um conceito mais flexível de inicializadores.

PS do tradutor

Leia também em nosso blog:

• “O que acontece no Kubernetes quando o kubectl run é iniciado?”: Parte 1 e Parte 2 ;
• " Como o agendador Kubernetes realmente funciona?" ";
• “ Guia Ilustrado de Rede em Kubernetes ”;
• “ Nossa experiência com o Kubernetes em pequenos projetos ” (reportagem em vídeo, que inclui uma introdução ao dispositivo técnico do Kubernetes);
• “ Brinque com o Kubernetes - um serviço para familiarizar-se com os K8s ”;
• " Infraestrutura com o Kubernetes como um serviço acessível ."