如何为kube-controller-manager与kube-scheduler启用Endpoints？

Hey there! Let's tackle this issue step by step—first, I'll explain why your kube-controller-manager and kube-scheduler endpoints show <none>, then walk you through how to set them up properly so you're ready for kube-prometheus-stack later.

By default, both kube-controller-manager and kube-scheduler are configured to only bind to 127.0.0.1 (localhost) on the control plane node. This means they don't listen on any network interfaces accessible to other parts of the cluster. Kubernetes can't create valid Endpoints for components that only accept local connections, hence the <none> value you're seeing.

Since these components are typically run as static Pods managed by the kubelet on your control plane node, you'll need to modify their manifest files:

1. Locate the component manifest files
   On most Kubernetes distributions, these are stored in /etc/kubernetes/manifests/. You'll find two files:

   • kube-controller-manager.yaml
   • kube-scheduler.yaml

2. Update the bind address configuration
   Open each file and look for the command section. Find the --bind-address flag and change its value from 127.0.0.1 to 0.0.0.0 (to listen on all interfaces) or your control plane node's internal cluster IP.
   Example snippet for kube-controller-manager.yaml:

   command:
     - kube-controller-manager
     - --bind-address=0.0.0.0
     - --secure-port=10257
     # Keep all other existing parameters intact
   

   For kube-scheduler.yaml, the secure port is usually 10259:

   command:
     - kube-scheduler
     - --bind-address=0.0.0.0
     - --secure-port=10259
     # Keep all other existing parameters intact
   

   Note: If you want to use insecure HTTP for testing (not recommended for production), you can also add --insecure-bind-address=0.0.0.0 and set --insecure-port (10252 for controller-manager, 10251 for scheduler). But stick to TLS/secure ports in production.

3. Restart the components
   The kubelet automatically monitors the /etc/kubernetes/manifests/ directory for changes. Once you save the modified files, it will terminate the old Pods and start new ones with the updated configuration. Verify the Pods are running with:

   kubectl get pods -n kube-system | grep -E 'controller-manager|scheduler'
   

4. Check if Endpoints are populated
   Run your original command again after a minute or two:

   kubectl get ep -n kube-system
   

   You should now see the control plane node's IP address followed by the secure port (e.g., 10.0.0.2:10257) for both endpoints.

When you deploy kube-prometheus-stack later, keep these in mind:

• The stack usually includes pre-configured scrape jobs for kube-controller-manager and kube-scheduler, but you'll need to ensure the target addresses match your updated bind address and port.
• If you're using secure TLS ports, make sure Prometheus has access to the CA certificates required to validate the component's TLS certificates. You can usually configure this via the helm chart's values.yaml under the prometheus.prometheusSpec section.

Just a final reminder: Binding to 0.0.0.0 exposes these components to all network interfaces on your control plane node. Ensure your cluster network is properly secured (e.g., network policies, firewall rules) to prevent unauthorized access.

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