Atualizações Contínuas e Reversões no Kubernetes

Um dos benefícios de usar um Deployment é a capacidade de realizar atualizações contínuas e criar uma estratégia de atualização contínua. Atualizações contínuas nos permitem atualizar a configuração dos pods gradualmente.

Uma estratégia de atualização (k8s rollingupdate, k8s update strategy) é a opção mais importante para configurar atualizações contínuas. Na definição do Deployment, spec.strategy.type tem dois valores possíveis:

• RollingUpdate: Novos pods são adicionados gradualmente e os pods antigos são encerrados gradualmente.
• Recreate: Todos os pods antigos são encerrados de uma vez antes que novos pods sejam adicionados.

Existem mais 2 opções ao atualizar o deployment usando RollingUpdate.

• maxSurge: O número de pods que podem ser criados acima do número desejado de pods durante uma atualização.
• maxUnavailable: O número de pods que podem estar indisponíveis durante o processo de atualização.

Usando atualizações contínuas de deployment, podemos atualizar a imagem usada por um deployment. O estado do deployment (kubectl rollout status) é salvo, o que nos permite reverter para qualquer versão anterior do deployment.

Quando uma aplicação falha devido a uma imagem incorreta ou o deployment está instável, podemos querer reverter o Deployment (k8s rollback). Por padrão, todo o histórico de rollout do Deployment é mantido no sistema, que pode ser usado posteriormente para reverter em caso de deployment instável. Podemos usar esse histórico para reverter a qualquer momento que quisermos.

Para saber mais sobre Atualização Contínua e Reversão, visite a documentação oficial do Kubernetes aqui.

Neste artigo, atualizaremos o deployment com a estratégia de Atualização Contínua padrão e reverteremos o deployment. Para reverter o deployment, usaremos a imagem incorreta em uma das atualizações do deployment.

Pré-requisitos

1. Cluster Kubernetes com pelo menos 1 nó de trabalho.
   Se você quiser aprender a criar um Cluster Kubernetes, clique aqui. Este guia o ajudará a criar um cluster Kubernetes com 1 Master e 2 Nós em Instâncias EC2 Ubuntu 18.04 da AWS.

O que faremos?

1. Atualização Contínua e Reversão

Atualização Contínua e Reversão

Crie um arquivo de definição de deployment para Nginx com o modelo de pod do deployment. Neste, especificamos a versão do Nginx como “nginx:1.14.2”.

vim my-deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rolling-update-demo
  labels:
    app: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Vamos verificar os pods existentes e criar um deployment.

kubectl get pods

kubectl create -f my-deployment.yml

Obtenha os detalhes do deployment que acabamos de criar. Este deployment criou 4 pods e é controlado pelo replicaset.

kubectl get deployments

kubectl get pods

kubectl get replicaset

Na captura de tela acima, você pode ver que temos 1 deployment sob o qual temos 1 replicaset e 4 pods controlados pelo replicaset.

Agora, vamos mudar a versão do Nginx de “nginx:1.14.2” para “nginx:1.61.1”

vim my-deployment.yml

Aplique a alteração ao deployment e obtenha detalhes dos pods, replicaset e deployment.

kubectl apply -f my-deployment.yml

kubectl get pods

kubectl get deployments

kubectl get replicaset

Na captura de tela acima, pode-se ver que um novo replicaset foi criado e possui 4 pods sob ele. Mas ainda vemos o replicaset mais antigo com 0 pods.

Agora, se mudarmos novamente a versão do Nginx, mas desta vez der uma versão errada do Nginx, o deployment falhará, pois a imagem do Nginx não existe para a versão errada.

vim my-deployment.yml

Vamos aplicar a alteração ao deployment.

kubectl apply -f my-deployment.yml

kubectl get pods

kubectl get deployments

Agora, vamos tentar obter detalhes do replicaset.

kubectl get replicaset

Na captura de tela acima, pode-se ver que os novos Pods estão falhando com o erro “ErrImagePull”. Os pods estão falhando porque a imagem do Nginx não existe para a versão “ngin:1.1.1”.

Agora, se quisermos voltar para as imagens anteriores que funcionavam, podemos reverter para uma revisão anterior se o status do rollout não estiver ok.

Para reverter, podemos primeiro obter o histórico de rollout do deployment usando o seguinte comando.

kubectl rollout history deployments rolling-update-demo

Agora, usando o seguinte comando com “–revision=2” podemos verificar os detalhes do deployment que temos em “–revision=2”

kubectl rollout history deployments rolling-update-demo --revision=2

Na captura de tela acima, você pode ver que a revisão-2 tem a versão da imagem do Nginx “nginx:1.16.1” que estava funcionando antes de atualizarmos nosso deployment com a versão do Nginx “ngin:1.1.1” que falhou.

Agora, vamos reverter o deployment para a última revisão que temos antes do deployment atual falhado.

kubectl get deployments

kubectl rollout undo deployment rolling-update-demo

kubectl get pods

kubectl get replicaset

Na captura de tela acima, você pode ver que revertimos o último deployment e agora temos uma revisão de deployment que estava funcionando antes da última atualização.

Para saber mais sobre o deployment, ele pode ser descrito usando o seguinte comando.

kubectl get deployments

kubectl describe deployment rolling-update-demo

Conclusão

Neste artigo, vimos os passos para criar um deployment e atualizá-lo. Vimos como um deployment pode ser revertido se falhar por algum motivo, aqui o erro que vimos para o deployment falhado foi “ErrImagePull”. Vimos como o deployment mantém sua revisão para a qual pode ser revertido caso não queiramos manter as últimas atualizações no deployment.