This decision was made due to the gardener's default denial of all traffic in the garden namespace, requiring network policies for Ingress controller use.
This aligns with the gardener operator's default behavior, as per official documentation:
The virtual-garden-kube-apiserver Deployment is exposed via a Service of type LoadBalancer with the same name. In the future, we will switch to exposing it via Istio, similar to how the kube-apiservers of shoot clusters are exposed.
For the virtual cluster, it is essential to provide a DNS domain via .spec.virtualCluster.dns.domain. The respective DNS record is not managed by gardener-operator and should be manually created and pointed to the load balancer IP of the virtual-garden-kube-apiserver Service. The DNS domain is used for the server in the kubeconfig, and for configuring the --external-hostname flag of the API server.
In order to align with Gardener, we remove the ingress resource of the Virtual Garden kube-apiserver. Instead, migrate to direct exposal of the kube-apiserver through service type LoadBalancer, which can be configured using the new `gardener_virtual_api_server_public_ip` role parameter. The DNS entry can be switched to the new IP address seamlessly.
Gerrit91
commented
5 months ago
This decision was made due to the gardener's default denial of all traffic in the garden namespace, requiring network policies for Ingress controller use.
This aligns with the gardener operator's default behavior, as per official documentation: