Environmental Info:
Host Cluster Configuration:
Host Cluster Version: RKE2 v1.31.5+rke2r1 (configured for IPv4/IPv6 dual-stack)
Host CNI: Cilium (or any CNI)
K3K Cluster Configuration:
K3K Version: v1.2.0-rc2
Shared mode virtual cluster
Describe the bug:
As mentioned by @max06 on #443,
When deploying a shared-mode virtual cluster on a dual-stack host cluster, the k3k controller fails to generate the workload isolation NetworkPolicy.
During reconciliation, the k3k controller attempts to build an egress rule that allows outbound traffic to the internet while blocking traffic to internal cluster nodes. It does this by fetching all PodCIDRs from the host nodes and adding them to the except list of a 0.0.0.0/0 ipBlock.
However, in a dual-stack environment, the controller blindly places both IPv4 and IPv6 PodCIDRs into the same 0.0.0.0/0 except list. The Kubernetes API immediately rejects the manifest because an IPv6 address mathematically cannot be a subset of an IPv4 address.
Because the API rejects the manifest, the NetworkPolicy is never created, leaving the virtual cluster's workloads completely unisolated.
Steps To Reproduce:
- Provision a host Kubernetes cluster configured for dual-stack. Ensure the nodes are assigned both IPv4 and IPv6 PodCIDRs (e.g., ["10.42.0.0/24", "fd42:0:dead::/24"]).
- Create a shared mode k3k cluster
- Check the k3k pod logs on the host cluster:
kubectl logs -n k3k-system k3k-7d9d855c5f-vg2km | grep -i strict
ERROR Reconciler error {"controller": "cluster", "controllerGroup": "k3k.io", "controllerKind": "Cluster", "Cluster": {"name":"dualcilk3k2","namespace":"k3k-system"}, "namespace": "k3k-system", "name": "dualcilk3k2", "reconcileID": "f00e076c-c14d-4111-adc5-098c64aa74f2", "error": "NetworkPolicy.networking.k8s.io \"k3k-dualcilk3k2\" is invalid: spec.egress[0].to[0].ipBlock.except[1]: Invalid value: \"fd42:0:dead::/64\": must be a strict subset of `cidr`"}
- Verify the NetworkPolicy was never created on the host cluster
kubectl get networkpolicy -n k3k-system
No resources found in k3k-system namespace.
Expected behavior:
The controller should group except CIDRs by IP family and emit separate ipBlock rules for IPv4 and IPv6.
IPv4 PodCIDRs should be placed in an except list under cidr: 0.0.0.0/0.
IPv6 PodCIDRs should be placed in an except list under cidr: ::/0.
The NetworkPolicy should be successfully accepted by the Kubernetes API and applied to the virtual cluster namespace.
Actual behavior:
The virtual cluster immediately fails during reconciliation due to an error from the Kubernetes API rejecting the malformed NetworkPolicy:
Environmental Info:
Host Cluster Configuration:
Host Cluster Version: RKE2 v1.31.5+rke2r1 (configured for IPv4/IPv6 dual-stack)
Host CNI: Cilium (or any CNI)
K3K Cluster Configuration:
K3K Version: v1.2.0-rc2
Shared mode virtual cluster
Describe the bug:
As mentioned by @max06 on #443,
When deploying a shared-mode virtual cluster on a dual-stack host cluster, the k3k controller fails to generate the workload isolation NetworkPolicy.
During reconciliation, the k3k controller attempts to build an egress rule that allows outbound traffic to the internet while blocking traffic to internal cluster nodes. It does this by fetching all PodCIDRs from the host nodes and adding them to the except list of a 0.0.0.0/0 ipBlock.
However, in a dual-stack environment, the controller blindly places both IPv4 and IPv6 PodCIDRs into the same 0.0.0.0/0 except list. The Kubernetes API immediately rejects the manifest because an IPv6 address mathematically cannot be a subset of an IPv4 address.
Because the API rejects the manifest, the NetworkPolicy is never created, leaving the virtual cluster's workloads completely unisolated.
Steps To Reproduce:
Expected behavior:
The controller should group except CIDRs by IP family and emit separate ipBlock rules for IPv4 and IPv6.
IPv4 PodCIDRs should be placed in an except list under cidr: 0.0.0.0/0.
IPv6 PodCIDRs should be placed in an except list under cidr: ::/0.
The NetworkPolicy should be successfully accepted by the Kubernetes API and applied to the virtual cluster namespace.
Actual behavior:
The virtual cluster immediately fails during reconciliation due to an error from the Kubernetes API rejecting the malformed NetworkPolicy: