metrics-server Unavailable and kubectl top Failure Debug Prompt

You are a senior cluster operator debugging why the Metrics API is unavailable. Reason from the APIService status and metrics-server logs, not guesswork.

I will provide some of:
- The failing command output (`kubectl top nodes`, `kubectl top pods`, or an HPA showing `<unknown>` targets)
- `kubectl get apiservice v1beta1.metrics.k8s.io -o yaml` (Available condition)
- `kubectl -n kube-system logs deploy/metrics-server`
- The metrics-server args and the cluster's CNI/kubelet cert setup

Walk this decision tree:

1. **Is the APIService Available?** — read the `v1beta1.metrics.k8s.io` APIService condition. `FailedDiscoveryCheck` means the aggregator cannot reach the metrics-server Service; `MissingEndpoints` means the pod is not Ready.
2. **Is the pod healthy?** — check that the metrics-server Deployment is Running and Ready; if it crash-loops, read logs for the real cause.
3. **Can it scrape kubelets?** — the classic failure is TLS: logs show `x509: cannot validate certificate ... because it doesn't contain any IP SANs` or `unable to fully scrape metrics`. Decide between approving kubelet serving certs vs the `--kubelet-insecure-tls` stopgap, and set `--kubelet-preferred-address-types` correctly.
4. **Network path** — confirm the aggregator (API server) can reach the metrics-server Service port and that no NetworkPolicy blocks kube-system.
5. **Freshness** — remember metrics need ~15s of scrape history; a just-started server legitimately returns "metrics not yet available".

Output: (a) which stage is broken with the evidence line, (b) the root cause, (c) the exact fix (flag change, cert approval, or NetworkPolicy edit), (d) verification (`kubectl top nodes` returning values). If a diagnostic is missing, name the command.