Como fazer testes de aceitação a um cluster Kubernetes antes da produção

Um cluster OpenShift ou OKD acabado de instalar recebe-nos com uma consola cheia de verde. Todos os operators reportam available, todos os nós estão ready, e é tentador dar o trabalho por terminado. O verde diz-nos que os componentes arrancaram. Não diz que um volume pode ser restaurado, que o tráfego sobrevive à perda de um nó, nem que um tenant não consegue ler os secrets de outro. Isso tem de ser testado, de propósito, antes de lá correr o que quer que seja que importe.

Estado não é comportamento

As verificações de saúde do cluster foram feitas para reportar se um componente está a correr. A produção depende de como a plataforma se comporta quando algo corre mal: um nó morre, um disco enche, um rolling update esvazia um nó que carrega uma base de dados. A única forma de saber é provocar essas condições de forma controlada e observar. O plano de testes abaixo cobre as camadas que mais contam. Adapte-o, mas escreva o seu, execute cada passo à mão da primeira vez e guarde as evidências.

Storage: criar, escrever, crescer, snapshot, restore, comparar

As cargas de trabalho stateful vivem ou morrem pelo storage. Para cada storage class que pretende oferecer:

oc apply -f test-pvc.yaml
oc rsh <test-pod> sh -c 'dd if=/dev/urandom of=/data/blob bs=1M count=256 && sha256sum /data/blob'
oc patch pvc test-pvc -p '{"spec":{"resources":{"requests":{"storage":"20Gi"}}}}'
oc apply -f test-snapshot.yaml
oc apply -f restore-pvc-from-snapshot.yaml
oc rsh <restore-pod> sha256sum /data/blob

Os checksums têm de coincidir. Confirme que a expansão é visível dentro do pod com df, não apenas no claim. Para storage partilhado read-write-many, monte o mesmo claim a partir de pods em dois nós diferentes e confirme que cada um vê as escritas do outro. Depois verifique o que acontece quando um claim é apagado: os dados de produção devem assentar numa storage class cuja reclaim policy retém o volume, para que uma eliminação por engano não o destrua.

Falha: mate um nó e cronometre a recuperação

Escolha o nó que carrega o tráfego ingress em produção e desligue-o a partir do controlador de gestão, não com um shutdown educado. De fora do cluster, corra um ciclo que marca a hora de cada pedido:

while true; do
  printf '%s ' "$(date +%T.%N)"
  curl -s -o /dev/null -w '%{http_code}\n' --max-time 2 https://test-app.example.com/
  sleep 0.2
done

A saída mostra exatamente durante quanto tempo o serviço esteve indisponível, que é o número que os seus utilizadores sentiriam. Depois observe o que o orchestrator faz: quanto tempo até o nó ser marcado not ready, se os pods são reagendados, se os pods stateful regressam com os seus dados. Volte a ligar o nó e confirme que se reintegra de forma limpa. A forma como a rede toma conhecimento da falha conta aqui. Se o endereço do serviço for anunciado a partir de todos os nós por BGP e o lado da rede correr deteção rápida de falhas, como BFD, o tráfego pode afastar-se de um nó morto em segundos, muito antes de o próprio Kubernetes ter decidido que o nó desapareceu.

Manutenção: prove que os disruption budgets mantêm o quórum

A manutenção rolling dos nós e as atualizações da plataforma esvaziam nós um após outro. Uma base de dados em cluster precisa de uma maioria de membros ativos em todos os momentos, e um PodDisruptionBudget é a forma de o dizer à plataforma:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: galera-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: galera

Depois teste-o. Com um cluster de três membros e um membro já em baixo (o seu nó esvaziado, de modo que só dois membros estão a correr), tente esvaziar o nó de um segundo membro:

oc adm cordon <node-a>
oc adm drain <node-b> --ignore-daemonsets --delete-emptydir-data
oc get pdb

O drain deve esperar em vez de fazer evict, porque o evict quebraria o quórum. Se fizer evict, o budget está errado ou em falta, e acabou de o descobrir num teste em vez de durante uma atualização. Distribua os membros pelos nós com topology spread constraints ou anti-affinity, para que uma falha de nó nunca possa levar dois membros.

Builds e o registry

Confirme que o cluster consegue construir e executar as suas próprias imagens, porque um registry interno que não aceita um push só será descoberto num dia de deploy:

oc new-build --name=smoke --binary --strategy=docker
oc start-build smoke --from-dir=. --follow
oc new-app smoke

Acesso: teste o que um tenant não pode fazer

A utilização por vários tenants define-se por aquilo que é recusado a um utilizador. Crie um utilizador de teste com âmbito limitado por tenant e verifique os limites explicitamente:

oc auth can-i get secrets -n tenant-b --as=tenant-a-user
oc auth can-i create pods -n tenant-a --as=tenant-a-user
oc auth can-i list nodes --as=tenant-a-user

O primeiro e o terceiro devem responder não, o segundo sim. Verifique que as quotas impedem um tenant de consumir o cluster, que o ingress de cada tenant serve apenas os seus próprios domínios com um certificado válido, e que o tráfego que sai do cluster em direção aos seus outros sistemas vem da identidade de egress que a sua firewall espera.

Guarde as evidências

Registe cada teste com o comando, a saída e o resultado. Quando algo mudar mais tarde, uma atualização da plataforma ou uma nova storage class, volte a correr a secção relevante e compare. Um cluster que passou nos testes uma vez e nunca mais foi testado torna-se, aos poucos, um cluster não testado.

Como o fazemos

Construímos OpenShift e OKD em servidores HPE dedicados, com block storage persistente e storage partilhado dentro do cluster, endereços de serviço públicos anunciados a partir dos nós por BGP, e ingress e certificados por tenant. Antes de um cluster carregar uma carga de trabalho de cliente, passa por mais de trinta verificações práticas deste tipo, de restores de storage byte a byte a falhas forçadas e delimitação de acessos. Num teste de aceitação desligámos o nó que carregava o tráfego em produção, e a rede reencaminhou em cerca de três segundos, muito antes de o orchestrator declarar o nó perdido. As bases de dados em cluster na plataforma são construídas segundo o padrão acima: disruption budgets que mantêm o quórum, storage que é retido, membros distribuídos pelos nós.

Se está prestes a colocar produção num cluster novo e só o viu verde, teremos todo o gosto em ajudar a testá-lo como deve ser primeiro.

Fale com um engenheiro

related line: Relacionados: Kubernetes privado em bare metal, OpenShift e OKD · Bare metal servers em HPE e Dell · Private cloud em KVM com OLVM

footer line: Publicado em 22 de outubro de 2026. Todas as notas de campo