Registering an Extension API Server
The APIService object is the registration record that wires a URL path to a backend service. It lives in the apiregistration.k8s.io/v1 API group, which is itself part of the core API server (not aggregated).
A fully annotated example, registering the Metrics Server's API group, names the object following the <version>.<group> pattern, declares the group and version it claims ownership of, points service at the Kubernetes Service fronting the Extension API Server Pod, supplies a base64-encoded caBundle to verify that backend's TLS certificate (or, only outside production, sets insecureSkipTLSVerify: true instead), and sets priority fields controlling ordering when multiple API versions exist for the same group.
What each field does:
| Field | Purpose |
|---|---|
group + version |
Defines which URL path (/apis/<group>/<version>) this APIService intercepts |
service |
The Kubernetes Service (ClusterIP) that the API server proxies to |
caBundle |
The CA cert the API server uses to verify the backend's TLS identity |
insecureSkipTLSVerify |
Skip TLS verification — only acceptable in development |
groupPriorityMinimum |
Minimum priority for the group in API discovery |
versionPriority |
Priority of this version within the group (higher = preferred) |
Checking registration status means reading the APIService's status.conditions field. A healthy one shows an Available condition with status: "True" and a "checks passed" message. An unhealthy one shows status: "False" with a message like connection refused or x509: certificate signed by unknown authority.
A common platform engineering interview question: "Your HPA stopped scaling even though CPU is clearly high. How do you debug it?" The answer starts with kubectl get apiservice v1beta1.metrics.k8s.io — if it shows Available: False, the Metrics Server is the culprit, not the HPA configuration. Then check kubectl logs -n kube-system deployment/metrics-server for TLS or connectivity errors.