k8s--基本架构--节点与控制平面之间的通信

最新推荐文章于 2024-04-14 15:06:18 发布

IT艺术家-rookie

最新推荐文章于 2024-04-14 15:06:18 发布

阅读量317

点赞数

分类专栏： k8s与docker容器技术文章标签： kubernetes

本文链接：https://blog.csdn.net/newbiej/article/details/133073416

版权

k8s与docker容器技术专栏收录该内容

24 篇文章 0 订阅

订阅专栏

本文详细描述了Kubernetes中API服务器与节点、节点间及控制平面组件间的通信过程，强调了在不信任网络中的安全配置，如使用HTTPS、SSH隧道和Konnectivity服务来保护通信安全。

摘要由CSDN通过智能技术生成

记录了API服务器和Kubernetes集群之间的通信路径。其目的是允许用户自定义安装，以加固网络配置，从而使集群能够在不受信任的网络上运行（或在云提供商上的完全公共IP上运行）。

简单来说，这篇文档描述了Kubernetes中控制平面（Control Plane）和节点之间的通信方式。控制平面包括API服务器、调度器、控制器和etcd等组件，用于管理和控制整个集群。
节点则是集群中运行实际工作负载的主机。

在Kubernetes中，控制平面和节点之间需要进行多种类型的通信，包括但不限于以下几种：

API服务器与节点：API服务器是集群的管理接口，通过API服务器可以对集群进行各种操作。它需要与节点进行通信，以便获取节点的状态、分配任务、监控节点健康状况等。
控制平面组件之间的通信：调度器、控制器、etcd等控制平面组件也需要相互通信。它们通过API服务器或直接连接到etcd等方式进行通信，以共享信息、协调工作以及保持集群的一致性。
节点之间的通信：在多节点的Kubernetes集群中，节点之间也需要相互通信。这些通信包括容器与容器之间的通信、跨节点的网络流量转发等。这些通信需要通过网络插件（如flannel、Calico等）来实现。

对于在不受信任的网络上运行Kubernetes的情况，您可以通过配置网络策略、使用网络隔离工具（如网络安全组）等方式来增强网络配置，以保护集群的安全性。

控制平面和节点

控制平面和节点之间的网络通信模式以及默认的安全配置。

在Kubernetes中，控制平面和节点之间使用了一种"集线器-分支"（hub-and-spoke）的API模式。
节点（或其上运行的Pod）对API的所有使用都通过API服务器完成。
其他控制平面组件并不设计用于暴露远程服务。API服务器被配置为在一个或多个安全的HTTPS端口（通常为443）上侦听远程连接，并启用一种或多种客户端身份验证方式。应启用一种或多种授权机制，特别是如果允许匿名请求或服务账号令牌。

节点应该使用集群的公共根证书进行配置，以便它们可以安全地连接到API服务器，并使用有效的客户端凭据。
一个好的做法是将提供给kubelet的客户端凭据形式为客户端证书。可以参考kubelet TLS引导启动自动配置kubelet客户端证书。

希望与API服务器连接的Pod可以通过使用Service Account来安全地连接到API服务器。这样，Kubernetes在Pod实例化时会自动注入公共根证书和有效的Bearer令牌到该Pod中。kubernetes服务（在默认命名空间中）配置了一个虚拟IP地址，该地址通过kube-proxy重定向到API服务器上的HTTPS端点。

控制平面组件也通过安全端口与API服务器进行通信。

因此，节点和运行在节点上的Pod与控制平面之间的默认操作模式默认为安全，并且可以在不受信任和/或公共网络上运行。

API服务器到kubelet

API服务器到kubelet的连接用于以下功能：

获取Pod的日志。
附加到正在运行的Pod（通常通过kubectl）。
提供kubelet的端口转发功能。

这些连接终止于kubelet的HTTPS端点。默认情况下，API服务器不验证kubelet的服务证书，这使得连接容易受到中间人攻击，并且在不受信任和/或公共网络上运行时不安全。

为了验证此连接，请使用–kubelet-certificate-authority标志向API服务器提供一个根证书束来验证kubelet的服务证书。

如果无法实现上述操作，请使用SSH隧道在API服务器和kubelet之间进行传输，以避免通过不受信任或公共网络进行连接。

最后，应该启用kubelet的身份验证和/或授权以保护kubelet API的安全性。

API 服务器与节点、Pod 或服务

关于 Kubernetes 中 API 服务器与节点、Pod 或服务之间的连接方式。
默认情况下，API 服务器与节点、Pod 或服务之间的连接采用普通的 HTTP 连接，因此既没有身份验证也没有加密。如果在 API URL 中的节点、Pod 或服务名称前添加了 https: 前缀，可以使用安全的 HTTPS 连接运行，但它们将不会验证由 HTTPS 端点提供的证书，也不提供客户端凭证。因此，虽然连接会被加密，但不会提供完整性的任何保证。这意味着这些连接目前不适合在不受信任或公共网络上运行。

SSH 隧道

使用 SSH 隧道来保护控制平面与节点之间的通信路径。
在这种配置下，API 服务器会向集群中的每个节点发起SSH隧道连接（连接到监听在22端口的SSH服务器），并通过隧道传递所有目标为kubelet、节点、Pod或服务的流量。这个隧道确保流量不会在节点所在的网络之外暴露出来。

使用SSH隧道的方式可以增加通信路径的安全性，通过建立加密的隧道来保护数据传输，防止第三方拦截或修改数据。这种方式特别适用于在不受信任的网络环境中运行的Kubernetes集群，可以确保节点之间的通信受到保护，防止敏感信息泄露或遭到恶意攻击。

SH 隧道目前处于弃用状态，因此除非您知道自己在做什么，否则不应该选择使用它们。Konnectivity 服务是对这种通信通道的替代方案。

Konnectivity 服务

Konnectivity 服务是一个替代 SSH 隧道的功能，它为控制平面到集群之间的通信提供了基于 TCP 层的代理。Konnectivity 服务由两部分组成：控制平面网络中的 Konnectivity 服务器和节点网络中的 Konnectivity 代理。
Konnectivity 代理主动连接到 Konnectivity 服务器并维护网络连接。启用 Konnectivity 服务后，所有控制平面到节点的流量都通过这些连接处理。
官方文档