这篇文章已经一年多了，较旧的文章可能包含过时的内容。请检查从发表以来，页面中的信息是否变得不正确。

Kubernetes 1.28：用于改进集群安全升级的新（Alpha）机制

作者： Richa Banker (Google)

译者： Xin Li (DaoCloud)

本博客介绍了混合版本代理（Mixed Version Proxy），这是 Kubernetes 1.28 中的一个新的 Alpha 级别特性。当集群中存在多个不同版本的 API 服务器时，混合版本代理使对资源的 HTTP 请求能够被正确的 API 服务器处理。例如，在集群升级期间或当发布集群控制平面的运行时配置时此特性非常有用。

这解决了什么问题？

当集群进行升级时，集群中不同版本的 kube-apiserver 为不同的内置资源集（组、版本、资源）提供服务。 在这种情况下资源请求如果由任一可用的 apiserver 提供服务，请求可能会到达无法解析此请求资源的 apiserver 中；因此，它会收到 404（"Not Found"）的响应报错，这是不正确的。 此外，返回 404 的错误服务可能会导致严重的后果，例如命名空间的删除被错误阻止或资源对象被错误地回收。

如何解决此问题？

"混合版本代理"新特性为 kube-apiserver 提供了将请求代理到对等的、 能够感知所请求的资源并因此能够服务请求的 kube-apiserver。 为此，一个全新的过滤器已被添加到 API

  1. 处理程序链中的新过滤器检查请求是否为 apiserver 无法解析的 API 组/版本/资源（使用现有的 StorageVersion API）。 如果是，它会将请求代理到 ServerStorageVersion 对象中列出的 apiserver 之一。 如果所选的对等 apiserver 无法响应（由于网络连接、收到的请求与在 ServerStorageVersion 对象中注册 apiserver-resource 信息的控制器之间的竞争等原因），则会出现 503（"Service Unavailable"）错误响应。
  2. 为了防止无限期地代理请求，一旦最初的 API 服务器确定无法处理该请求，就会在原始请求中添加一个 （v1.28 新增）HTTP 请求头 X-Kubernetes-APIServer-Rerouted: true。将其设置为 true 意味着原始 API 服务器无法处理该请求，需要对其进行代理。如果目标侧对等 API 服务器看到此标头，则不会对该请求做进一步的代理操作。
  3. 要设置 kube-apiserver 的网络位置，以供对等服务器来代理请求，将使用 --advertise-address 或（当未指定--advertise-address时）--bind-address 标志所设置的值。 如果网络配置中不允许用户在对等 kube-apiserver 之间使用这些标志中指定的地址进行通信， 可以选择将正确的对等地址配置在此特性引入的 --peer-advertise-ip 和 --peer-advertise-port 参数中。

如何启用此特性？

以下是启用此特性的步骤：

  • 下载Kubernetes 项目的最新版本（版本 v1.28.0 或更高版本）
  • 在 kube-apiserver 上使用命令行标志 --feature-gates=UnknownVersionInteroperabilityProxy=true 打开特性门控
  • 使用 kube-apiserver 的 --peer-ca-file 参数为源 kube-apiserver 提供 CA 证书， 用以验证目标 kube-apiserver 的服务证书。注意：这是此功能正常工作所必需的参数。 此参数没有默认值。
  • 为本地 kube-apiserver 设置正确的 IP 和端口，在代理请求时，对等方将使用该 IP 和端口连接到此 --peer-advertise-port 命令行参数来配置 kube-apiserver。 --peer-advertise-port 命令行参数。 如果未设置这两个参数，则默认使用 --advertise-address 或 --bind-address 命令行参数的值。 如果这些也未设置，则将使用主机的默认接口。

少了什么东西？

目前，我们仅在确定时将资源请求代理到对等 kube-apiserver。 接下来我们需要解决如何在这种情况下处理发现请求。 目前我们计划在测试版中提供以下特性：

  • 合并所有 kube-apiserver 的发现数据
  • 使用出口拨号器（egress dialer）与对等 kube-apiserver 进行网络连接

如何进一步了解？

如何参与其中？

通过 Slack：#sig-api-machinery 或邮件列表 联系我们。

非常感谢帮助设计、实施和评审此特性的贡献者： Daniel Smith、Han Kang、Joe Betz、Jordan Liggit、Antonio Ojea、David Eads 和 Ben Luddy！