Deploying Applications with Kubernetes Deployments

A Abordagem Declarativa: Definindo o "Quê", Não o "Como"

Ao contrário da abordagem imperativa, onde você diz ao Kubernetes "execute este comando", a abordagem declarativa consiste em fornecer um arquivo de manifesto que descreve o estado final desejado. Você diz ao Kubernetes: "Eu quero que existam três réplicas de uma aplicação web Nginx em execução." O Kubernetes então se encarrega de fazer isso acontecer.

Essa reconciliação é realizada por um padrão de design central no Kubernetes chamado control loop (ou ciclo de controle). Um controlador observa o estado atual do cluster, compara-o com o estado desejado que você definiu no manifesto e executa as ações necessárias para fechar essa lacuna.

A Anatomia de um Manifesto Kubernetes

Todos os manifestos do Kubernetes, independentemente do tipo de recurso, compartilham uma estrutura comum em YAML. Para entender essa estrutura, vamos assistir a uma breve explicação.

Resumindo, os quatro campos principais em qualquer manifesto são:

• apiVersion: A versão da API do Kubernetes usada para criar este objeto. Para Deployments, o valor comum e estável é apps/v1.
• kind: O tipo de objeto que estamos definindo. Neste caso, será Deployment.
• metadata: Dados que ajudam a identificar unicamente o objeto, como seu name e labels (etiquetas).
• spec (especificação): Esta é a parte mais importante. Aqui você descreve o estado desejado do objeto. Para um Deployment, isso inclui quantas réplicas você quer e qual imagem de contêiner usar.

Autenticando um Manifesto de Deployment

Um Deployment é um objeto de alto nível que gerencia o ciclo de vida dos seus Pods. Ele garante que um número especificado de réplicas de Pods esteja sempre em execução. Se um Pod falhar, o Deployment o substituirá. Você raramente criará Pods diretamente; em vez disso, você criará um Deployment que os gerencia para você.

Vamos analisar em detalhes como escrever o manifesto para um Deployment.

Com base na leitura, vamos montar nosso próprio manifesto de Deployment básico. Crie um arquivo chamado nginx-deployment.yaml e adicione o seguinte conteúdo:

# nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment      # O nome do nosso objeto Deployment
  labels:
    app: nginx                # Um label para o próprio Deployment
spec:
  replicas: 2                 # Estado desejado: queremos 2 réplicas do nosso Pod
  selector:
    matchLabels:
      app: nginx              # Como o Deployment encontra os Pods para gerenciar
  template:                   # O blueprint (modelo) para os Pods que serão criados
    metadata:
      labels:
        app: nginx            # O label aplicado aos Pods. Deve corresponder ao selector.matchLabels
    spec:
      containers:
      - name: nginx-container # O nome do contêiner dentro do Pod
        image: nginx:latest   # A imagem Docker a ser usada
        ports:
        - containerPort: 80   # A porta que o contêiner expõe (informativo)

Analisando as partes mais importantes do spec:

• replicas: 2: Diz ao Kubernetes para garantir que dois Pods correspondentes a este template estejam sempre em execução.
• selector.matchLabels: Este é o elo crucial. O Deployment usa este seletor para saber quais Pods "pertencem" a ele. Ele procurará por Pods que tenham o label app: nginx.
• template: Este é um "manifesto de Pod" aninhado.
  • template.metadata.labels: Aqui aplicamos o label app: nginx ao Pod. É essencial que este label corresponda ao selector.matchLabels do Deployment.
  • template.spec.containers: Uma lista de contêineres a serem executados dentro do Pod. A maioria dos Pods executa um único contêiner, mas pode executar mais. Aqui, definimos um contêiner chamado nginx-container usando a imagem nginx:latest.

Aplicando o Manifesto

Agora que temos nosso manifesto declarativo, vamos pedir ao Kubernetes para torná-lo realidade. Para isso, usamos o comando kubectl apply.

Diferente de kubectl create, kubectl apply é idempotente. Você pode executá-lo repetidamente com o mesmo arquivo. Se o objeto não existir, ele será criado. Se já existir e o manifesto for diferente, ele será atualizado para corresponder ao novo estado desejado.

1. Aplique o manifesto:
   Execute este comando no mesmo diretório onde você salvou o arquivo nginx-deployment.yaml:

   kubectl apply -f nginx-deployment.yaml
   

   Você deve ver a saída: deployment.apps/nginx-deployment created.

2. Verifique a implantação:
   Agora, use os comandos que você aprendeu na lição anterior para inspecionar o que aconteceu.

   # Verifique o status do Deployment. Você deve ver 2/2 em READY.
   kubectl get deployments
   
   # Veja os Pods que foram criados pelo Deployment. Você deve ver dois Pods.
   kubectl get pods
   
   # Para ver a cadeia completa (Deployment -> ReplicaSet -> Pods)
   kubectl get all
   

Para ver como o Kubernetes realizou o rollout, você pode descrever o Deployment:

kubectl describe deployment nginx-deployment

Na seção Events, você verá o controlador do Deployment escalando um novo ReplicaSet para 2 réplicas, o que resultou na criação dos dois Pods.

Finalmente, para limpar seu ambiente, você pode usar o mesmo arquivo de manifesto com o comando delete:

kubectl delete -f nginx-deployment.yaml

Conclusão

Parabéns! Você acaba de dar o passo mais importante para gerenciar aplicações no Kubernetes de forma profissional. Em vez de dar ordens imperativas, você agora sabe como declarar o estado desejado e deixar o Kubernetes fazer o trabalho pesado.

Principais Pontos:

• Abordagem Declarativa: Você define o "quê" em um arquivo YAML, e o Kubernetes descobre o "como".
• Anatomia do Manifesto: Os quatro pilares são apiVersion, kind, metadata e spec.
• Estrutura do Deployment: Define o número de replicas e usa um selector para encontrar os Pods criados a partir de um template.
• kubectl apply: O comando principal para aplicar um estado desejado de um arquivo de manifesto ao seu cluster. É seguro executá-lo várias vezes.

Próxima Lição:
Nossos Pods estão em execução, mas estão isolados dentro da rede do cluster. Como um cliente externo (ou até mesmo outro serviço dentro do cluster) pode se comunicar com eles? Na próxima lição, "Author and apply a Kubernetes Service manifest (ClusterIP, NodePort) to expose a Deployment", você aprenderá sobre o objeto Service, que fornece um ponto de acesso estável e de rede para seus Pods.