为什么k8s控制平面不使用10251和10252端口？

Question

我正在关注此内容，并要求我们的 IT 团队为我打开硬件防火墙端口：

\n

控制平面节点

\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

协议	方向	端口范围	目的	使用者
传输控制协议	入境	6443*	Kubernetes API 服务器	全部
传输控制协议	入境	2379-2380	etcd 服务器客户端 API	kube-apiserver、etcd
传输控制协议	入境	10250	库贝莱特API	自控平面
传输控制协议	入境	10251	kube 调度程序	自己
传输控制协议	入境	10252	kube 控制器管理器	自己

\n

\n

工作节点

\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n \n\n

协议	方向	端口范围	目的	使用者
传输控制协议	入境	10250	库贝莱特API	自控平面
传输控制协议	入境	30000-32767	NodePort 服务\xe2\x80\xa0	全部

\n

\n

在我要求 IT 为我打开硬件端口之前，我检查了没有硬件防火墙的本地环境，我看到了以下内容：

\n

# netstat -oanltp | grep 10250\ntcp6       0      0 :::10250       :::*              LISTEN      3914/kubelet         off (0.00/0/0)\n# netstat -oanltp | grep 10251\n# netstat -oanltp | grep 10252\n

\n

10251您可以看到和上没有任何内容正在监听10252。但我的kube-scheduler和kube-controller-manager正在运行，一切看起来都正常：

\n

kube-system   kube-controller-manager-shlava     1/1     Running     0          47h     10.192.244.109   \nkube-system   kube-scheduler-shlava              1/1     Running     0          47h     10.192.244.109   \n

\n

所以我想知道：没有人在监听10251和是正常的吗10252？

\n

Answer 1

答案是：这取决于。

• --port您可能已使用标志指定了不同的端口来提供 HTTP 服务
• 您可能已经完全禁用了 HTTP 服务--port 0
• 您使用的是最新版本的K8s

最后一个是最有可能的，因为Creating a cluster with kubeadm声明它是为版本1.21编写的

端口10251和10252已在版本1.17中被替换（更多信息请参见此处）

Kubeadm：启用安全 kube-scheduler 和 kube-controller-manager 端口进行运行状况检查。对于 kube-scheduler 是 10251，变为 10259。对于 kube-controller-manager 是 10252，变为 10257。

此外，此功能在1.19中已不再使用（更多信息请参见此处）

Kube-apiserver：组件状态 API 已弃用。该 API 提供了 etcd、kube-scheduler 和 kube-controller-manager 组件的状态，但仅当这些组件位于 API 服务器本地且 kube-scheduler 和 kube-controller-manager 暴露不安全的运行状况端点时才有效。etcd 健康状况包含在 kube-apiserver 健康检查中，而不是此 API，并且可以直接针对这些组件的健康端点进行 kube-scheduler/kube-controller-manager 健康检查。

文档的某些部分似乎已经过时了。