Se quiser usar uma implantação para distribuir uma versão para um subconjunto de usuários ou um subconjunto de servidores, você pode seguir o padrão canário descrito em Gerenciamento de recursos e criar várias implantações, uma para cada versão.
O chamado Canary Release significa que o processo de atualização é suspenso imediatamente após a criação do primeiro novo Pod, e a parte principal ainda é a versão antiga neste momento. Em seguida, selecione cuidadosamente um pequeno número de solicitações do usuário com base nas características do usuário e encaminhe-as para a nova versão do aplicativo, continuando a observar se as expectativas foram atendidas. Certifique-se de que não haja nenhum problema antes de continuar a concluir o restante da atualização contínua, caso contrário, reverta imediatamente.
Atualizações contínuas para implantações
A implantação oferece suporte ao controle personalizado do ritmo contínuo durante o processo de atualização, como "pausar" ou "continuar" a operação de atualização. Um controle mais sofisticado do processo também pode ser alcançado com a ajuda dos atributos maxSurgee .maxUnavailable
A implantação atualizará .spec.strategy.type==RollingUpdateos pods de maneira contínua. Você pode especificar maxUnavailablee maxSurgecontrolar o processo de atualização contínua.
máximo indisponível
.spec.strategy.rollingUpdate.maxUnavailableé um campo opcional que especifica o número máximo de pods indisponíveis durante o processo de atualização. Esse valor pode ser um número absoluto (por exemplo, 5) ou uma porcentagem dos pods desejados (por exemplo, 10%). Os valores percentuais são convertidos em números absolutos e a parte decimal é removida. Se .spec.strategy.rollingUpdate.maxSurgefor 0, esse valor não pode ser 0. O valor padrão é 25%.
Por exemplo, quando esse valor é definido como 30%, a atualização contínua começa imediatamente a reduzir o antigo ReplicaSet para 70% do número esperado de pods. Assim que os novos Pods estiverem prontos, você pode continuar a reduzir o ReplicaSet antigo e, em seguida, aumentar o novo ReplicaSet, garantindo que o número total de Pods disponíveis a qualquer momento durante a atualização seja de pelo menos 70% do número desejado de Pods.
valor de pico máximo
.spec.strategy.rollingUpdate.maxSurgeé um campo opcional que especifica o número de pods que podem ser criados além do número desejado de pods. Esse valor pode ser um número absoluto (por exemplo, 5) ou uma porcentagem dos pods desejados (por exemplo, 10%). Se MaxUnavailablefor 0, esse valor não pode ser 0. Os valores percentuais são convertidos em números absolutos por arredondamento. O valor padrão para este campo é 25%.
Por exemplo, quando esse valor for 30%, o novo ReplicaSet será expandido imediatamente após o início da atualização contínua, garantindo que o número total de Pods antigos e novos não exceda 130% do número total de Pods necessários. Depois que os pods antigos são eliminados, o novo ReplicaSet pode ser dimensionado ainda mais, garantindo que o número total de pods em execução a qualquer momento durante a atualização seja de no máximo 130% do número total desejado de pods.
segundos de prazo de progresso
.spec.progressDeadlineSecondsé um campo opcional que especifica o número de segundos que o sistema espera para que uma implantação progrida antes de relatar uma falha no andamento da implantação. Esses relatórios serão refletidos no status do recurso como type: Progressing, status: False, reason: ProgressDeadlineExceeded. O controlador de implantação continuará tentando a implantação por um padrão de 600 milissegundos. No futuro, assim que a reversão automática for implementada, o controlador de implantação reverterá a implantação assim que detectar tal condição.
Se especificado, o valor desse campo precisa ser maior que .spec.minReadySecondso valor de .
Operação real
Normalmente, a atualização contínua do Deployment exclui um pod v1 e cria um pod v2 porque o Deployment maxSurgee maxUnavailableo atributo padrão são 1. Na versão canary, é necessário criar primeiro e depois excluir, e o número total de pods disponíveis não é menor do que o valor esperado. O número de réplicas de Pod criadas aqui depende de sua capacidade de carga . Definido maxUnavailablecomo 0:
$ kubectl patch deployments my-app-deployment \
-p '{"spec": {"strategy": {"rollingUpdate": {"maxSurge": 1, "maxUnavailable": 0}}}}'
Inicia o processo de atualização do Deployment controller, pausando a atualização imediatamente após modificar a versão da imagem do container correspondente . Aqui, você pode definir maxReadySecondso atributo (quanto tempo esperar para que o novo objeto Pod esteja pronto depois de criado) para reservar o tempo de operação para a atualização da pausa ou executar dois comandos no Shell por vez:
$ kubectl set image deployments my-app-deployment myapp=path/to/image:new \
&& kubectl rollout pause deployments my-app-deployment
Verifique o status da implantação. Depois de criar uma nova versão do recurso de pod, a atualização contínua é pausada :
$ kubectl rollout status deployments my-app-deployment
Em seguida, por meio de recursos de serviço ou ingresso e configurações de política de roteamento relacionadas, uma pequena parte do tráfego do usuário é direcionada para o novo pod para verificação de liberação. Após um período de tempo, confirme se não há problema e retome a atualização contínua:
$ kubectl rollout resume deoloyments my-app-deployment
Se o "canário" estiver em perigo, é hora de retomar a atualização contínua e reverter imediatamente :
$ kubectl rollout resume deoloyments my-app-deployment \
&& kubectl rollout undo deoloyments my-app-deployment
Após a conclusão da reversão, verifique se o objeto do controlador ReplicaSet gerenciado pela implantação foi restaurado para a versão histórica especificada para garantir que a reversão seja normal. Você pode reverter para uma versão histórica específica especificando o número de série da versão histórica depois kubectl rollout undoseguido pela opção.--to-revision=N
$ kubectl rollout history deployments my-app-deployment
$ kubectl rollout undo deployments my-app-deployment --to-revision=3
Para obter mais atributos, consulte o site oficial:
K8S deployemnt canary deployment web page address