concepts/architecture/master-node-communication/

Master-Node Communication 主节点通信#

本文档对主服务器（实际上是 apiserver）和 kubernetes 集群之间的通信路径进行了编目。其目的是允许用户自定义其安装以强化网络配置，从而使群集可以在不受信任的网络（或云提供商上的完全公共 IP）上运行。

• Cluster to Master
• Master to Cluster

Cluster to Master#

从集群到主服务器 (master) 的所有通信路径都终止于 apiserver（其他主组件都不设计为公开远程服务）。在典型的部署中，APIServer 配置为在启用了一种或多种形式的客户端身份验证 的安全 https 端口（443）上侦听远程连接。应启用一种或多种形式的授权，尤其是在允许匿名请求或服务帐户令牌的情况下。

应为节点设置群集的公用根证书，以便它们可以与有效的客户端凭据一起安全地连接到 APIServer。例如，在默认的 gke 部署中，提供给 kubelet 的客户端凭据是以客户端证书的形式提供的。参见 kubelet tls bootstrapping 了解 kubelet 客户端证书的自动设置。

Pods that wish to connect to the apiserver can do so securely by leveraging a service account so that Kubernetes will automatically inject the public root certificate and a valid bearer token into the pod when it is instantiated. The kubernetes service (in all namespaces) is configured with a virtual IP address that is redirected (via kube-proxy) to the HTTPS endpoint on the apiserver. 连接到 apiserver 的 pod 可以通过利用服务帐户来安全地连接，这样 kubernetes 将在 pod 被实例化时自动将公共根证书和有效的承载令牌注入到 pod 中。kubernetes 服务（在所有命名空间中）都配置了一个虚拟 IP 地址，该地址被重定向（通过 kube 代理）到 APIServer 上的 https 端点。

the master components also communicate with the cluster apiserver over the secure port. 主组件 (调度器，控制器) 还通过安全端口与集群 APIServer 通信。

因此，默认情况下，从集群（节点及节点运行的 pod）到主机的连接的默认操作模式是安全的，并且可以在不受信任和 / 或公共网络上运行。As a result, the default operating mode for connections from the cluster (nodes and pods running on the nodes) to the master is secured by default and can run over untrusted and/or public networks.

Master to Cluster#

There are two primary communication paths from the master (apiserver) to the cluster. The first is from the apiserver to the kubelet process which runs on each node in the cluster. The second is from the apiserver to any node, pod, or service through the apiserver’s proxy functionality. 从主服务器（APIServer）到集群有两条主通信路径。第一个是从 apiserver 到 kubelet 进程，kubelet 进程在集群中的每个节点上运行。第二个是通过 apiserver 的代理功能从 apiserver 到任何节点、pod 或服务。

apiserver to kubelet#

从 APIServer 到 Kubelet 的连接用于：

• . 获取 pods 日志
• kubectl 连接到 pod 里的容器
• 提供 Kubelet 的端口转发功能.Providing the kubelet’s port-forwarding functionality.

这些连接在 kubelet 的 https endpoint。默认情况下，APIServer 不会验证 kubelet 的服务证书，这会使连接受到中间人攻击，并且不安全在不受信任和 / 或公共网络上运行。

要验证此连接，请使用 --kubelet-certificate-authority 参数在 APIServer 启动时提供一个根证书包，用于验证 kubelet 的服务证书。

如果不可能，请在 apiserver 和 kubelet 之间使用 ssh 隧道，以避免通过不受信任或公共网络进行连接。

最后，应该启用 kubelet 身份验证和 / 或授权 来保护 kubelet api。

apiserver to nodes, pods, and services#

从 apiserver 到节点、pod 或 service 的连接默认为纯 http 连接，因此既不经过身份验证也不加密。它们可以通过在 api url 中的节点、pod 或 service 名前面加上 https: 来在安全的 https 连接上运行，但它们不会验证 https 端点提供的证书，也不会提供客户端凭据，因此在对连接进行加密时，它不会提供任何诚信保证。这些连接目前不安全，无法在不受信任和 / 或公共网络上运行。

SSH Tunnels#

kubernetes 支持 ssh 隧道来保护 master-> 集群通信路径。在这种配置中，apiserver 启动到集群中每个节点的 ssh 隧道（连接到监听端口 22 的 ssh 服务器），并通过隧道传递到 kubelet、节点、pod 或 service 的所有通信量。此隧道确保流量不会暴露在节点运行的网络外部。
ssh 隧道目前已被弃用，因此除非您知道自己在做什么，否则不应选择使用它们。正在设计此通信信道的替代品。

Kubernetes supports SSH tunnels to protect the Master -> Cluster communication paths. In this configuration, the apiserver initiates an SSH tunnel to each node in the cluster (connecting to the ssh server listening on port 22) and passes all traffic destined for a kubelet, node, pod, or service through the tunnel. This tunnel ensures that the traffic is not exposed outside of the network in which the nodes are running.

SSH tunnels are currently deprecated so you shouldn’t opt to use them unless you know what you are doing. A replacement for this communication channel is being designed.

本作品采用《CC 协议》，转载必须注明作者和本文链接