Introdução ao ReplicaSet

O ReplicaSet (RS) é um controlador fundamental no ecossistema Kubernetes, projetado para garantir a disponibilidade de um conjunto estável de réplicas de Pods em execução a qualquer momento. Ele atua como um mecanismo de segurança: se um Pod falha ou é excluído acidentalmente, o ReplicaSet identifica a divergência entre o estado desejado e o estado atual, instanciando novas unidades para preencher a lacuna.

Embora essencial, o ReplicaSet possui uma limitação importante: ele não oferece suporte nativo a atualizações declarativas complexas (como rolling updates) de forma automatizada, tarefa que geralmente é delegada ao objeto Deployement.

Estrutura e Definição do Recurso

Para entender como um ReplicaSet opera, podemos inspecionar sua estrutura via linha de comando:

kubectl explain rs

• apiVersion: Define a versão da API (geralmente apps/v1).
• kind: O tipo de recurso (ReplicaSet).
• metadata: Dados de identificação, como nome e namespaces.
• spec: Onde definimos o comportamento desejado, incluindo o número de réplicas e o seletor.
• status: Informações de leitura sobre o estado atual do objeto no cluster.

O Campo Spec em Detalhes

kubectl explain rs.spec

• replicas: Quantidade de instâncias que devem estar rodando (padrão é 1).
• selector: Critério de seleção para identificar quais Pods este controlador deve gerenciar. Deve coincidir rigorosamente com os labels definidos no template.
• template: O blueprint do Pod que será criado caso novas instâncias sejam necessárias.

Preparação de Imagens para Teste

Considerando um ambiente com containerd, vamos simular dois cenários de uma aplicação Java simples (Versão A e Versão B) que retornam mensagens distintas.

Versão 1.0 (Resposta "Azul")

@RestController
public class AppController {
    @GetMapping("/status")
    public String checkStatus() {
        return "Servidor Ativo - Ambiente Azul";
    }
}

Versão 2.0 (Resposta "Verde")

@RestController
public class AppController {
    @GetMapping("/status")
    public String checkStatus() {
        return "Servidor Ativo - Ambiente Verde";
    }
}

Após gerar os pacotes, as imagens são importadas nos nós do cluster:

# Executar nos nós de trabalho
ctr -n=k8s.io images import app-v1.tar
ctr -n=k8s.io images import app-v2.tar

Gerenciamento Prático de Pods

Configuração via Manifesto YAML

Arquivo: web-replicaset.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: rs-web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: backend
  template:
    metadata:
      labels:
        tier: backend
    spec:
      containers:
      - name: container-app
        image: app-v1:latest
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080

Aplicando o recurso:

kubectl apply -f web-replicaset.yaml
kubectl get rs

No comando acima, DESIRED mostra o que pedimos (3), enquanto CURRENT e READY mostram o estado em tempo real.

Interação com Pods Independentes

O ReplicaSet monitora labels. Se criarmos um Pod manualmente com o label tier: backend enquanto o ReplicaSet já possui suas 3 réplicas, o controlador matará o novo Pod imediatamente para manter o número exato definido em replicas.

Inversamente, se deletarmos o ReplicaSet, por padrão, todos os Pods vinculados a ele através do seletor também serão removidos pelo mecanismo de garbage collection do Kubernetes.

Escalonamento Dinâmico

Aumentar ou diminuir a capacidade de processamento é simples com o ReplicaSet. Para realizar o Scale Up de 3 para 5 réplicas, alteramos o campo replicas no YAML e aplicamos novamente:

# Altere replicas: 5 no arquivo
kubectl apply -f web-replicaset.yaml
kubectl get pods

O Kubernetes detectará a necessidade de mais 2 Pods e os criará instantaneamente. O Scale Down funciona da mesma forma: ao reduzir o número no arquivo, o controlador escolherá Pods para encerramento até atingir a meta.

Limitações na Atualização de Imagens

Um ponto crítico no uso de ReplicaSets é a atualização de versões. Se alterarmos a imagem de app-v1 para app-v2 no manifesto e aplicarmos:

kubectl apply -f web-replicaset.yaml

Os Pods existentes não serão reiniciados automaticamente. O ReplicaSet entende que sua meta de "quantidade" de Pods com o label específico já foi atingida. A nova imagem só será utilizada se os Pods antigos forem deletados manualmente, forçando o controlador a criar novos baseados no template atualizado.

# Forçando a atualização através da exclusão
kubectl delete pod [nome-do-pod]

Devido a esse comportamento manual, para fluxos de CI/CD e atualizações sem downtime, recomenda-se o uso de Deploymenst, que gerenciam ReplicaSets internamente para automatizar esse processo.

Resumo Operacional

• O ReplicaSet garante que o número exato de Pods esteja rodando através de seletores de labels.
• Oferece resiliência automática contra falhas de Pods individuasi.
• Suporta escalonamento vertical (mudança de recursos) e horizontal (mudança de réplicas) de forma simples.
• Não gerencia o ciclo de vida de atualização de forma declarativa e automática, sendo um componente de nível inferior em comparação ao Deployment.