混合版本代理
Kubernetes v1.28 [alpha]
(默认情况下禁用)Kubernetes 1.32 包括一个 alpha 功能,允许 API Server 将资源请求代理到其他 对等 API 服务器。当一个集群中运行多个不同 Kubernetes 版本的 API 服务器时,这很有用(例如,在长期部署到 Kubernetes 新版本期间)。
这使集群管理员能够配置更高可用性的集群,通过将(升级期间)发出的资源请求定向到正确的 kube-apiserver,可以更安全地进行升级。这种代理机制可防止用户看到由升级过程导致的意外 404 未找到错误。
此机制称为 混合版本代理。
启用混合版本代理
启动 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 服务器之间的代理传输和身份验证
源 kube-apiserver 重用现有的 APIserver 客户端身份验证标志
--proxy-client-cert-file
和--proxy-client-key-file
来呈现其身份,其身份将由其对等方(目标 kube-apiserver)验证。目标 API 服务器根据您使用--requestheader-client-ca-file
命令行参数指定的配置来验证对等连接。要验证目标服务器的服务器证书,您必须通过为源 API 服务器指定
--peer-ca-file
命令行参数来配置证书颁发机构捆绑包。
对等 API 服务器连接配置
要设置对等方将用来代理请求的 kube-apiserver 的网络位置,请使用 kube-apiserver 的 --peer-advertise-ip
和 --peer-advertise-port
命令行参数,或在 API 服务器配置文件中指定这些字段。如果未指定这些标志,则对等方将使用 kube-apiserver 的 --advertise-address
或 --bind-address
命令行参数中的值。如果这些也未设置,则使用主机的默认接口。
混合版本代理
启用混合版本代理时,聚合层加载一个特殊的过滤器,该过滤器执行以下操作:
- 当资源请求到达无法提供该 API 的 API 服务器时(要么是因为它所在的版本早于该 API 的引入,要么是在该 API 服务器上禁用了该 API),该 API 服务器会尝试将请求发送到可以提供所请求 API 的对等 API 服务器。它通过识别本地服务器无法识别的 API 组/版本/资源来实现此目的,并尝试将这些请求代理到能够处理该请求的对等 API 服务器。
- 如果对等 API 服务器未能响应,则源 API 服务器将返回 503(“服务不可用”)错误。
工作原理
当 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(“未找到”)响应。
如果处理 API 服务器已识别并选择了一个对等 API 服务器,但该对等方未能响应(由于网络连接问题,或者在接收到请求和控制器将对等方的信息注册到控制平面之间存在数据竞争等原因),则处理 API 服务器会返回 503(“服务不可用”)错误。