Troubleshoot c8s

Start with the pods and events, then inspect the rendered Helm values:

kubectl get pods -A
kubectl get events -A --sort-by=.lastTimestamp | tail -40
c8s render-values --cvm-mode=bare-metal --hardware-platform=sev-snp --resolve-digests=false

Install failures

Both --cvm-mode (bare-metal, gke, or aks) and --hardware-platform (sev-snp or tdx) are required. Select the deployment mode that matches the node's evidence source. The installer also needs helm and kubectl; with default digest resolution it needs crane and registry access.

If helm --wait times out, inspect kubectl describe pod for the failing component. ImagePullBackOff usually points to a missing image or image-pull Secret. On a self-managed TDX install, check /dev/tdx_guest, qgsd, its quote-generation bridge, and the intel-tdx.node.kubernetes.io/enabled=true node label. The install is an idempotent Helm upgrade: fix the cause and run it again.

A router pod that stays Pending may be competing for host port 443. On an RKE2 node with its bundled ingress, set router.hostPort.enabled: false and use the router Service, or assign a free port.

Workload failures

A confidential.ai/cw workload needs its image digest in the allowlist. Check the pod events and the node NRI image-policy logs when container creation is denied. If the workload remains in Init, inspect the injected c8s-cert container and confirm that CDS is reachable and its measurement pins match the node CVM.

For secret or volume delivery, verify that the workload has the matching allowlist grant and that the injected sidecar is running. Encrypted volumes additionally require c8s install --volumes and a healthy volumed node agent.

Verification failures

A c8s verify exit code of 2 means evidence or policy verification failed; 3 means evidence was unavailable or could not be parsed. Check network reachability, the expected launch measurement, and TDX RTMR pins. Pin the launch digest for production: with no --measurements, any genuine TEE may be accepted. See verify a deployment.