Kubernetes v1.36：Mixed Version Proxy 升级为 Beta

早在 Kubernetes 1.28 中，我们曾在一篇博客文章中将 Mixed Version Proxy（MVP）作为 Alpha 功能引入（位于功能门控 UnknownVersionInteroperabilityProxy 下）。其目标简单但关键：通过确保对旧版 API 服务器尚未知晓资源的请求被正确路由到较新的对等 API 服务器，而不是返回错误的 404 Not Found，从而让集群升级更加安全。

我们很高兴地宣布，Mixed Version Proxy 将在 Kubernetes 1.36 中升级为 Beta，并将默认启用！自首次发布以来，该功能已显著演进，弥补了关键缺口并使其架构现代化。

下面介绍该功能是如何演进的，以及你需要了解哪些内容才能在集群中利用它。

我们要解决什么问题？

在正在升级的高可用控制平面中，你通常会有运行不同版本的 API 服务器。这些服务器可能提供不同的 API 集合（组、版本、资源）。如果没有 MVP，当客户端请求落到一个不提供所请求资源的 API 服务器上时（例如升级中引入的新 API 版本），该服务器会返回 404 Not Found。从技术上讲这是不正确的，因为该资源在集群中可用，只是不在那台特定服务器上可用。这可能导致严重的副作用，例如误判的垃圾回收或命名空间删除被阻塞。MVP 通过将请求代理到能够提供该资源的对等 API 服务器来解决这一问题。

sequenceDiagram
    participant Client
    participant API_Server_A as API Server A (Older/Different)
    participant API_Server_B as API Server B (Newer/Capable)
    
    Client->>API_Server_A: 1. Request for Resource (e.g., v2)
    Note over API_Server_A: Determines it cannot serve locally
    API_Server_A->>API_Server_A: 2. Looks up capable peer in Discovery Cache
    API_Server_A->>API_Server_B: 3. Proxies request (adds x-kubernetes-peer-proxied header)
    API_Server_B->>API_Server_B: 4. Processes request locally
    API_Server_B-->>API_Server_A: 5. Returns Response
    API_Server_A-->>Client: 6. Forwards Response

自 1.28 以来它如何演进

最初的 Alpha 实现是一个很好的概念验证，但存在一些局限，并依赖较旧的机制。下面介绍我们为 Beta 对其进行现代化改造的方式：

1. 从 StorageVersion API 到 Aggregated Discovery 在 Alpha 版本中，API 服务器依赖 StorageVersion API 来判断哪些对等节点提供哪些资源。虽然该方法可用，但有一个显著限制：StorageVersion API 尚不支持 CRD 和聚合 API。对于 Beta，我们已将对 StorageVersion API 调用的依赖替换为使用 Aggregated Discovery。API 服务器现在使用聚合发现数据来动态了解其对等节点的能力。
2. 缺失的一环：Peer-Aggregated Discovery 1.28 的博客文章指出了一个显著缺口：虽然我们可以代理资源请求，但发现请求仍然只显示本地 API 服务器所知道的内容。在 1.36 中，我们新增了 Peer-Aggregated Discovery 支持！现在，当客户端执行发现操作（例如列出可用 API）时，API 服务器会将其本地视图与所有活跃对等节点的发现数据合并。这为客户端提供了整个集群中所有可用 API 的完整、统一视图，无论它们连接到哪台 API 服务器。

sequenceDiagram
    participant Client
    participant API_Server_A as API Server A
    participant API_Server_B as API Server B
    
    Client->>API_Server_A: 1. Request Discovery Document
    API_Server_A->>API_Server_A: 2. Gets Local APIs
    API_Server_A->>API_Server_B: 3. Gets Peer APIs (Cached or Direct)
    API_Server_A->>API_Server_A: 4. Merges and sorts lists deterministically
    API_Server_A-->>Client: 5. Returns Unified Discovery Document

虽然对等聚合发现将成为默认行为（请注意，如果设置了 --peer-ca-file 标志，则会启用对等聚合发现；否则服务器将回退为仅显示其本地 API），但在某些情况下，你可能需要仅检查当前所连接的特定 API 服务器所提供的资源。你可以通过在请求的 Accept 头中包含 profile=nopeer 参数来请求这种非聚合视图（例如：Accept: application/json;g=apidiscovery.k8s.io;v=v2;as=APIGroupDiscoveryList;profile=nopeer）。

必需配置

虽然功能门控将默认启用，但它需要设置某些标志，以允许对等 API 服务器之间进行安全通信。为确保功能正常运行，请确保你的 API 服务器配置了以下标志：

• --feature-gates=UnknownVersionInteroperabilityProxy=true：这将在 1.36 中成为默认设置，但最好进行确认
• --peer-ca-file=<path-to-ca>：[关键] 这是必需标志。你必须提供 CA 包，源 API 服务器将使用它来认证目标对等 API 服务器的服务证书。没有它，代理将因 TLS 验证错误而失败。
• --peer-advertise-ip 和 --peer-advertise-port：这些标志用于设置对等节点访问此 API 服务器时应使用的网络地址。如果未设置，将使用 --advertise-address 或 --bind-address 的值。如果你的网络拓扑较复杂，API 服务器需要通过特定内部接口通信，强烈建议显式设置这些标志。

使用 kubeadm 进行配置

如果你使用 kubeadm 管理集群，可以在 ClusterConfiguration 文件中配置这些标志：

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
apiServer:
  extraArgs:
    peer-ca-file: "/etc/kubernetes/pki/ca.crt"
    # peer-advertise-ip and port if needed

行动号召

如果你正在运行多主集群并定期升级它们，Mixed Version Proxy 是一项重大的安全性改进。随着它在 1.36 中成为默认功能，我们鼓励你：

1. 检查你的 API 服务器标志，确保 --peer-ca-file 设置正确。
2. 在为 1.36 升级做准备时，在预发布环境中测试该功能。
3. 向 SIG API Machinery（通过 Slack、邮件列表，或参加 SIG API Machinery 会议）反馈你的使用体验。

• ← 上一篇
• 下一篇 →