Como reiniciar pods do Kubernetes com Kubectl

o_m / Shutterstock. com

Os pods do Kubernetes devem operar sem intervenção, mas às vezes você pode ter um problema em que um contêiner não está funcionando como deveria. Reiniciar o pod pode ajudar a restaurar as operações ao normal.

O Kubectl não tem uma maneira direta de reiniciar pods individuais. Os pods devem permanecer em execução até que sejam substituídos como parte de sua rotina de implantação. Normalmente, é quando você lança uma nova versão da imagem do contêiner.

Aqui estão algumas técnicas que você pode usar quando quiser reiniciar os pods sem construir uma nova imagem ou executar o pipeline de CI. Eles podem ajudar quando você acha que um novo conjunto de contêineres colocará sua carga de trabalho em execução novamente.

Escalonamento da contagem de réplicas

Embora não haja nenhuma reinicialização do kubectl, você pode conseguir algo semelhante dimensionando o número de réplicas de contêiner que você &’ está executando. Isso funciona quando seu pod faz parte de um Deployment, StatefulSet, ReplicaSet ou Replication Controller.

 implantação da escala kubectl my-deployment --replicas = 0 implantação da escala kubectl my-deployment --replicas = 3 

Reduzir a sua implantação para 0 removerá todos os seus pods existentes. Espere até que os pods tenham sido encerrados, usando kubectl get pods para verificar seus status, em seguida, redimensione a implantação de volta para a contagem de réplicas pretendida. O Kubernetes criará novos pods com novas instâncias de contêiner.

Reinícios sem tempo com implantações

O ajuste manual da contagem de réplicas tem uma limitação: reduzir para 0 criará um período de inatividade em que não haverá pods disponíveis para atender aos usuários. Uma opção alternativa é iniciar uma reinicialização contínua, que permite substituir um conjunto de pods sem tempo de inatividade. Ele está disponível com o Kubernetes v1.15 e posterior.

 kubectl rollout restart deployment my-deployment 

Publicidade

Ao executar este comando, o Kubernetes encerrará e substituirá gradualmente seus pods, garantindo que alguns contêineres permaneçam operacionais o tempo todo. A natureza em fases do lançamento permite que você continue atendendo aos clientes enquanto efetivamente “ reinicia ” seus pods nos bastidores.

Após a conclusão da implementação, você &’ terá o mesmo número de réplicas de antes, mas cada contêiner será uma nova instância. Você pode verificar o status da implementação usando kubectl get pods para listar os pods e observar como eles são substituídos. Também há kubectl rollout status deployment / my-deployment que também mostra o progresso atual.

A implementação do kubectl funciona com Deployments, DaemonSets e StatefulSets. Na maioria das vezes, essa deve ser sua opção preferida quando você deseja encerrar seus contêineres e iniciar imediatamente novos.

(Ab) usando ReplicaSet Monitoring

Quando o seu pod faz parte de um ReplicaSet ou implantação, você pode iniciar uma substituição simplesmente excluindo-o. O ReplicaSet notará que o pod desapareceu à medida que o número de instâncias de contêiner cairá abaixo da contagem de réplicas de destino.

 kubectl delete pod my-pod 

O ReplicaSet intervirá para restaurar o nível mínimo de disponibilidade. Ele criará automaticamente um novo pod, iniciando um novo contêiner para substituir o antigo.

Publicidade

Este é tecnicamente um efeito colateral – é melhor usar os comandos de escala ou rollout, que são mais explícitos e projetados para este caso de uso. No entanto, as exclusões manuais podem ser uma técnica útil se você souber a identidade de um único pod com comportamento incorreto dentro de um ReplicaSet ou implantação. Uma implementação substituiria todos os pods gerenciados, não apenas aquele que apresenta uma falha.

Você pode expandir a técnica para substituir todos os pods com falha usando um único comando:

 kubectl delete pods --field-selector = status. phase = Failed 

Todos os pods no estado de falha serão encerrados e removidos. O controlador de replicação notará a discrepância e adicionará novos pods para mover o estado de volta para a contagem de réplicas configurada. Se você tiver certeza de que os pods antigos falharam devido a um erro temporário, os novos devem continuar funcionando em um estado íntegro.

Alteração das anotações do pod

Outra maneira de forçar a substituição de um Pod é adicionar ou modificar uma anotação. O Kubernetes substituirá o pod para aplicar a mudança.

Você pode usar o comando kubectl annotate para aplicar uma anotação:

 kubectl annotate pods my-pod app-version = "2" --overwrite 

Este comando atualiza a anotação da versão do aplicativo em my-pod. O sinalizador --overwrite instrui o Kubectl a aplicar a alteração, mesmo se a anotação já existir. Sem ele, você só pode adicionar novas anotações como medida de segurança para evitar alterações não intencionais.

Publicidade

Atualizar as variáveis ​​de ambiente de uma implantação tem um efeito semelhante à alteração de anotações. Isso é ideal quando você já está expondo um número de versão de aplicativo, ID de compilação ou data de implantação em seu ambiente.

 kubectl set env deployment my-deployment APP_VERSION = "2" 

Conclusão

Os pods do Kubernetes geralmente devem ser executados até que sejam substituídos por uma nova implantação. Como resultado, não há uma maneira direta de “ reiniciar ” um único pod. Se um de seus contêineres apresentar um problema, tente substituí-lo em vez de reiniciá-lo. A mudança sutil na terminologia corresponde melhor ao modelo operacional sem estado dos pods do Kubernetes.

Escale a contagem de réplicas, inicie uma implementação ou exclua manualmente os pods de um ReplicaSet para encerrar os contêineres antigos e iniciar novas instâncias. Os lançamentos são a solução preferida para versões modernas do Kubernetes, mas as outras abordagens também funcionam e podem ser mais adequadas a cenários específicos.

Em primeiro lugar, você deve ter estas duas perguntas: você deseja que todos os pods em sua implantação ou ReplicaSet sejam substituídos e qualquer tempo de inatividade é aceitável? As exclusões manuais de pods podem ser ideais se você deseja “ reiniciar ” um Pod individual sem tempo de inatividade, desde que você esteja executando mais de uma réplica, enquanto a escala é uma opção quando o comando de implantação não pode ser usado e você não está preocupado com um breve período de indisponibilidade.