混合版本代理

特性状态: Kubernetes v1.28 [alpha] (默认启用:false)

Kubernetes 1.33 包含一个 Alpha 特性,该特性使得 API 服务器能够将资源请求代理到其他 对等 (peer) API 服务器。这在集群中运行多个不同版本 Kubernetes 的 API 服务器时非常有用(例如,在向新版 Kubernetes 进行长期滚动更新期间)。

这使得集群管理员可以配置高可用性集群,通过将(在升级期间发出的)资源请求导向正确的 kube-apiserver,从而更安全地进行升级。这种代理机制可以防止用户看到源自升级过程中出现的意外 404 Not Found 错误。

这种机制称为 混合版本代理(Mixed Version Proxy)

启用混合版本代理

启动 API 服务器 时,确保 UnknownVersionInteroperabilityProxy 特性门控 已启用。

kube-apiserver \
--feature-gates=UnknownVersionInteroperabilityProxy=true \
# required command line arguments for this feature
--peer-ca-file=<path to kube-apiserver CA cert>
--proxy-client-cert-file=<path to aggregator proxy cert>,
--proxy-client-key-file=<path to aggregator proxy key>,
--requestheader-client-ca-file=<path to aggregator CA cert>,
# requestheader-allowed-names can be set to blank to allow any Common Name
--requestheader-allowed-names=<valid Common Names to verify proxy client cert against>,

# optional flags for this feature
--peer-advertise-ip=`IP of this kube-apiserver that should be used by peers to proxy requests`
--peer-advertise-port=`port of this kube-apiserver that should be used by peers to proxy requests`

# …and other flags as usual

API 服务器之间的代理传输和身份认证

  • 源端 kube-apiserver 重用现有的 API 服务器客户端身份认证参数 --proxy-client-cert-file--proxy-client-key-file 来提供其身份,该身份将由其对等端(目标端 kube-apiserver)验证。目标端 API 服务器基于你使用 --requestheader-client-ca-file 命令行参数指定的配置来验证该对等连接。

  • 为了对目标服务器的服务证书进行身份认证,你必须通过向源端 API 服务器指定 --peer-ca-file 命令行参数来配置证书颁发机构捆绑包。

对等 API 服务器连接配置

要设置对等端用于代理请求的 kube-apiserver 的网络位置,请使用 --peer-advertise-ip--peer-advertise-port 命令行参数来启动 kube-apiserver,或在 API 服务器配置文件中指定这些字段。如果这些标志未指定,对等端将使用 kube-apiserver 的 --advertise-address--bind-address 命令行参数的值。如果这些参数也未设置,则使用主机的默认接口。

混合版本代理

当你启用混合版本代理时,聚合层会加载一个特殊过滤器,该过滤器执行以下操作:

  • 当资源请求到达无法处理该 API 的 API 服务器时(可能是因为其版本早于该 API 的引入,或者该 API 在该 API 服务器上已关闭),该 API 服务器会尝试将请求发送到能够处理该请求的对等 API 服务器。它是通过识别本地服务器无法识别的 API 组 / 版本 / 资源,并尝试将这些请求代理到能够处理该请求的对等 API 服务器来完成此操作的。
  • 如果对等 API 服务器未能响应,则 源端 API 服务器会返回 503 ("Service Unavailable") 错误。

内部工作原理

当 API 服务器接收到资源请求时,它首先检查哪些 API 服务器可以处理所请求的资源。此检查通过内部 StorageVersion API 进行。

  • 如果接收到请求的 API 服务器知道该资源(例如,GET /api/v1/pods/some-pod),则请求在本地处理。

  • 如果未找到针对所请求资源的内部 StorageVersion 对象(例如,GET /my-api/v1/my-resource),并且配置的 APIService 指定要代理到扩展 API 服务器,则代理将遵循扩展 API 的常规流程进行。

  • 如果找到了针对所请求资源的有效内部 StorageVersion 对象(例如,GET /batch/v1/jobs),并且尝试处理请求的 API 服务器(处理 API 服务器)禁用了 batch API,则该处理 API 服务器会使用获取到的 StorageVersion 对象中的信息,获取能够处理相关 API 组 / 版本 / 资源(本例中为 api/v1/batch)的对等 API 服务器。然后,处理 API 服务器会将请求代理到了解所请求资源的匹配对等 kube-apiserver 之一。

    • 如果没有已知对等端能够处理该 API 组 / 版本 / 资源,则处理 API 服务器会将请求传递给其自身的处理链,该链最终应返回 404 ("Not Found") 响应。

    • 如果处理 API 服务器已经识别并选择了一个对等 API 服务器,但该对等端未能响应(原因可能是网络连接问题,或者请求被接收与控制器将对等端信息注册到控制平面之间存在竞态条件),则处理 API 服务器会返回 503 ("Service Unavailable") 错误。

最后修改于 2024 年 2 月 6 日 12:29 AM PST: 使用新的 feature_gate_name 选项 (a3f297bc80)