这篇文章已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。
Kubernetes 1.28：用于更安全集群升级的新 (alpha) 机制
这篇博客描述了混合版本代理，这是 Kubernetes 1.28 中的一项新的 Alpha 功能。在集群中存在多个不同版本的 API 服务器的情况下，混合版本代理允许将资源的 HTTP 请求发送到正确的 API 服务器。例如，这在集群升级期间，或在部署集群控制平面的运行时配置时非常有用。
它解决了什么问题？
当集群进行升级时，在这种情况下，不同版本的 kube-apiserver 可以提供不同组（组、版本、资源）的内置资源。在这种情况下发出的资源请求可能由任何可用的 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 和端口，对等方将在代理请求时使用该 IP 和端口连接到此 kube-apiserver。在启动时，将标志
--peer-advertise-ip和peer-advertise-port传递给 kube-apiservers。如果未设置，则使用传递给--advertise-address或--bind-address的值。如果这两个值也未设置，则将使用主机的默认接口。
缺少什么？
目前，我们仅在确定要代理时才将资源请求代理到对等 kube-apiserver。接下来，我们需要解决在这种情况下如何处理发现请求。现在我们计划为 beta 版本提供以下功能
- 跨所有 kube-apiserver 的合并发现
- 对与对等 kube-apiserver 建立的网络连接使用出口拨号器
如何了解更多？
如何参与？
在 Slack 上联系我们：#sig-api-machinery，或通过邮件列表。
非常感谢参与此功能的设计、实现和审查的贡献者：Daniel Smith、Han Kang、Joe Betz、Jordan Liggit、Antonio Ojea、David Eads 和 Ben Luddy！