kube-apiserver如何定位工作节点kubelet及通信机制详解

Great question—since you built your cluster with Kubernetes the Hard Way, you're perfectly positioned to understand the raw, unabstracted interactions between these core components. Let's break this down into two key parts: how the apiserver learns about worker kubelets and how they communicate for metrics and other operations.

1. How kube-apiserver Discovers Worker Kubelets: Kubelet主动注册 #

The short answer: worker node kubelets reach out to the apiserver first to register themselves—the apiserver doesn't "search" for them. Here's the play-by-play tailored to your KTHW setup:

• When you deployed kubelets on your worker nodes, you likely set startup flags like --api-servers=https://<your-lb-ip>:6443 (pointing to your load balancer for the master apiservers) and --register-node=true (this is the default, so you might not have set it explicitly).
• On startup, each kubelet uses its TLS credentials (configured via --tls-cert-file and --tls-private-key-file in KTHW) to authenticate with the apiserver.
• The kubelet sends a Node object to the apiserver containing critical details: the worker node's IP (set via --node-ip in KTHW), the kubelet's listening port (default 10250), node labels, and initial status.
• The apiserver validates the kubelet's identity (using the CA cert you generated during KTHW) and adds the Node object to its storage (etcd). From that point on, the apiserver knows exactly where each worker kubelet is running.

Bonus: Keeping the Connection Alive #

Kubelets send regular heartbeat updates (via the NodeStatus API) to the apiserver. If a kubelet stops sending heartbeats, the apiserver marks the node as NotReady until communication resumes.

2. How kube-apiserver Communicates with Kubelets for Metrics & Operations #

Once the kubelet is registered, the apiserver uses the stored Node object details to initiate communication. Here's how it works:

• Target Address & Port: The apiserver pulls the worker node's IP and kubelet port (10250) directly from the Node object's status.addresses and spec.kubeletPort fields.
• TLS Encrypted Communication: All traffic between apiserver and kubelet is TLS-secured. The apiserver uses the kubelet's CA cert (generated in KTHW) to verify the kubelet's identity, and the kubelet uses the apiserver's CA cert to verify the apiserver's identity—this prevents man-in-the-middle attacks.
• Fetching Metrics & Data: When you run commands like kubectl top node or kubectl describe node, the apiserver acts as a proxy:
  1. It receives your request.
  2. It queries the corresponding kubelet's API endpoints (e.g., /metrics for resource usage, /stats/summary for detailed node/pod stats).
  3. It formats the kubelet's response and sends it back to your kubectl client.

Note on Your Master Node Setup #

Since you didn't deploy kubelets on your master nodes, those nodes never register with the apiserver—so the apiserver only knows about your two worker nodes. This is a valid setup (many production clusters run masters without kubelets to reduce attack surface and resource usage).

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