Peer Pods is the deployment model for CoCo (Confidential Containers) designed for public cloud environments where the Kubernetes worker nodes are standard VMs — not bare metal — and therefore cannot host a nested confidential VM for each pod. The fundamental constraint it solves is physical: confidential computing hardware (TDX, SEV-SNP) does not support nested virtualisation, meaning a confidential guest cannot be launched inside another VM. In the conventional CoCo deployment, the Kata Containers runtime asks a local hypervisor (QEMU/KVM) on the worker node to create a micro-VM for each pod; if the worker node is itself a VM, this requires nested virtualisation that the TEE hardware cannot provide. Peer Pods sidestep this entirely by moving the pod’s VM off the worker node and onto a separate, cloud-provisioned instance running directly on bare-metal TEE-capable hardware.
The mechanism is the Cloud API Adaptor (CAA), a daemonset running on each Kubernetes worker node that implements Kata Containers’ remote hypervisor interface. When the Kata shim would normally call a local hypervisor to create a pod sandbox VM, it instead calls the CAA over a local socket. The CAA translates that request into a cloud provider API call — Azure VM API, AWS EC2, IBM Cloud, or others — to provision a new TEE-capable instance (a CVM) on the provider’s infrastructure. A network tunnel is then established between the worker node and the remote pod VM, through which the Kata agent inside the VM communicates with the Kata shim on the node as if the VM were local. From Kubernetes’ perspective the pod behaves identically to any other Kata pod: the worker node schedules it, the kubelet manages its lifecycle, and standard kubectl tooling works unchanged. The pod VM itself, however, is a first-class CVM on the cloud provider’s physical TEE hardware — a genuine SEV-SNP guest or TDX Trust Domain, not a nested VM.
The attestation and secret delivery flow is the same as in conventional CoCo: the Attestation Agent inside the peer pod VM collects hardware evidence, presents it to Trustee (KBS/AS), and receives secrets only after the evidence validates. The key operational trade-off of peer pods is latency: each pod start requires a cloud API call to provision a new VM, which adds seconds compared to the milliseconds of a local VM launch. This makes peer pods better suited to longer-lived, latency-tolerant workloads — inference services, batch jobs, data processing pipelines — than to short-lived or highly burst-scheduled tasks. In exchange, peer pods allow CoCo to run on any managed Kubernetes service (AKS, GKE, ROSA, IKS) without any special worker node configuration, making confidential containers accessible to the vast majority of cloud Kubernetes users who have no access to bare-metal nodes.