Your Initial Understanding is Correct #

First off, great call on your initial understanding—you’re totally on the right track!

When you run kubectl get pods --all-namespaces, here’s exactly what happens:

• kubectl reads your ~/.kube/config file to grab the cluster endpoint (in your case, 192.168.64.2:8443), along with authentication credentials (like client certificates, tokens, or username/password) and TLS settings.
• It constructs an HTTPS request to the Kubernetes API server at the path https://192.168.64.2:8443/api/v1/pods (the --all-namespaces flag adds a query parameter ?allNamespaces=true to fetch pods across all namespaces).
• The API server validates your credentials, processes the request, and returns the pod data back to kubectl, which formats it for you to read.

How kubectl "Knows" the Metrics Server IP #

Your question about the Metrics Server is a great one—kubectl isn’t actually connecting directly to 172.17.0.8:4443 on its own. Here’s the breakdown:

• When you deploy the Metrics Server, it registers its API group (metrics.k8s.io) and version (v1beta1) with the Kubernetes API server. This is part of Kubernetes’ API discovery mechanism.
• When you run kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes/<NODE_NAME>, kubectl first sends a request to the main API server (192.168.64.2:8443) to discover where the metrics.k8s.io API is hosted.
• The API server acts as a proxy: it forwards your request to the Metrics Server’s service endpoint (172.17.0.8:4443), retrieves the metrics data, and sends it back to kubectl.
• That’s why you don’t have to specify the Metrics Server IP manually—kubectl relies on the API server to handle routing to all registered API extensions.

Do All kubectl Commands Point to the Same IP? #

Not exactly, but by default, yes—most kubectl commands target the main Kubernetes API server defined in your current kubeconfig context. Here are the exceptions:

• If you use the --server flag to explicitly specify a different API endpoint, kubectl will send requests there instead.
• For some custom controllers or API extensions, you might configure kubectl to connect directly to their endpoints (though this is rare; the standard pattern is to go through the main API server as a proxy).
• If you switch kubeconfig contexts (using kubectl config use-context <CONTEXT_NAME>), kubectl will target the cluster endpoint defined in that context, which could be a different IP/port.

In short: kubectl’s primary target is always the API server of your current cluster context, and other services like Metrics Server are accessed through that API server’s proxying capability.

内容的提问来源于stack exchange，提问作者pandawithcat