-
Bug
-
Resolution: Unresolved
-
Normal
-
None
-
4.20.z
-
None
-
False
-
-
None
-
Moderate
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Summary
In an HCP KubeVirt deployment on a DualStack (IPv4/IPv6) OpenShift 4 management cluster, only the `kube-api service` receives both IPv4 and IPv6 addresses from MetalLB by default. Other services configured as `LoadBalancer` via `servicePublishingStrategy` receive only IPv4 addresses.
Description
When deploying HCP KubeVirt on a DualStack IPv4/IPv6 OCP 4 management cluster with default configuration, the `kube-api` service correctly gets both IPv4 and IPv6 addresses assigned by MetalLB.
However, if the `services` section in the `HostedCluster` YAML is modified during cluster creation to explicitly configure `servicePublishingStrategy` as `LoadBalancer` for additional services (e.g., Konnectivity, Ignition), the resulting LoadBalancer services receive only an IPv4 address from MetalLB. IPv6 addresses are not assigned, unlike the `kube-api` service.
Expected Result
All LoadBalancer-type services configured via servicePublishingStrategy should receive both IPv4 and IPv6 addresses from MetalLB in a DualStack environment.
Actual Result
Only the kube-api service receives dual-stack addresses. Other LoadBalancer services receive IPv4 addresses only.
Note: All of the below data is from my test cluster and doesn't contain any sensitive information.
❯ omc get hostedcluster aygarg -oyaml -n clusters | grep -i services -A14 ─╯ services: - service: APIServer servicePublishingStrategy: route: hostname: api.ayush.hcp.com type: Route - service: Ignition servicePublishingStrategy: type: Route - service: Konnectivity servicePublishingStrategy: type: Route - service: OAuthServer servicePublishingStrategy: type: Route ❯ omc get hostedcluster aygarg -oyaml -n clusters | grep -i networking -A7 ─╯ networking: clusterNetwork: - cidr: 10.132.0.0/14 - cidr: fd03::/48 networkType: OVNKubernetes serviceNetwork: - cidr: 172.31.0.0/16 - cidr: fd04::/112 ❯ omc get svc -n clusters-aygarg | grep -i LoadBalancer ─╯ router LoadBalancer 172.30.41.137 192.168.111.26 443:30454/TCP 29m ❯ omc get svc router -n clusters-aygarg -oyaml ─╯ spec: allocateLoadBalancerNodePorts: true clusterIP: 172.30.41.137 clusterIPs: - 172.30.41.137 externalTrafficPolicy: Cluster internalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - name: https nodePort: 30454 port: 443 protocol: TCP targetPort: https selector: app: private-router sessionAffinity: None type: LoadBalancer status: loadBalancer: ingress: - ip: 192.168.111.26 ipMode: VIP ###### Management Cluster ###### ❯ omc get Infrastructure/cluster -oyaml ─╯ infrastructureTopology: HighlyAvailable platform: BareMetal platformStatus: baremetal: apiServerInternalIP: 192.168.111.5 apiServerInternalIPs: - 192.168.111.5 - fd2e:6f44:5dd8:c956::5 ingressIP: 192.168.111.4 ingressIPs: - 192.168.111.4 - fd2e:6f44:5dd8:c956::4 loadBalancer: type: OpenShiftManagedDefault machineNetworks: - 192.168.111.0/24 - fd2e:6f44:5dd8:c956::/120 type: BareMetal
