Description
I ran into this issue in the kube-aggregator project that accurately describes our ask but we saw it was closed with no comment.
My company is migrating to Kubernetes. We have a custom software networking stack (Discovery, Routing, Traffic Control, etc) that we do not intend to deprecate as part of the migration. This has generally not been a problem; the loosely coupled nature of the k8s design makes it possible for us to create and manage the API objects we care about (Deployments, Pods, Nodes, etc) while integrating with our custom networking stack.
While working on deploying the k8s metrics server, I was surprised to learn that the metrics server (or any API server extension) MUST be deployed as a k8s Service. https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#apiservicespec-v1-apiregistration-k8s-io
This seems like an unnecessary requirement. We can work around it by creating an ExternalName Service (we don't run kube-dns so it doesn't really do much) and then adding the necessary CNAME to our own internal DNS resolver.
We would prefer to just configure a DNS name and the CN of the extension API server's certificate and call it a day.
We are in a similar boat. We, too, have a custom networking stack and a custom CA and we have resorted to non-ideal workarounds to get this to work. We would love to be able to pass an external address for the Extension API Server that also works with TLS (as today, the TLS validation in the assumes the server name ends in .svc https://github.com/kubernetes/kube-aggregator/blob/master/pkg/apiserver/handler_proxy.go#L209)
Since this is pretty important to us, we are willing to do the work to support this!