Kubernetes Avançado — Operators, Custom Resources e automação de plataforma

Em 2016, Brandon Philips (CTO da CoreOS) publicou um post que introduziu o padrão Operator: a ideia de que o conhecimento operacional de sistemas complexos — como operar um cluster etcd, fazer upgrades sem downtime, recuperar de falhas — pode ser codificado em um controlador Kubernetes em vez de em runbooks que dependem de intervenção humana. O princípio é simples: se um engenheiro sênior sabe o que fazer quando o etcd primário cai, esse conhecimento pode ser codificado em um programa que reage automaticamente ao mesmo evento.

Operators elevam o Kubernetes de um orquestrador de containers para uma plataforma de automação de operações. A pergunta muda de "como faço deploy desse banco de dados?" para "como codifico o conhecimento de operar esse banco de dados de forma que a plataforma o faça automaticamente?".

Custom Resource Definitions (CRDs)

Antes de falar em Operators, é necessário entender CRDs. O Kubernetes é extensível: você pode adicionar novos tipos de recursos além dos built-in (Deployment, Service, ConfigMap). Um CRD define um novo tipo de recurso com seu próprio schema:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: bancosdedados.minha.org
spec:
  group: minha.org
  names:
    kind: BancoDeDados
    listKind: BancoDeDadosList
    plural: bancosdedados
    singular: bancodedados
  scope: Namespaced
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              required: [engine, version, storage]
              properties:
                engine:
                  type: string
                  enum: [postgres, mysql]
                version:
                  type: string
                  pattern: '^[0-9]+\.[0-9]+$'
                storage:
                  type: string      # "10Gi", "100Gi"
                  pattern: '^[0-9]+(Mi|Gi)$'
                highAvailability:
                  type: boolean
                  default: false
            status:
              type: object
              properties:
                phase:
                  type: string
                  enum: [Pending, Provisioning, Ready, Failed]
                endpoint:
                  type: string
                lastError:
                  type: string

Depois de aplicar esse CRD, você pode criar recursos do tipo BancoDeDados:

apiVersion: minha.org/v1
kind: BancoDeDados
metadata:
  name: banco-producao
  namespace: meu-servico
spec:
  engine: postgres
  version: "16.2"
  storage: "100Gi"
  highAvailability: true

O recurso é armazenado no etcd, mas sem um controller, nada acontece. É o Operator que age sobre o recurso.

O padrão Operator — reconciliation loop

Um Operator é um controller que observa recursos (CRDs ou recursos built-in) e reconcilia o estado real com o estado desejado. O loop de reconciliação é o coração do padrão:

// Go — controller com kubebuilder (simplificado)
func (r *BancoDeDadosReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    // 1. Buscar o recurso atual
    banco := &minhav1.BancoDeDados{}
    if err := r.Get(ctx, req.NamespacedName, banco); err != nil {
        return ctrl.Result{}, client.IgnoreNotFound(err)
    }

    // 2. Determinar o estado atual vs desejado
    switch banco.Status.Phase {
    case "":
        // Primeira vez — iniciar provisionamento
        banco.Status.Phase = "Pending"
        r.Status().Update(ctx, banco)
        return ctrl.Result{Requeue: true}, nil

    case "Pending":
        // Criar os recursos Kubernetes necessários
        if err := r.createStatefulSet(ctx, banco); err != nil {
            banco.Status.LastError = err.Error()
            banco.Status.Phase = "Failed"
            r.Status().Update(ctx, banco)
            return ctrl.Result{}, err
        }
        banco.Status.Phase = "Provisioning"
        r.Status().Update(ctx, banco)
        return ctrl.Result{RequeueAfter: 30 * time.Second}, nil

    case "Provisioning":
        // Verificar se o StatefulSet está pronto
        if r.isReady(ctx, banco) {
            banco.Status.Phase = "Ready"
            banco.Status.Endpoint = r.getEndpoint(banco)
            r.Status().Update(ctx, banco)
        }
        return ctrl.Result{RequeueAfter: 10 * time.Second}, nil

    case "Ready":
        // Reconciliar continuamente — detectar drift
        if r.specChanged(banco) {
            return r.handleSpecChange(ctx, banco)
        }
        return ctrl.Result{RequeueAfter: 60 * time.Second}, nil
    }

    return ctrl.Result{}, nil
}

O controller é notificado pelo API server quando qualquer objeto BancoDeDados é criado, modificado, ou deletado — e também periodicamente (via RequeueAfter). A reconciliação é idempotente: se chamada múltiplas vezes com o mesmo estado, o resultado é o mesmo. Isso é o que torna o loop de reconciliação robusto a falhas parciais.

Kubebuilder e Operator SDK

Escrever um Operator do zero envolve muita boilerplate de interação com o API server. Kubebuilder e Operator SDK são frameworks que geram o scaffolding:

