O que significa
Antes de criar o container, o kubelet monta o que o pod pede: variáveis de ambiente com secretKeyRef e configMapKeyRef, envFrom e volumes de Secret e ConfigMap. Se algum desses objetos não existe no namespace do pod, ou a chave pedida não está nele, o container não é criado e o motivo fica CreateContainerConfigError. O kubelet tenta de novo periodicamente; assim que o objeto aparece, o container sobe sem precisar recriar o pod.
Secret e ConfigMap são sempre do mesmo namespace do pod. Um Secret com o nome certo em outro namespace não serve.
Causas comuns
O Secret foi criado em outro namespace, com outro nome, ou ainda não foi criado porque o pipeline aplica o Deployment antes dele.
O Secret existe, mas o secretKeyRef pede uma chave que não está nele. Comum depois de renomear a chave num lado só.
O mesmo problema do Secret, com ConfigMap. Aparece muito quando o ConfigMap vem de outro chart ou de outro repositório.
External Secrets, Sealed Secrets ou o CSI de cofre criam o Secret de forma assíncrona. Se a sincronização falha, o pod espera indefinidamente.
Diagnóstico em 3 comandos
Saídas reais de um pod de teste que lê um token de um Secret que não foi criado.
1 · confirme o estado
kubectl -n loja get pod pagamentos NAME READY STATUS RESTARTS AGE
pagamentos 0/1 CreateContainerConfigError 0 109s 2 · o evento diz qual objeto falta
kubectl -n loja describe pod pagamentos | sed -n '/Events:/,$p' Events:
Type Reason Age From Message
Normal Pulled 112s kubelet Successfully pulled image "busybox:1.36" in 3.636s
Warning Failed 8s (x10 over 112s) kubelet Error: secret "gateway-credenciais" not found O Pulled antes do erro mostra que a imagem não é o problema. O x10 over 112s mostra o kubelet tentando de novo.
3 · veja o que existe no namespace e o que o pod pede
kubectl -n loja get secrets,configmaps
kubectl -n loja get pod pagamentos -o jsonpath='{.spec.containers[*].env}' | jq . A correção
Crie o objeto com o nome e a chave exatos que o pod referencia, no mesmo namespace. Não é preciso reiniciar nada: na próxima tentativa o kubelet encontra o Secret e sobe o container.
kubectl -n loja create secret generic gateway-credenciais \
--from-literal=token="$GATEWAY_TOKEN" Se a variável é realmente opcional, marque a referência como opcional. Aí o container sobe sem ela, e cabe à aplicação lidar com a ausência (documentação do Kubernetes, "Secrets", seção sobre Secrets opcionais).
env:
- name: GATEWAY_TOKEN
valueFrom:
secretKeyRef:
name: gateway-credenciais
key: token
optional: true avisoUse optional só para configuração que é de fato opcional. Marcar um token obrigatório como opcional troca um erro claro no pod por uma falha difusa na aplicação.
Em pipelines, aplique Secrets e ConfigMaps antes do Deployment, ou use uma ferramenta que respeite a ordem (Helm aplica por tipo de recurso). Com operadores de segredo, confira o status do objeto que gera o Secret: é lá que aparece o erro de sincronização.
Como aparece no Kubepier
O Kubepier mostra os eventos do pod com os avisos primeiro, com filtro por tipo, namespace e motivo. O diagnóstico por IA explica o erro a partir dos eventos e do log, em português, com a sua chave de API (Anthropic ou OpenAI). Abaixo, uma ilustração com dados fictícios.
Causa provável: o pod pede o Secret gateway-credenciais, que não existe no namespace loja. Evidência: "Error: secret \"gateway-credenciais\" not found" repetido nos eventos. A imagem já foi baixada, então não é problema de registry. Correção sugerida: criar o Secret no namespace loja ou corrigir o nome no Deployment.