K8s em Exemplos: Deployments

Deployments gerenciam Pods via ReplicaSets. A hierarquia é: Deployment → ReplicaSet → Pods. Deployments adicionam self-healing, scaling, rolling updates e rollbacks sobre ReplicaSets.
deployment.yaml

Deployments usam a API apps/v1. O selector vincula o Deployment aos seus Pods.

 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app.kubernetes.io/name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: my-app

O template do Pod define como cada réplica se parece. Labels no template devem corresponder ao selector.

 
  template:
    metadata:
      labels:
        app.kubernetes.io/name: my-app
    spec:
      containers:
        - name: app
          image: my-app:v1.2.0
          ports:
            - name: http
              containerPort: 8080
terminal

Kubernetes usa loops de reconciliação para manter o estado desejado. Delete um Pod e observe o Deployment recriá-lo automaticamente.

 
$ kubectl delete pod my-app-7d9f8b6c5d-abc12
pod "my-app-7d9f8b6c5d-abc12" deleted

$ kubectl get pods
NAME                      READY   STATUS    AGE
my-app-7d9f8b6c5d-def34   1/1     Running   5s
my-app-7d9f8b6c5d-ghi56   1/1     Running   10m
my-app-7d9f8b6c5d-jkl78   1/1     Running   10m
terminal

Scale up e novos Pods são criados automaticamente. Scale down e Pods excedentes são terminados.

 
$ kubectl scale deployment my-app --replicas=5
deployment.apps/my-app scaled

$ kubectl get deployment my-app
NAME     READY   UP-TO-DATE   AVAILABLE   AGE
my-app   5/5     5            5           10m
rolling-update-strategy.yaml

Duas estratégias de update: RollingUpdate (padrão) substitui Pods gradualmente; Recreate mata todos os Pods antes de criar novos.

 
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1

minReadySeconds atrasa a marcação de Pods como ready. revisionHistoryLimit controla quantos ReplicaSets antigos manter para rollback.

 
  replicas: 3
  minReadySeconds: 10
  revisionHistoryLimit: 5
terminal

Rolling updates criam um novo ReplicaSet e gradualmente transferem Pods. ReplicaSets antigos são mantidos (escalados para 0) para rollbacks.

 
$ kubectl get rs
NAME                DESIRED   CURRENT   READY   AGE
my-app-7d9f8b6c5d   3         3         3       10m
my-app-5f8d9a7b3c   0         0         0       1h
terminal

Cada update cria uma nova revisão no histórico. Veja todas as revisões com rollout history.

 
$ kubectl rollout history deployment/my-app
deployment.apps/my-app
REVISION  CHANGE-CAUSE
1         Initial deployment
2         kubectl set image deployment/my-app app=my-app:v1.3.0
3         kubectl set image deployment/my-app app=my-app:v1.4.0
terminal

Atualize a imagem para disparar um rolling update. Acompanhe o status com rollout status.

 
$ kubectl set image deployment/my-app app=my-app:v1.3.0
deployment.apps/my-app image updated

$ kubectl rollout status deployment/my-app
Waiting for deployment "my-app" rollout to finish: 1 of 3 updated...
Waiting for deployment "my-app" rollout to finish: 2 of 3 updated...
deployment "my-app" successfully rolled out
terminal

Rollbacks são rápidos porque ReplicaSets antigos ainda existem. Kubernetes apenas escala eles para cima e para baixo.

 
$ kubectl rollout undo deployment/my-app
deployment.apps/my-app rolled back

$ kubectl rollout undo deployment/my-app --to-revision=2
deployment.apps/my-app rolled back to revision 2
terminal

Pause e resume rollouts para deploys estilo canary. Enquanto pausado, você pode testar novos Pods antes de completar o update.

 
$ kubectl set image deployment/my-app app=my-app:v2.0.0
deployment.apps/my-app image updated

$ kubectl rollout pause deployment/my-app
deployment.apps/my-app paused

$ kubectl rollout resume deployment/my-app
deployment.apps/my-app resumed

Índice | GitHub | Use as setas do teclado para navegar |