# Criar um novo projeto Operator com kubebuilder
kubebuilder init --domain minha.org --repo github.com/minha-org/meu-operator

# Criar CRD e controller
kubebuilder create api --group banco --version v1 --kind BancoDeDados

# Estrutura gerada
meu-operator/
├── api/v1/
│   ├── bancodedados_types.go    # estrutura do CRD (você preenche)
│   └── zz_generated.deepcopy.go
├── controllers/
│   └── bancodedados_controller.go   # lógica de reconciliação (você implementa)
├── config/
│   ├── crd/                     # CRD gerado automaticamente
│   └── rbac/                    # RBAC para o controller
└── main.go

O Operator SDK (Red Hat) é similar ao kubebuilder mas também suporta Operators em Ansible e Helm — útil para encapsular charts Helm existentes em um Operator sem escrever Go.

Operators canônicos — exemplos de produção

cert-manager: gerencia certificados TLS dentro do cluster. Você cria um recurso Certificate ou anota um Ingress, e o cert-manager emite automaticamente o certificado via Let's Encrypt (ACME), Vault, ou CA interno — e o renova antes da expiração. Elimina o toil de gestão manual de certificados.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: meu-servico-tls
spec:
  secretName: meu-servico-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - api.minha-empresa.com

External Secrets Operator (ESO): sincroniza secrets de sistemas externos (Vault, AWS Secrets Manager, GCP Secret Manager) para Kubernetes Secrets. O secret não fica armazenado no git — apenas a referência a onde ele está:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: db-credentials   # Kubernetes Secret criado
  data:
    - secretKey: password
      remoteRef:
        key: producao/banco-de-dados
        property: password

Crossplane: provision de infraestrutura cloud via recursos Kubernetes. Em vez de usar Terraform ou Pulumi, você cria um recurso RDSInstance no Kubernetes e o Crossplane cria o banco de dados na AWS. O cluster Kubernetes se torna o plano de controle de toda a infraestrutura:

apiVersion: rds.aws.crossplane.io/v1alpha1
kind: DBInstance
metadata:
  name: producao-postgres
spec:
  forProvider:
    region: us-east-1
    dbInstanceClass: db.t3.medium
    engine: postgres
    engineVersion: "16.2"
    multiAZ: true
  providerConfigRef:
    name: aws-provider

Prometheus Operator: gerencia configuração do Prometheus via CRDs — ServiceMonitor, PodMonitor, PrometheusRule. Times de produto adicionam um ServiceMonitor ao seu serviço para expor métricas sem editar o arquivo de configuração central do Prometheus.

Admission Webhooks — validação e mutação

Admission webhooks são plugins que interceptam requisições ao API server antes que recursos sejam persistidos no etcd. Existem dois tipos:

Validating Admission Webhook: valida um recurso e pode rejeitar a criação/modificação. Exemplos de uso: impedir Deployments sem resource limits, bloquear imagens de registries não aprovados, validar que todos os recursos têm as tags obrigatórias.

Mutating Admission Webhook: modifica um recurso antes de persistir. Exemplos: injetar sidecar de logging automaticamente, adicionar labels padrão, ou setar valores padrão que o usuário não especificou.

// Go — Validating webhook que rejeita Pods sem resource limits
func (v *PodValidator) Handle(ctx context.Context, req admission.Request) admission.Response {
    pod := &corev1.Pod{}
    if err := v.decoder.Decode(req, pod); err != nil {
        return admission.Errored(http.StatusBadRequest, err)
    }

    for _, container := range pod.Spec.Containers {
        if container.Resources.Limits == nil {
            return admission.Denied(fmt.Sprintf(
                "container %q não tem resource limits definidos — obrigatório em produção",
                container.Name,
            ))
        }
        if container.Resources.Limits.Memory().IsZero() {
            return admission.Denied(fmt.Sprintf(
                "container %q não tem memory limit — pode causar OOM no nó",
                container.Name,
            ))
        }
    }

    return admission.Allowed("resource limits OK")
}

Webhooks são registrados como ValidatingWebhookConfiguration e MutatingWebhookConfiguration. O API server envia a requisição ao webhook via HTTPS antes de persistir — o webhook precisa ter alta disponibilidade, pois sua indisponibilidade bloqueia operações no cluster.

Policy enforcement com OPA/Gatekeeper

Open Policy Agent (OPA) com Gatekeeper é o padrão para policy enforcement em Kubernetes. Gatekeeper é implementado como admission webhook, e as políticas são escritas em Rego:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: require-team-label
spec:
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds: ["Deployment"]
  parameters:
    labels: ["team", "service", "environment"]

---
# ConstraintTemplate que define a lógica de validação
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        openAPIV3Schema:
          properties:
            labels:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels

        violation[{"msg": msg}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("labels obrigatórias ausentes: %v", [missing])
        }

Decisões de engenharia

Perguntas de entrevista

Exercícios práticos