Kubernetes Architecture --- Master-Node communication

集群到master:

从集群到master的所有的通信路径都会在apiserver处终止。没有其他的master组件被设计成暴露出远程服务。典型的配置中，apiserver会被配置成在安全的https 443端口上监听启用了一种或多种形式的客户端认证远程的连接。应该启用一种或多种的认证，尤其是匿名请求或者已经有允许的服务账户的令牌。

应该给nodes提供集群的公共的root证书，这样他们就能安全的连接到了apiserver带有有效的客户端凭证。例如在默认的gke部署上，提供给kubelet的客户端凭证是采用客户端证书的形式。

希望连接到apiserver的pod通过利用服务账户安全的连接到，这样当pod实例化的时候kubernates可以将证书和token自动注入。所有namespace下的services将会被配置一个虚拟的ip地址以至于可以通过kube-proxy来重定向到apiserver上的https端口。

master组件也会通过安全的端口和cluster的apiserver进行交互。

因此，在默认情况下node和node上的pods的集群到master的连接的默认操作模式是安全的，可以再不受信任的网络和公网上运行。

master到集群：

从master（apiserver）连接到集群主要两种交互的途径。第一种是从apiserve连接到集群中每一个node的kubelet进程上。第二种是从apiserver通过apiserver的代理功能连接到任何的node，pod和service。

apiserver到kubelet：

从apiserver到kubelet的连接主要用于：

获取pod的日志、通过kubelet附加到运行的pods上、为kubelet提供端口转发的功能

这些连接在kubelet的 HTTPS 端口终止。默认情况下，apiserver不会验证kubelet的服务证书，这会时连接遭受到中间人的攻击，在不信任的网络和公网下是不安全的。

为了验证连接，使用--kubelet-certificate-authority 标志来提供apiserver一个root证书包来验证kubelet的服务证书。

如果做不到这一点，要使用ssh通道来避免不受信任的或者公共的网络

最后，应该启用kubelet的身份认证或者授权来保护kubelet api

 

apiserver到nodes，pods和services

这种连接是纯http连接，因此既没有认证也没有加密。他们能运行在安全的连接上，（通过以HTTPS开头，在api url上的node，pod，或者service 的连接），所以这些连接不会验证https 端口提供的证书也不会提供客户端的证书，所以连接将会被加密，否则他们不会提供任何的诚信保证。目前，这些连接在不受信任或公网上运行时是不安全的。