Configuração da política de atualização da carga de trabalho
Em aplicações reais, a atualização é uma operação comum. Uma Implementação, o StatefulSet ou o DaemonSet podem suportar facilmente a atualização de aplicações.
Você pode definir diferentes políticas de atualização:
- Atualização contínua: novos pods são criados gradualmente e, em seguida, os pods anteriores são excluídos. Esta é a política padrão.
- Atualização de substituição: os pods atuais são excluídos e, em seguida, novos pods são criados.
Parâmetros de atualização
|
Parâmetro |
Descrição |
Restrição |
|---|---|---|
|
Max. Surge (maxSurge) |
Especifica o número máximo de pods que podem existir em comparação com spec.replicas. O valor padrão é 25%. Por exemplo, se spec.replicas for definido como 4, um máximo de cinco pods podem existir durante a atualização. Ou seja, a atualização é realizada em uma etapa de 1. Durante a atualização real, o valor é convertido em um número e arredondado para cima. O valor também pode ser definido como um número absoluto. |
Esse parâmetro é suportado apenas por Implementações e DaemonSets. |
|
Max. Unavailable Pods (maxUnavailable) |
Especifica o número máximo de pods que podem estar indisponíveis em comparação com spec.replicas. O valor padrão é 25% Por exemplo, se spec.replicas estiver definido como 4, pelo menos três pods existirão durante a atualização. Ou seja, a exclusão é realizada em uma etapa de 1. O valor também pode ser definido como um número absoluto. |
Esse parâmetro é suportado apenas por Implementações e DaemonSets. |
|
Min. Ready Seconds (minReadySeconds) |
Um pod é considerado disponível apenas quando o tempo mínimo de prontidão é excedido sem que nenhum de seus contêineres falhe. O valor padrão é 0 (o pod é considerado disponível imediatamente após estar pronto). |
Nenhuma |
|
Revision History Limit (revisionHistoryLimit) |
Especifica o número de ReplicaSets antigos a serem retidos para permitir a reversão. Esses ReplicaSets antigos consomem recursos em etcd e lotam a saída de kubectl get rs. A configuração de cada revisão de Implementação é armazenada em seus ReplicaSets. Portanto, depois que o ReplicaSet anterior for excluído, você perderá a capacidade de reverter para essa revisão de Implementação. Por padrão, 10 ReplicaSets anteriores serão mantidos, mas o valor ideal depende da frequência e estabilidade das novas Implementações. |
Nenhuma |
|
Max. Upgrade Duration (progressDeadlineSeconds) |
Especifica o número de segundos que o sistema aguarda que uma Implementação progrida antes de comunicar uma falha de progresso da Implementação. Ele é exibido como uma condição com Type=Progressing, Status=False e Reason=ProgressDeadlineExceeded no status do recurso. O controlador de Implementação continuará tentando novamente a Implementação. No futuro, quando a reversão automática for implementada, o controlador de Implementação reverterá uma Implementação assim que observar tal condição. Se este parâmetro for especificado, o valor deste parâmetro deve ser maior que .spec.minReadySeconds. |
Nenhuma |
|
Scale-In Time Window (terminationGracePeriodSeconds) |
Tempo de exclusão gracioso. O valor padrão é 30 segundos. Quando um pod é excluído, um sinal SIGTERM é enviado e o sistema aguarda que as aplicações no contêiner terminem. Se a aplicação não for encerrada dentro do tempo especificado por terminationGracePeriodSeconds, um sinal SIGKILL é enviado para terminar forçosamente o pod. |
Nenhuma |
Exemplo de atualização
A Implementação pode ser atualizada em um modo declarativo. Ou seja, você só precisa modificar a definição YAML da Implementação. Por exemplo, você pode executar o comando kubectl edit para alterar a imagem de Implementação para nginx:alpine. Após a modificação, consulte o ReplicaSet e o pod. O resultado da consulta mostra que um novo ReplicaSet é criado e o pod é recriado.
$ kubectl edit deploy nginx $ kubectl get rs NAME DESIRED CURRENT READY AGE nginx-6f9f58dffd 2 2 2 1m nginx-7f98958cdf 0 0 0 48m $ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-6f9f58dffd-tdmqk 1/1 Running 0 1m nginx-6f9f58dffd-tesqr 1/1 Running 0 1m
A Implementação pode usar os parâmetros maxSurge e maxUnavailable para controlar a proporção de pods a serem recriados durante a atualização, o que é útil em muitos cenários. A configuração é a seguinte:
spec:
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
No exemplo anterior, o valor de spec.replicas é 2. Se ambos maxSurge e maxUnavailable forem o valor padrão 25%, maxSurge permite que existam no máximo três pods (2 x 1,25 = 2,5, arredondado para 3), e maxUnavailable não permite que um máximo de dois pods estejam indisponíveis (2 x 0,75 = 1,5, arredondado para 2). Ou seja, durante o processo de atualização, sempre haverá dois pods em execução. Cada vez que um novo pod é criado, um pod antigo é excluído, até que todos os pods sejam novos.
Reversão
Reversão é reverter uma aplicação para a versão anterior quando ocorre uma falha durante a atualização. Uma Implementação pode ser facilmente revertida para a versão anterior.
Por exemplo, se a imagem atualizada estiver com defeito, você poderá executar o comando kubectl rollout undo desfazer para reverter a Implementação.
$ kubectl rollout undo deployment nginx deployment.apps/nginx rolled back
Uma Implementação pode ser facilmente revertida porque usa um ReplicaSet para controlar um pod. Após a atualização, o ReplicaSet anterior ainda existe. A Implementação é revertida usando o ReplicaSet anterior para recriar o pod. O número de ReplicaSets armazenados em uma Implementação pode ser restrito pelo parâmetro revisionHistoryLimit. O valor padrão é 10.
