混合版本代理

功能状态: Kubernetes v1.28 [alpha]

Kubernetes 1.31 包含一项 Alpha 功能,允许 API Server 将资源请求代理到其他对等 API Server。当在一个集群中运行着不同版本的 Kubernetes 的多个 API Server 时(例如,在将 Kubernetes 升级到新版本时,升级持续时间很长),这很有用。

这使集群管理员能够配置高可用集群,这些集群可以更安全地升级,方法是将资源请求(在升级期间发出)定向到正确的 kube-apiserver。这种代理可以防止用户看到升级过程导致的意外 404 Not Found 错误。

这种机制称为混合版本代理

启用混合版本代理

启动 API Server 时,请确保已启用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 Server 之间的代理传输和身份验证

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

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

对等 API Server 连接的配置

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

混合版本代理

启用混合版本代理后,聚合层 会加载一个特殊的过滤器,执行以下操作

  • 当资源请求到达无法提供该 API 的 API Server 时(可能是因为它是在引入 API 之前的版本,或者因为 API 在 API Server 上被关闭),API Server 会尝试将请求发送到能够提供请求 API 的对等 API Server。它是通过识别本地服务器无法识别的 API 组/版本/资源,并尝试将这些请求代理到能够处理该请求的对等 API Server 来实现的。
  • 如果对等 API Server 无法响应,则 API Server 将返回 503 ("服务不可用") 错误。

幕后工作原理

当 API Server 收到资源请求时,它首先会检查哪些 API Server 可以提供请求的资源。此检查使用内部 StorageVersion API 进行。

  • 如果收到请求的 API Server 认识该资源(例如,GET /api/v1/pods/some-pod),则该请求将在本地处理。

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

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

    • 如果没有为该 API 组/版本/资源识别到对等方,则处理 API Server 会将其请求传递到其自己的处理程序链,该链最终应返回 404 ("未找到") 响应。

    • 如果处理 API Server 已识别并选择了对等 API Server,但该对等方无法响应(由于网络连接问题或请求接收和控制器将对等方信息注册到控制平面之间的数据竞争等原因),则处理 API Server 将返回 503 ("服务不可用") 错误。

上次修改于 2024 年 2 月 6 日凌晨 12:29 PST: 使用新的 feature_gate_name 选项 (a3f297bc80)