🇺🇸 English version coming soon.

Nas partes anteriores desta série, construímos o cluster do zero: preparamos o ambiente (Parte 1), instalamos containerd e Kubernetes (Parte 2), inicializamos o control-plane (Parte 3) e ingressamos os workers (Parte 4). Com o cluster de pé e todos os nós no estado Ready, chegou a hora de colocá-lo para trabalhar de verdade: vamos fazer o deploy da nossa primeira aplicação.

Neste artigo, vamos usar o Nginx como exemplo — um caso clássico para validar que o cluster está funcionando de ponta a ponta, desde a criação dos pods até a exposição do serviço.

Organizando os arquivos

Antes de tudo, crie um diretório para organizar os manifestos desse deployment:

mkdir nginx
cd nginx

Enter fullscreen mode Exit fullscreen mode

Costumo deixar os manifestos do Kubernetes organizados em diretórios por aplicação, considero uma boa prática que facilita a manutenção e o versionamento (por exemplo, com Git) conforme o cluster cresce.

Criando o Deployment

Um Deployment é o objeto do Kubernetes responsável por gerenciar réplicas de pods, garantindo que o número desejado de instâncias esteja sempre em execução — e cuidando de coisas como rolling updates e recuperação automática em caso de falha.

Crie o arquivo nginx-deployment.yaml com o seguinte conteúdo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.0
        ports:
        - containerPort: 80

Enter fullscreen mode Exit fullscreen mode

Esse manifesto define:

  • 2 réplicas do pod Nginx (replicas: 2), distribuídas entre os workers disponíveis;
  • Um selector que associa o Deployment aos pods através do label app: nginx;
  • A imagem nginx:1.14.0, expondo a porta 80 do container.

Aplicando o Deployment

Com o arquivo salvo, aplique-o no cluster:

kubectl apply -f nginx-deployment.yaml

Enter fullscreen mode Exit fullscreen mode

O kubectl vai criar o Deployment e, a partir dele, o Kubernetes se encarrega de agendar os 2 pods nos workers disponíveis.

Verificando o Deployment

Para conferir se o Deployment foi criado e está com as réplicas desejadas em execução:

kubectl get deployments

Enter fullscreen mode Exit fullscreen mode

E, para detalhes mais completos (eventos, condições, estratégia de rollout, etc.):

kubectl describe deployment nginx-deployment

Enter fullscreen mode Exit fullscreen mode

Se tudo estiver certo, você deve ver as 3 réplicas prontas (2/2) na coluna de disponibilidade.

Criando o Service

Só o Deployment não é suficiente para acessar a aplicação de fora do cluster — pods são efêmeros e seus IPs mudam a cada recriação. É para isso que existe o Service: um ponto de acesso estável que direciona tráfego para os pods corretos, com base nos labels.

Crie o arquivo nginx-service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  labels:
    run: nginx-service
spec:
  type: NodePort
  ports:
  - port: 80
    protocol: TCP
  selector:
    app: nginx

Enter fullscreen mode Exit fullscreen mode

Aqui, o tipo NodePort é usado para expor o serviço em uma porta acessível diretamente pelo IP de qualquer nó do cluster — uma opção simples e prática para ambientes on-premise, sem depender de um load balancer externo (diferente do tipo LoadBalancer, mais comum em provedores de nuvem).

Aplicando o Service 

kubectl apply -f nginx-service.yaml

Enter fullscreen mode Exit fullscreen mode

Verificando o Service 

kubectl get service

Enter fullscreen mode Exit fullscreen mode

Esse comando mostra, entre outras informações, a porta externa (NodePort) que foi alocada automaticamente pelo Kubernetes — normalmente na faixa entre 30000 e 32767.

Para mais detalhes:

kubectl describe service nginx-service

Enter fullscreen mode Exit fullscreen mode

Com a porta em mãos, o Nginx já pode ser acessado através do IP de qualquer nó do cluster (master ou workers) na porta indicada — por exemplo: http://10.0.10.100:<porta-nodeport>.

O que validamos aqui

Se você conseguiu acessar a página padrão do Nginx através do NodePort, isso confirma que todo o cluster está funcionando corretamente de ponta a ponta:

  • O control-plane está agendando pods normalmente;
  • A rede de pods (CNI) está permitindo a comunicação entre os componentes;
  • O kube-proxy está roteando o tráfego do Service para os pods corretos;
  • Os workers estão executando containers sem problemas.

Considerações finais

Com isso, fechamos o essencial para montar e validar um cluster Kubernetes on-premise do zero: preparação do ambiente, instalação dos componentes, inicialização do control-plane, ingresso dos workers e o primeiro deploy de uma aplicação real.

A partir daqui, os próximos passos naturais incluem temas como armazenamento persistente (Persistent Volumes), Ingress Controllers, gerenciamento de configurações e segredos (ConfigMaps e Secrets), monitoramento (Prometheus/Grafana) e estratégias de backup do cluster (como o etcd). Fica a sugestão para uma possível continuação desta série.

Se você seguiu os cinco artigos até aqui, já tem em mãos um cluster Kubernetes on-premise funcional, construído e validado do zero — sem depender de nenhum provedor de nuvem.

Agora na Parte 6 desta série, vamos subir nosso container com nossa aplicação e endentender como tudo funciona.

Continua na Parte 6.