该文档对祝服务器（实际上是 apiserver）与 Kubernetes 集群之间的通信路径进行了分类。目的是允许用户定义其安装以强化网络配置，以便可以在不受信任的网络（或云提供商的完全公共 IP）上运行集群。
集群到主节点
从集群到主机的所有通信路径都在 apiserver 处种植（其他主机组件均未设计为公开远程服务）。在典型部署中，将 apiserver 配置为侦听启用了一种或多种形式的客户端身份验证（敬请期待～～）的安全 HTTPS 端口（443）上的远程连接。应该启用一种或多种形式的授权（敬请期待～～），尤其是在允许匿名请求（敬请期待～～）或服务账户令牌（敬请期待～～）的情况下。
应该为节点配置集群的公根证书，以便它们可以与有效的客户端凭据一起安全地连接到 apiserver。例如，在默认的 GKE 部署中，提供给 kubelet 的客户端凭据采用客户端证书的形式。有关自动配置 kubelet 客户端证书的信息，请参阅 kubelet TLS 引导（敬请期待～～）。
希望连接到 apiserver 的 Pod 可以通过利用服务账户来安全地这样做，以便 Kubernetes 在实例化 Pod 时会自动将公根证书和有效的承载令牌注入 Pod。Kubernetes 服务（在所有命名空间中）都有配置虚拟 IP 地址，该地址被重定向（通过 kube-proxy）到 apiserver 上的 HTTPS 断电。
主组件还通过安全端口与集群 apiserver 通信。
因此，默认情况下，用于保护从集群（节点和节点上运行的 Pod）到主机的连接的默认操作模式可以在不受信任和/或公共网络上运行。
主节点到集群
从主服务器（apiserver）到集群有两条主要通信路径。第一个是从 apiserver 到在集群中每个节点上运行的 kubelet 进程。第二个是通过 apiserver 的代理功能从 apiserver 到任何节点、pod 或服务。
apiserver 到 kubelet
从 apiserver 到 kubelet 的连接用于：
- 为 pod 获取日志；
- （通过 kubectl）附加到正在运行的 pod；
- 提供 kubectl 的端口转发功能。
这些连接在 kubelet 的 HTTPS 端点处终止。默认情况下，apiserver 不会验证 kubelet 的服务证书，该证书会使连接受到中间人攻击，并且无法在不受信任和/或公共网络上运行。
要验证该连接，请使用 --kubelet-certificate-authority 标志为 apiserver 提供根证书捆绑包，以用于验证 kubelet 的服务证书。
如果无法做到这一点，请在 apiserver 和 kubelet 之间使用 SSH 通道（如果需要），以避免通过不可信或公共网络进行连接。
最后，应该启用 Kubelet 身份验证和/或授权（敬请期待～～）以保护 kubelet API。
apiserver 到 节点、pods，及服务
从 apiserver 到节点、pod 或服务的连接默认为纯 HTTP 连接，因此未经身份验证或加密。可以通过在 API URL 中的节点、pod 或服务名称前添加 https: 来在安全的 HTTPS 连接上运行它们，但是它们不会验证 HTTPS 端点提供的证书，也不会提供客户端凭据，因此连接将被加密，它不会提供任何完整性保证。这些连接当前在通过不受信任的和/或公共网络上运行并不安全。
SSH 通道
Kubernetes 支持 SSH 通道来保护主节点 -> 集群通信路径。在该配置中，apiserver 启动到集群中每个节点的 SSH 通道（连接到侦听端口 22 的 SSH 服务器），并通过通道传递发往 kubelet、节点、pod 或服务的所有流量。该通道确保流量不会暴露在运行节点的网络外部。
目前不推荐使用 SSH 通道，因此除非我们知道自己在做什么，否则不要选择使用它们。Konnectivity 服务该通信渠道的替代产品。
Konnectivity 服务
功能状态：Kubernetes v1.18 beta
作为 SSH 通道的替代，Konnectivity 服务提供了 Master -> Cluster 通信的 TCP 级别代理。Konnectivity 由两部分组成，分别是在主网络和集群网络中运行的 Konnectivity 服务器和 Konnectivity 代理。Konnectivity 代理启动与 Konnectivity 服务器的连接并维护连接。然后，所有主节点 -> 集群通信都通过这些连接。
有关如何在集群中进行设置的信息，请参见 Konnectivity 服务搭建（敬请期待～～）。
