免责声明：本文发表已超过一年。旧文章可能包含过时内容。请核实页面信息自发布以来是否已发生变化。
Kubernetes 1.28：一种更安全集群升级的新（Alpha）机制
本文介绍了 混合版本代理，这是 Kubernetes 1.28 中的一个新 Alpha 特性。混合版本代理使得在集群中存在多个不同版本的 API 服务器时，资源的 HTTP 请求可以由正确的 API 服务器处理。例如，这在集群升级期间或推出集群控制平面的运行时配置时非常有用。
这解决了什么问题？
当集群进行升级时，在这种场景下，不同版本的 kube-apiservers 可能提供不同集合（组、版本、资源）的内置资源。在这种情况下发出的资源请求可能由任何可用的 apiserver 处理，可能导致请求到达一个可能不知道所请求资源的 apiserver；因此返回不正确的 404 未找到错误。此外，错误地返回 404 错误可能导致严重后果，例如命名空间被错误地阻止删除或对象被错误地垃圾回收。
我们如何解决这个问题？
新特性“混合版本代理”为 kube-apiserver 提供了将请求代理到知道所请求资源并因此可以处理请求的对等 kube-apiserver 的能力。为此，在 API 服务器的聚合层处理链中添加了一个新过滤器。
- 处理链中的新过滤器检查请求是否针对 apiserver 不知道的组/版本/资源（使用现有的 StorageVersion API）。如果是，它将请求代理到 ServerStorageVersion 对象中列出的其中一个 apiserver。如果识别出的对等 apiserver 未能响应（原因如网络连接问题，请求接收与控制器在 ServerStorageVersion 对象中注册 apiserver-资源信息之间的竞争），则返回 503（“服务不可用”）错误。
- 为了防止请求无限期地代理，一旦确定原始 API 服务器无法处理该请求，就会在原始请求中添加一个（v1.28 新增）HTTP 头
X-Kubernetes-APIServer-Rerouted: true。将其设置为 true 表示原始 API 服务器无法处理该请求，因此应该进行代理。如果目标对等 API 服务器看到此头部，它就不会再将请求进一步代理。 - 为了设置对等节点将用于代理请求的 kube-apiserver 的网络位置，使用
--advertise-address中传递的值，或者（当--advertise-address未指定时）使用--bind-address标志的值。对于网络配置不允许对等 kube-apiserver 使用这些标志中指定的地址进行通信的用户，可以选择通过此特性引入的--peer-advertise-ip和--peer-advertise-port标志传递正确的对等地址。
如何启用此特性？
以下是启用该特性所需的步骤
- 下载最新 Kubernetes 项目（版本
v1.28.0或更高） - 在 kube-apiservers 上使用命令行标志
--feature-gates=UnknownVersionInteroperabilityProxy=true开启特性门 - 在 kube-apiservers 上使用
--peer-ca-file标志传递源 kube-apiserver 将用于验证目标 kube-apiserver 服务证书的 CA 捆绑包。注意：这是此特性工作所需的强制标志。此标志没有默认值。 - 传递本地 kube-apiserver 的正确 IP 和端口，对等节点在代理请求时将使用这些信息连接到此 kube-apiserver。启动 kube-apiservers 时使用
--peer-advertise-ip和peer-advertise-port标志。如果未设置，则使用传递给--advertise-address或--bind-address的值。如果这些也未设置，将使用主机的默认网络接口。
目前缺少什么？
目前我们只在确定需要代理时，才将资源请求代理到对等 kube-apiserver。接下来我们需要解决在这种场景下如何处理发现请求。目前我们计划在 Beta 版本中包含以下能力
- 合并所有 kube-apiserver 的发现信息
- 对连接对等 kube-apiserver 的网络连接使用 egress dialer
如何了解更多信息？
如何参与贡献？
在Slack 上联系我们：#sig-api-machinery，或通过邮件列表。
非常感谢参与此特性设计、实现和评审的贡献者：Daniel Smith, Han Kang, Joe Betz, Jordan Liggit, Antonio Ojea, David Eads 和 Ben Luddy！