Kubernetes v1.36：混合版本代理升级到 Beta

早在 Kubernetes 1.28 中， 我们在之前的博客文章中引入了 Mixed Version Proxy (MVP) 作为 Alpha 特性（在特性门控 UnknownVersionInteroperabilityProxy 下）。 目标简单但关键：通过确保对旧版 API 服务器尚不了解的资源请求被正确路由到较新的对等 API 服务器， 而不是返回不正确的 404 Not Found，从而使集群升级更安全。

我们很高兴地宣布，Mixed Version Proxy 将在 Kubernetes 1.36 中升级到 Beta 版本， 并将默认启用！该特性自首次发布以来有了显著发展，解决了关键差距并实现了架构现代化。

以下介绍该特性的发展历程以及在集群中使用它需要了解的内容。

我们正在解决什么问题？

在正在升级的高可用控制平面中，你通常会有运行不同版本的 API 服务器。 这些服务器可能提供不同的 API 集（Groups、Versions、Resources）。 没有 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 到聚合发现 在 Alpha 版本中，API 服务器依赖 StorageVersion API 来确定哪些对等服务器提供哪些资源。 虽然功能正常，但这种方法有一个显著的局限性：StorageVersion API 尚不支持 CRD 和聚合 API。 对于 Beta 版本，我们用 Aggregated Discovery 取代了对 StorageVersion API 调用的依赖。 API 服务器现在使用聚合发现数据来动态了解其对等服务器的能力。

2. 缺失的部分：对等聚合发现 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>：[CRITICAL] 这是必需的标志。 你必须提供源 API 服务器将用于验证目标对等 API 服务器服务证书的 CA 包。没有这个，代理将因 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"
    # `eer-advertise-ip 和端口（如果需要）

行动号召

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

1. 检查你的 API 服务器标志，确保 --peer-ca-file 已正确设置。
2. 在准备 1.36 升级时，在你的暂存环境中测试此功能。
3. 向 SIG API Machinery 提供反馈（Slack、 邮件列表， 或通过参加 SIG API Machinery 会议） 分享你的体验。

• ←上一页
• 下一页→