## Summary Expose the cluster k8s API/Ingress virtual IP (`cluster_virtual_ip`) on IPv6 as well, so that dual-stack Sylva clusters can be reached over IPv6 too, not just over IPv4. Today `cluster_virtual_ip` is a IPv4-only used in `sylva-core`/`sylva-units` and `sylva-capi-cluster`. ### References of dev work to be merged as a first implementation of dual-stack - [sylva-core !7761](https://gitlab.com/sylva-projects/sylva-core/-/merge_requests/7761) - [sylva-capi-cluster !1003](https://gitlab.com/sylva-projects/sylva-elements/helm-charts/sylva-capi-cluster/-/merge_requests/1003) - [metallb-resources !86](https://gitlab.com/sylva-projects/sylva-elements/helm-charts/metallb-resources/-/merge_requests/86) - [sylva-library !158](https://gitlab.com/sylva-projects/sylva-elements/helm-charts/sylva-library/-/merge_requests/158) ## Context The dual-stack work mentioned above (CNI, CoreDNS, MetalLB, capm3/capo network and security-groups) makes cluster networking itself dual-stack. The cluster's VIP — used for the Kubernetes API endpoint, Ingress Controller and k8s-gateway — is not: it's still IPv4-only. ## Constraint Cluster API's `controlPlaneEndpoint` (`Cluster.spec.controlPlaneEndpoint`/ `Metal3Cluster.spec.controlPlaneEndpoint`) is a single `{host, port}` struct — it cannot hold two hosts. There is no way to make the API endpoint natively dual-stack at the CAPI object level: one address family has to be set and the other exposed as a secondary. We would keep IPv4 as the `controlPlaneEndpoint` / `apiServerFixedIP` config and add the IPv6 VIP as a secondary, additive exposure (extra address pool + extra cert SAN) — the similar pattern Sylva uses for `cluster_public_ip` as an "additional address" alongside the default one. ### Proposed setup - Keep `cluster_virtual_ip` as IPv4 only and add a new field `cluster_virtual_ipv6`. `metallb-resources` has in `templates/ipaddresspool.yaml` a single `lbpool` IPAddressPool (`{{ .Values.cluster_virtual_ip }}/32`). It needs a second branch adding a `/128` ipaddresspool for the v6 VIP (MetalLB's L2 mode supports IPv6 via NDP — no MetalLB code change). - certSANs / tls-san: additive and low-risk — kubeadm and RKE2 support appending extra SANs (same mechanism as `cluster_public_ip` / `cluster_api_cert_extra_SANs` today); add the v6 VIP there so `https://[vip6]:6443` gets a valid certificate. - kube-vip (kubeadm): the `kube-vip.io/loadbalancerIPs` annotation would need both addresses (kube-vip supports dual-stack, comma-separated) - RKE2 (cabpr) path: the bootstrap NAT trick uses hardcoded `iptables` DNAT rules (port 6443/9345 → localhost) — would need `ip6tables` equivalent with an IPv6 VIP. The reason why this is done in Sylva is explained [here](https://gitlab.com/sylva-projects/sylva-elements/helm-charts/sylva-capi-cluster/-/merge_requests/445). ### CAPO specifics - `cluster_virtual_ip` is injected into the `metallb-resources` and `cluster` units via the `capo-cluster-resources` job/ConfigMap, backed by a Neutron port (`cluster_virtual_ip_port_uuid`) rather than a static value. Since this port is part of the dual-stack primary network, it will also be assigned with an IPv6 address that can be used as for `cluster_virtual_ipv6` value. - `OpenStackCluster` has `apiServerFixedIP` as a single-host - keep the IPv4 one - `allowedAddressPairs` already understand IPv6 addresses (from - [sylva-capi-cluster !1003](https://gitlab.com/sylva-projects/sylva-elements/helm-charts/sylva-capi-cluster/-/merge_requests/1003)), so once a v6 VIP address exists it should be straightforward to add to the existing allow-list. - Security group rules for the API endpoint over IPv6 need checking — likely already covered by the existing dual-stack security group, should be verified. ### Ingress Controller and k8s-gateway Both `rke2-ingress-nginx` (`controller.service`) and `k8s-gateway` (`service`) get their LoadBalancer IP the same way `cluster-vip` and `metal3-ironic` do: via `_internal.lb_service_annotations`, which resolves to either `metallb_service_annotations` (`metallb.io/loadBalancerIPs` + `metallb.io/allow-shared-ip: cluster-external-ip`) or `kube_vip_service_annotations` (`kube-vip.io/loadbalancerIPs`) depending on whether the `metallb` unit is enabled — all four currently point at the single IPv4 `cluster_virtual_ip`. - Extending `metallb_service_annotations`/`kube_vip_service_annotations` to carry both addresses (both MetalLB and kube-vip accept comma-separated dual-stack `loadBalancerIPs`) is a single shared change that benefits `cluster-vip`, `metal3-ironic`, `k8s-gateway`, and `rke2-ingress-nginx` all at once. - Each of these Services would also need `ipFamilyPolicy: RequireDualStack` set explicitly via Helm values when `ipv6_enabled` — none of them set it today (confirmed live: both are `SingleStack`/IPv4-only) — mirroring what !7761 already did for the CoreDNS Service. - `k8s-gateway` itself should need no extra change beyond that: it resolves Ingress FQDNs from `Ingress.status.loadBalancer.ingress[].ip`, so once `rke2-ingress-nginx`'s Service reports both an IPv4 and IPv6 address, AAAA answers should follow automatically.