控制面到节点通信

Kubernetes 采用的是中心辐射型（Hub-and-Spoke）API 模式。所有从集群（或所运行的 Pods）发出的 API 调用都终止于 apiserver。其它控制面组件都没有被设计为可暴露远程服务。 apiserver 被配置为在一个安全的 HTTPS 端口（通常为 443）上监听远程连接请求，并启用一种或多种形式的客户端身份认证机制。一种或多种客户端应该被启用，特别是在允许使用匿名请求或的时候。

应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 apiserver。一种好的方法是以客户端证书的形式将客户端凭据提供给 kubelet。请查看 kubelet TLS 启动引导以了解如何自动提供 kubelet 客户端证书。

想要连接到 apiserver 的 Pod 可以使用服务账号安全地进行连接。当 Pod 被实例化时，Kubernetes 自动把公共根证书和一个有效的持有者令牌注入到 Pod 里。服务（位于名字空间中）配置了一个虚拟 IP 地址，用于（通过 kube-proxy）转发请求到 apiserver 的 HTTPS 末端。

控制面组件也通过安全端口与集群的 apiserver 通信。

这样，从集群节点和节点上运行的 Pod 到控制面的连接的缺省操作模式即是安全的，能够在不可信的网络或公网上运行。

控制面到节点

从 apiserver 到 kubelet 的连接用于：

获取 Pod 日志
挂接（通过 kubectl）到运行中的 Pod

这些连接终止于 kubelet 的 HTTPS 末端。默认情况下，apiserver 不检查 kubelet 的服务证书。这使得此类连接容易受到中间人攻击，在非受信网络或公开网络上运行也是 不安全的。

为了对这个连接进行认证，使用标志给 apiserver 提供一个根证书包，用于 kubelet 的服务证书。

如果无法实现这点，又要求避免在非受信网络或公共网络上进行连接，可在 apiserver 和 kubelet 之间使用 SSH 隧道。

最后，应该启用来保护 kubelet API。

Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。在这种配置下，apiserver 建立一个到集群中各节点的 SSH 隧道（连接到在 22 端口监听的 SSH 服务）并通过这个隧道传输所有到 kubelet、节点、Pod 或服务的请求。这一隧道保证通信不会被暴露到集群节点所运行的网络之外。

SSH 隧道目前已被废弃。除非你了解个中细节，否则不应使用。 Konnectivity 服务是对此通信通道的替代品。

FEATURE STATE:

作为 SSH 隧道的替代方案，Konnectivity 服务提供 TCP 层的代理，以便支持从控制面到集群的通信。 Konnectivity 服务包含两个部分：Konnectivity 服务器和 Konnectivity 代理，分别运行在控制面网络和节点网络中。Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。启用 Konnectivity 服务之后，所有控制面到节点的通信都通过这些连接传输。

请浏览 Konnectivity 服务任务在你的集群中配置 Konnectivity 服务。