本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

Kubernetes 1.28：一种新的（Alpha）机制，用于更安全的集群升级

作者：Richa Banker (Google) |

这篇博客介绍了 Kubernetes 1.28 中的一个新 Alpha 特性——**混合版本代理**（mixed version proxy）。混合版本代理使得在集群中存在多个不同版本的 API 服务器时，针对某个资源的 HTTP 请求能够被正确的 API 服务器处理。例如，这在集群升级或滚动更新集群控制平面的运行时配置时非常有用。

这解决了什么问题？

当集群进行升级时，该场景下不同版本的 kube-apiserver 可能会提供不同集合（组、版本、资源）的内置资源。在这种情况下发出的资源请求可能会被任何一个可用的 apiserver 处理，这可能导致请求最终被一个不了解所请求资源的 apiserver 处理；因此，请求会收到一个不正确的 404 not found 错误。此外，不正确地处理 404 错误可能会导致严重的后果，例如命名空间删除被错误地阻止或对象被错误地垃圾回收。

我们如何解决这个问题？

新的特性“混合版本代理”为 kube-apiserver 提供了将请求代理到能够识别所请求资源并因此能够处理该请求的对等 kube-apiserver 的能力。为此，在 API 服务器的聚合层的处理链中增加了一个新的过滤器。

  1. 处理链中的新过滤器会检查请求是否针对一个 apiserver 不知道的组/版本/资源（使用现有的 StorageVersion API）。如果是，它会将请求代理到 ServerStorageVersion 对象中列出的某个 apiserver。如果识别出的对等 apiserver 未能响应（由于网络连接、请求接收与控制器在 ServerStorageVersion 对象中注册 apiserver-资源信息之间的竞争等原因），则会返回 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 传递 CA 捆绑包，源 kube-apiserver 将使用它来验证目标 kube-apiserver 的服务证书。注意：这是此特性工作的必需标志。此标志没有默认值。
  • 在启动时，向 kube-apiserver 传入正确的本地 kube-apiserver 的 IP 和端口，对等方在代理请求时将使用这些信息连接到此 kube-apiserver。使用 --peer-advertise-ip 和 peer-advertise-port 标志。如果未设置，则使用传递给 --advertise-address 或 --bind-address 的值。如果这些也未设置，将使用主机的默认接口。

还缺少什么？

目前，我们只在确定需要时将资源请求代理到对等的 kube-apiserver。接下来，我们需要解决如何处理发现（discovery）请求在这种场景下的问题。目前我们计划为 Beta 版本实现以下功能：

  • 合并所有 kube-apiserver 的发现信息
  • 使用 egress dialer 与对等 kube-apiserver 建立网络连接

我如何了解更多信息？

我如何参与？

通过 Slack 上的 #sig-api-machinery 频道或邮件列表与我们联系。

非常感谢为该特性的设计、实现和审查做出贡献的人员：Daniel Smith, Han Kang, Joe Betz, Jordan Liggit, Antonio Ojea, David Eads 和 Ben Luddy！