浅谈kubernetes：集群中master节点与node节点之间通讯

Posted 2021-04-16 DevOps云原生应用

DevOps君寄语：在了解了k8s的整体架构后，我们知道整个集群分为master节点和node节点，那么整个k8s集群中master节点与node节点是如何通信的，它们之间是通过什么协议通信，该如何避免集群安全问题。

本文将围绕master与集群通信为话题，深入理解集群中master和node之间是如何通信。

在kubernets集群中，master节点与node节点通讯更确切的说是apiserver与node节点内其他组件通讯（kubelet），这里还要涉及到与node以及pod，services相关的通讯。目的是为了让用户能够自定义他们的安装，对网络配置进行加固，使得集群能够在不可信的网络上（或者在一个云服务商完全公共的 IP 上）运行。

Node节点 -> Master节点（apiserver）通信

Node节点与master节点通讯主要为node上的kubelet组件以及pods应用到apiserver通讯。

所有从集群到 master 的通信路径都终止于 apiserver（其它 master 组件没有被设计为可暴露远程服务，比如：control-manager，scheduler等组件）。在一个典型的部署中，apiserver 被配置为在一个安全的 HTTPS 端口（443）上监听远程连接并启用一种或多种形式的客户端身份认证机制。一种或多种客户端身份认证机制应该被启用(1.基本认证；2.token认证；3.CA双向认证等目前流行的3种认证方法)，特别是在允许使用 匿名请求 或 service account tokens 的时候。

使用集群的公共根证书开通节点，所以它们就能够基于有效的客户端凭据安全的连接 apiserver。例如：在一个默认的 GCE 部署中，客户端凭据以客户端证书的形式提供给 kubelet。请搜索 kubelet TLS bootstrapping 获取如何自动提供 kubelet 客户端证书。

这样的结果使得从集群（在节点上运行的 nodes 和 pods）到 master 的缺省连接操作模式默认被保护，能够在不可信或公网中运行。

Master节点 -> Master节点（apiserver）通信

Master节点与master节点通讯主要为master上的control-manager与scheduler与apiserver之间的通讯。它们之间通讯方式有两种：

本地非安全端口认证

Master 其他组件通过非安全（没有加密或认证）端口和集群的 apiserver 通信。这个端口通常只在 master 节点的 localhost 接口暴露，这样，所有在相同机器上运行的 master 组件就能和集群的 apiserver 通信。

CA安全端口认证

Master其他组件通过安全（加密需认证）端口和集群的apiserver通信，apiserver服务被配置为在一个安全的 HTTPS 端口（443）上监听远程连接并启用客户端身份认证机制。使用集群的公共根证书开通节点，这样master上其他组件就能够基于有效的客户端凭据安全的连接 apiserver，从而与其通信。

Master节点（apiserver） -> Node节点通信

Master节点与node节点通信分为两种：1.master上的apiserver与每个node上运行的kubelet进程通信；2.master上apiserver通过它的代理功能到任何node、pod应用或者service通信。

Apiserver与Kubelet的通信

从 apiserver 到 kubelet 的连接用于获取 pods 日志、连接（通过 kubectl）运行中的 pods，以及使用 kubelet 的端口转发功能。这些连接终止于 kubelet 的 HTTPS endpoint。默认的，apiserver 不会验证 kubelet 的服务证书，这会导致连接遭到中间人攻击，因而在不可信或公共网络上是不安全的。

为了对这个连接进行认证，请使用 --kubelet-certificate-authority 标记给 apiserver 提供一个根证书捆绑，用于 kubelet 的服务证书。

如果这样不可能，又要求避免在不可信的或公共的网络上进行连接，请在 apiserver 和 kubelet 之间使用 SSH 隧道。最后，应该启用Kubelet 用户认证和/或权限认证来保护 kubelet API。

Apiserver与pod，node，service的通信

从 apiserver 到 node、pod或者service 的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密。他们能够通过给API URL 中的 node、pod 或 service 名称添加前缀 https: 来运行在安全的 HTTPS 连接上。但他们即不会认证 HTTPS endpoint 提供的证书，也不会提供客户端证书。这样虽然连接是加密的，但它不会提供任何完整性保证。这些连接目前还不能安全的在不可信的或公共的网络上运行。

SSH隧道（GCE环境）

在谷歌GCE环境中，使用 SSH 隧道保护 Master -> Cluster 通信路径。在这种配置下，apiserver 发起一个到集群中每个节点的 SSH 隧道（连接到在 22 端口监听的 ssh 服务）并通过这个隧道传输所有到 kubelet、node、pod 或者 service 的流量。这个隧道保证流量不会在集群运行的私有 GCE 网络之外暴露。

k8s集群中各个节点组件通信是Kubernetes集群安全一个重要的环节。在实际的生产应用中，强烈建议开启CA证书双向认证保证集群的API的安全。

比较会答疑解惑

比较想你关注我

 长按二维码关注~

点击阅读原文，更多干货等你来分享 。