k8s--基础架构--Mixed Version Proxy

Mixed Version Proxy 是 Kubernetes 1.28 中的一个新特性，处于 alpha 阶段。
能干什么：它允许 API Server 将资源请求代理给其他同伴 API Server。
应用场景：这在集群中存在多个运行不同 Kubernetes 版本的 API Server 时非常有用，例如在长期部署新版本 Kubernetes 过程中。

这个特性使得集群管理员能够配置高可用的集群，并更安全地进行升级，通过将资源请求（在升级过程中发出的请求）定向到正确的 kube-apiserver。这种代理机制可以防止用户在升级过程中看到意外的 404 Not Found 错误。

简而言之，Mixed Version Proxy 允许在 Kubernetes 升级过程中，通过代理机制将资源请求定向到正确的 API
Server，确保用户正常访问，并避免由于升级过程引起的错误。

开启Mixed Version Proxy 特性

当启动 API Server 时，需确保已启用 UnknownVersionInteroperabilityProxy 的 feature gate。

下面是一些在启用该特性时需要使用的命令行参数：

--feature-gates=UnknownVersionInteroperabilityProxy=true：启用 Mixed Version Proxy 特性的 feature gate。

--peer-ca-file=：指定 kube-apiserver 的 CA 证书路径。

--proxy-client-cert-file=：指定聚合器代理证书的路径。

--proxy-client-key-file=：指定聚合器代理密钥的路径。

--requestheader-client-ca-file=：指定聚合器 CA 证书的路径。

--requestheader-allowed-names=：指定用于验证代理客户端证书的有效 Common Name。

--peer-advertise-ip=（可选）：指定此 kube-apiserver 的 IP 地址，供同伴使用以代理请求。

--peer-advertise-port=（可选）：指定此 kube-apiserver 的端口号，供同伴使用以代理请求。

除以上参数外，你还可以使用其他常规的标志参数来配置 API Server。

请注意，这是一个示例配置，并且在实际部署时，你需要根据自己集群的具体情况进行相应的配置。

API servers之间的代理传输和认证

1. 在 API Server 之间进行代理传输和认证时，源 kube-apiserver 会重用现有的 API Server 客户端认证标志 --proxy-client-cert-file 和 --proxy-client-key-file 来展示自己的身份，这将由其对等体（目标 kube-apiserver）进行验证。目标 API Server 根据你使用 --requestheader-client-ca-file 命令行参数指定的配置来验证对等体连接。

2. 为了验证目标服务器的服务证书，你需要通过在源 API Server 上使用 --peer-ca-file 命令行参数来配置一个证书颁发机构（Certificate Authority）捆绑包。这样源 API Server 才能验证目标服务器的身份。

简而言之，通过指定 --proxy-client-cert-file 和 --proxy-client-key-file 来展示源 API Server 的身份，通过 --requestheader-client-ca-file 来配置验证对等体连接，通过 --peer-ca-file 来验证目标服务器的服务证书。

配置用于对等节点 API 服务器连接

这是关于配置用于对等节点 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 服务器。
• 如果对等 API 服务器无法响应，源 API 服务器将以 503（“服务不可用”）错误响应。

API 服务器在处理资源请求时的工作原理

当一个 API 服务器接收到资源请求时，首先会通过内部的 StorageVersion API 来检查哪些 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 组/版本/资源的匹配的对等方kube-apiserver。然后，处理 API 服务器将请求代理到其中一个匹配的对等方 kube-apiserver，这些对等方 kube-apiserver知道所请求的资源。

如果对于该 API 组/版本/资源没有已知的对等方，那么处理 API 服务器将将请求传递给自身的处理链，该处理链最终应返回 404（“Not Found”）响应。

如果处理 API 服务器已标识并选择了一个对等方 API 服务器，但该对等方无法响应（原因可能是网络连接问题或请求接收与控制平面中的控制器注册对等方信息之间存在数据竞争等），那么处理 API 服务器将返回 503（“Service Unavailable”）错误。
官网文档