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 协议》，转载必须注明作者和本文链接