Kubernetes 容器平台能力洞察

Gateway API

Ingress是k8s对集群中服务的外部访问进行管理的API对象，允许对外部的HTTP访问提供负载均衡、SSL终结等能力。目前Ingress API仍稳定支持，但已被冻结，K8s 社区推荐使用Gateway API而非Ingress。

Kubernetes社区引入Gateway API以弥补Ingress角色模型耦合、表达能力不足、扩展标准缺失的短板：

• 基础设施维护人员、平台管理员、开发者角色耦合，职责边界不清
• 资源模型单一，规则表达能力有限，仅支持HTTP协议
• 缺乏统一的扩展能力规范，能力声明依赖Annotation

资源模型

在Gateway API的设计中，集群网络的相关人员被划分为以下三种：

• 基础设施提供者：管理基础设施，为多个集群/租户提供技术设施服务。
• 集群操作者：管理单个集群，保障集群所有用户的服务。
• 应用开发者：管理个人在集群中运行的应用程序。

相对的，Gateway API提供的资源类型可分为实现层、实例层、规则层三层，从而支持在集群范围内的职责分离。

• GatewayClass：定义一组具有配置相同的网关，由实现该类的控制器管理，一般由基础设施提供者管理。
• Gateway：定义流量处理基础设施（例如云负载均衡器）的一个实例，一般由集群操作者管理。
• xxxRoute：定义将流量从Gateway监听器映射到后端网络端点的规则，一般由应用开发者管理。目前提供标准或实验性的API有 HTTPRoute、GRPCRoute、TLSRoute、TCPRoute、UDPRoute

Gateway API通过分层资源建模与职责解耦，构建了面向多协议、多角色、多租户场景的网络管理架构，弥补了 Ingress 在模型表达能力和企业级治理方面的结构性不足。

一个GatewayClass资源可用于描述一个Gateway控制器实例，管理多个Gateway对象；一个Gateway对象只能与一个GatewayClass相关联；一个Gateway可以被多个 Route 对象关联，一个 Route 对象也可以关联多个Gateway对象。

工作方式

基础设施提供者会为集群提供Gateway控制器（可以为集群内部或外部服务），并在集群中创建GatewayClass资源，其中包含该控制器的名称。

集群操作者创建Gateway资源，其中指定所关联的 GatewayClass以及监听规则。Gateway 控制器将据此判断是否有自己管理，并创建Gateway实例（数据平面组件等），作为外部请求的入口。

应用开发者创建Route资源，其中包含所关联的Gateway实例以及请求的路由规则。被关联的Gateway实例将加载该规则，在接收到符合条件的请求时，将根据该规则进行路由的处理，转发到指定的服务端点。

南北向（Ingress替代）

Gateway作为外部流量入口，监听特定协议、地址、端口等配置上的外部请求，根据所加载的Route规则进行匹配，再流量以特定方式路由到指定的服务端点。

  flowchart LR
    A(Client) -->|http request| B
    B["Gateway<br/>[HTTPRoute]"] -->|route| C
    C[Endpoint<br />e.g. Service] --> D(Pod)
    C --> E(Pod)

东西向（ServiceMesh集成）

K8s同时还提出了GAMMA倡议 （Gateway API for Mesh Management and Administration），是Gateway API在服务网格场景下的扩展倡议，旨在引导各类服务网格组件复用Gateway API核心资源，为服务网格提供统一、可移植的控制平面接口，替代各类服务网格中的CRD体系。

GAMMA已纳入Gateway API标准（标准通道），目前业界正在响应，若干网格项目已经实现或部分实现了GAMMA支持。

Gateway API inference extension

GAIE是在Gateway API上的扩展，针对K8s AI推理场景的特有流量管理能力，提出了进一步的扩展支持需求，如：

• 多模型路由与轮转
• 基于指标的负载调度
• 长连接与流式响应优化

不改造Gateway API，通过提供扩展CRD增强能力。GAIE针对AI推理服务的运维进一步划分了两类角色：

• 推理平台所有者，管理整个平台的推理服务，对一些列推理后端的服务可访问性负责
• 推理负载所有者，负责特定的推理后端管理

并分别提供了职责解耦的对应CRD资源

• InferencePool定义一系列提供AI推理服务的Pod集合。与Service一样作为Gateway Route资源的路由断电
• InferenceObject定义单个AI推理服务实例，包含模型、运行策略等信息，InferencePool据此进行管理与调度

一个InferencePool可以与一系列InferenceObject对象关联。一个InferenceObject只能关联一个InferencePool

项目分析

在发行版中引入 Gateway，通常需要满足以下要求：

• 开源项目，无云服务依赖
• 对 Gateway API 支持较好，社区演进积极
• 支持 Inference Extension，适配未来 AI 推理场景

根据 Gateway API 官方仓库中的 Conformance 报告，已有较多开源项目对 Gateway API 的支持已相对成熟且在积极演进；而 GAIE 成熟度相对较低，提供对推理扩展支持的社区较少。

• Envoy Gateway: Envoy本身是云原生数据平面项目，Envoy社区实现Envoy Gateway控制器，可基于底层Envoy实例实现流量控制。同时，Envoy社区提供Envoy AI Gateway插件实现推理扩展。
• Istio: 主流服务网格项目，在控制平面内部实现Gateway API管理功能，底层复用Envoy，并已经实现了GAMMA倡议。同样在内部实现推理扩展。
• kgateway: 独立社区项目，社区规模较小，轻量级专用控制器，与服务平面解耦，可以自行对接。项目设计上原生支持推理扩展。
• Nginx Gateway Fabric: Nginx社区提供的Gateway API控制器，使用Nginx的反向代理、负载均衡能力。官方已内置推理扩展支持，可以通过配置项开启。

此外，Gateway API要求K8s版本1.26+；各个控制器由于具体实现不同，K8s的版本要求也不相同：

存储

部分发行版的本地存储仍依赖 hostPath，强绑定节点、无副本机制、无调度感知。对于镜像/应用包、二进制等资源不适合放在 k8s 资源中，且不能依赖节点本地目录的内容，需要考虑集群提供存储方案。

业界洞察

OpenShift存储主要在：

• Image Registry Operator提供了一个内置镜像仓。若检测到是特定云服务商环境，Image Registry Operator的管理面会自动配置当前面云服务的存储对象。对于本地裸金属环境，则会默认禁用镜像仓，需要用户手动配置自定义的存储源并创建PVC，从而将其关联到镜像仓管理并用于镜像的存储。
• OpenShift企业版提供OpenShift Database，是OpenShift生态中的存储服务解决方案，并非平台能力自用的基础设施。基于Rook+Ceph补充了一系列商业增强，支持集群内、外部存储源的对接。

可以看到，即使是强依赖存储的能力，OpenShift将存储的底层配置交由用户决策使用何种类型，用户保留了使用特定存储组件还是hostPath的选择权。

Rancher默认轻量，不带内置镜像或应用仓库，应用市场完全依赖外部仓库的添加。同时，官方有开源Longhorn分布式存储项目，对标ceph，但是针对云原生设计其架构。Rancher公司在商业版Rancher Prime中一并提供商业支持。

方案

若平台组件本身对高可用存储依赖较低，内置本地仓库使用也不多，存储增强的优先级可以相对靠后，以免额外资源占用。

与主流发行版保持一致，将业务存储的选择权交给用户，但可为业界常见实践提供支持：

• 对于应用包、镜像、二进制等大型文件，可以使用对象存储（harbor支持S3 API的对象存储管理）
  • MinIO+Longhorn：使用Longhorn作为底层存储模块，提供PVC；MinIO作为对象存储服务提供S3接口，允许Harbor进行Helm包或镜像管理，数据库业务可直接使用Longhorn PVC
  • Ceph(Rook)：使用Rook安装完整Ceph集群，统一提供对象存储（RADOSGW）允许Harbor调用，数据库业务可使用块存储（RBD）PVC
• 对于轻量化数据库存储，可以直接保持hostPath的使用方式，或直接使用分布式存储的PVC

local harbor

部分发行版会提供本地 Harbor，用于存储 Chart 包、镜像等制品。常见目标场景包括：

• 自制应用包的实验性开发
• 离线环境下应用的部署

实践中常见的现状：

• 在线环境更倾向使用官方应用源，离线环境则更多使用自建仓库，本地 Harbor 使用率不一定高。
• local-harbor 默认组件较多，运维复杂度与故障面更大。
• Harbor 默认自带 registry 用于镜像存储，但未必真正启用；同时镜像管理本身常有现实诉求。

因此，更合理的做法是：提供 local Harbor 能力，但不一定默认安装；允许用户以 Helm 应用形式按需启用（与官方安装方式保持一致）；同时完善平台对 Harbor 镜像能力的支持，便于离线环境使用 registry 管理镜像，并在推荐实践中将本地 Chart 仓库与本地 Registry 组合使用。

证书管理 Cert-manager

部分发行版当前仍采用人工/脚本创建证书文件，通过 Secret 或 ConfigMap 存储，再以 volume 挂载到 Pod 内供应用加载。

cert-manager介绍

cert-manager是一个开源的云原生证书管理控制器，CNCF毕业项目。通过将证书作为K8s资源管理，实现了证书全生命周期的自动化管理。相比证书的人工创建、更新，cert-manage提供以下能力：

1. 证书生命周期自动化：自动签发、自动续期等

cert-manager主要面向用户提供Issuer/ClusterIssuer和Certificate两类API，允许证书签发管理者声明证书签发来源、应用开发者声明具体的证书实例。

• 证书管理员在集群内部或外部证书准备签发服务后，需要在集群中声明Issuer资源
• 应用开发者根据需要声明Certificate资源，cert-manager作为控制器创建相关的私钥与签发请求，并将所有证书相关信息保存在Secret中。cert-manager还将会根据Certificate资源中的声明，自动完成证书的更新与重新签发。

2. 多源证书颁发支持，

cert-manager支持多种证书签发源，包括ACME协议的公有CA（如Let’s Encrypt）、私有CA（如HashiCorp Vault、CyberArk）以及自签名CA。

3. Ingress/Gateway集成

在Ingress、Gateway中标准实现中，都能通过API声明的方式配置TLS终止证书。Cert-manager会监听Ingress、Gateway资源，根据其中的cert-manager注解信息，自动创建Certificate以请求所需证书的创建，实现无需人工干预的自动证书配置。

如何引入

• 部署cert-manager：CRD & 控制器
• 配置Issuer资源，指向集群的CA
• 配置Certificate，与现有证书Secret名称对齐；但是需注意Secret内的字段名与cert-manager规范命名是否一致。

使用场景

cert-manager的主要目的是以自动化的方式，避免频繁的手工操作轮换证书。一般情况下，用于公网访问的证书有相对更高的更换频率要求（如90天一次），而内部服务的证书有效期可以较长（如2年）。

若发行版证书以内部服务为主、公网场景较少，证书轮换压力通常不高。此时不一定要把 cert-manager 作为默认能力，但可以保证适配，或将其作为可选能力提供。

OIDC

OIDC 是一种基于OAuth 2.0规范的身份认证协议，通过标准化的认证流程与ID Token机制向系统证明用户身份。从而允许

• 允许多系统使用统一的身份来源
• 使用第三方的身份接入能力作为身份认证
• 支持单点登录
• 多客户端支持

Kubernetes官方原生支持OIDC，可以在apiserver中通过启动参数启用并指定相关配置。在K8s提供的多种认证方式中，OIDC是最适合企业统一管理的方案。

方案分析

云原生社区主要使用以下两个组件：

• Dex：轻量级OIDC broker，为多种身份源提供统一入口，不提供复杂用户与权限管理，部署简单；适用于轻量级、个人/社区开发者。
• KeyCloak：Keycloak是一个完整的企业级身份与访问管理平台，支持OIDC、OAuth2、SAML，以及RBAC、多因素认证和单点登录。适合需要统一企业认证、跨集群或跨平台单点登录的企业用户场景。

上述项目均为CNCF开源项目，但Rancher与OpenShift仅将KeyCloak作为推荐方案提供支持（可能出于企业客户考虑，更倾向于选择全套完整服务），而Dex在其他k8s发行版中也有使用。

一些发行版使用自研 oauth-server 提供本地 OAuth2.0 认证与 JWT Token 签发，用户体系则依赖 k8s 本地资源。这种方式较轻量，但在跨系统统一身份认证、第三方身份源接入方面能力有限。

考虑到离线场景较多，本地认证通常仍需保留；是否接入第三方身份源，可按社区诉求再演进。

发行版内可尽量避免引入重型 IAM，使用开源项目作为 OIDC broker，分别接入本地认证源和外部 OIDC 认证源：本地默认启用，外部身份源由用户按需配置；同时尽量沿用既有 token 签发与用户管理机制，降低其他组件的配置改动成本。

compliance operator

OpenShit提供的operator，允许在集群上定时执行安全合规标准扫描任务，检测集群当前状态与合规基线之间的差距，以及可行的修补措施。提供一系列k8s资源，允许集群管理者对扫描策略、扫描任务等进行管理。

OpenShift compliance operator组件基于OpenSCAP合规检查工具，本质上提供了一个规则执行框架，同时预制了一些规则集，提供CIS、PCI DSS、Essential 8等行业或政府机构指定的安全规范支持。同时，也允许用户根据需求对创建新的规则集、或基于现有规则集进行扩充与裁剪。

配置scansetting、scansettingbanding等扫描配置资源后，operator即可定时创建扫描任务。每一次的扫描都会创建pod执行进程，并将结果保存在绑定的PV中供用户查看。同时，还会生成Remediation资源，其中包含可行的自动修复方式。自动修复不会自动触发，用户检视确认其影响后方可手动触发。

该Operator通过OpenShift Operator Hub安装，说明使用场景为集群中持久化部署，实现安全合规的扫描。因此推测海外用户的诉求是把定期执行的扫描作为合规保障，避免集群运维过程中新增安全风险。

海外商用场景往往需要符合属地或行业合规要求，OpenShift 为此提供了 compliance operator，简化合规基线运维。对容器平台而言，这类能力更多是安全治理增强，而非基础能力本身；更稳妥的做法是先明确需遵从的规则集，再评估继承既有方案或采用开源组件。

安全上下文

Pod Security Admission是Kubernetes官方提供的Pod安全准入控制机制，提供了一个K8s内置准入控制器，并定义了privileged、baseline、restricted三种级别。在创建添加了PSA标签的pod时，准入控制器会检查起各类安全配置（如privileged、用户组控制、volume权限等），并根据用户设置进行拒绝或警告。该机制只能检查指定的pod spec字段，不支持自定义策略，不支持其他资源类型。

Rancher在K8s PSA基础上进行PSA策略模板抽象，以CRD形式将其模板化管理，实际上的原理不变，只是提供更便捷地使用体验。

OpenShift 的 SCC（Security Context Constraints）同样通过K8s准入控制器机制提供了自研的准入控制机制，作为OpenShift原生APi类型提供。准入控制的目标也是pod。与PSA相比，SCC资源API允许用户自定义准入策略，且能够直接绑定平台RBAC。

https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/authentication_and_authorization/managing-pod-security-policies

Kyverno是CNCF毕业项目，云原生准入控制器，作为集群中持久化运行的服务，通过apiserver webhook方式介入Admission Controller。与上面的内置准入相比，能够提供完全可编程的策略控制：支持更灵活、更复杂的准入逻辑，支持校验后Mutate，适用于任何资源类型。 https://kyverno.io/

对发行版而言，建议先明确安全准入规则，再按规则复杂度选型或分阶段实现：简单规则可先基于 PSA，复杂准入再考虑 Kyverno 等策略引擎。

openShift安装部署

是否有针对不同场景的不同安装方式?

OpenShift提供的多种安装方式，是根据基础设施场景划分，而不是用户使用场景。

• Installer-Provisioned Infrastructure（IPI）：在具备完善API的基础设施环境中（如云服务），安装程序可以实现较高程度的自动化部署（虚机资源创建、网络存储配置等）
• User-Provisioned Infrastructure（UPI）：在企业私有云、裸金属环境中，安装程序仅负责生成节点启动配置并完成集群引导；用户几乎全手动安装，需要自行准备计算节点、网络等基础设施
• Assisted Installer/Agent-based Installer：对裸金属、边缘节点等环境中，通过Agent生成启动镜像，使节点在启动后自动加入安装流程，从而简化裸金属环境下的部署过程。
• Single Node OpenShift：用于资源受限生产环境的单节点Openshift集群，分别用于与开发测试环境，由上述工具提供单节点安装的支持
• CodeReady Containers：通过虚机提供的开箱即用本地OpenShift沙盒环境，适用于开发测试。官方提供专用工具可以简单拉起。

Rancher也提供单节点Docker安装方式，提供轻量开发测试环境

openshift安装思路

OpenShift安装过程中，涉及三种节点，bootstrap - master - worker：

• bootstrap仅用于拉起master控制平面，以容器化方式提供临时管理面（etcd、apiserver等）。任务完成后，控制权移交给master，而其自身会被被删除。这样会导致一个节点的闲置。对于云服务环境安装，安装工具可以通过调用云服务API管理销毁该节点；而对于用户自有基础设施上的安装，则需要人工操作。
• Master作为控制平面，承载etcd、apisevrer的那个k8s核心组件与OpenShift核心operator。Worker只运行kubelet等，用于运行业务。Master和Worker共同组成一个OpenShift集群。
• Master基于OpenShift Machine API实现Worker节点的生命周期管理。（Machine API是Cluster API的早起设计来源，但是两者已分叉发展）

一些发行版采用「引导节点 - 管理集群 - 业务集群」的三层结构，角色定位可能略有重叠：

• 引导节点与管理集群都提供集群生命周期管理，因此可以跳过管理集群直接在引导节点创建业务集群。
• 管理集群和业务集群都包含完整容器平台能力，可以直接在管理集群运行业务

与 OpenShift 不同，若引导节点运行在容器环境中的轻量 k3s 集群并与宿主机隔离，则支持引导节点与管理/业务集群共部署。这在一定程度上允许不修改基础设施的情况下直接删除引导节点。

多集群

目前多集群能力主要聚焦在多集群统一管理与集群生命周期管理。

• OpenShift商用版提供Advanced Cluster Management，允许在OpenShift集群上部署管理集群组件，以管理多个OpenShift或标准K8s集群。Agent进行通信，实现集群生命周期管理、应用生命周期管理、策略治理与可观测能力。
• 通过在标准K8s集群上安装Rancher，可以将其转换为一个管理集群。通过与纳管集群中的Agent通信，同样实现集群的生命周期管理，并访问集群上的资源

两者均使用了类似的流程架构：

• 管理集群的控制器根据用户创建的CR资源，连接目标节点进行其他生命周期管理操作
• 新建集群默认自带Agent，也允许在已有集群中安装Agent，注册到管理集群的多集群组件，从而实现集群纳管

OpenShift MachineAPI与ClusterAPI思想接近，但不一致；Rancher默认使用自研的Provision体系，但新版本提供了Turtle插件作为CAPI实现。

基于 ClusterAPI 的发行版，在集群生命周期管理上通常相对完善；若再叠加 Karmada 一类多集群方案，可在管理集群提供统一管理面。有的实现通过 Kubeconfig 做跨集群资源管理，这与 Agent 架构不同。

会话凭证管理示例

认证过程中可能存在 Oauth-code、session-secret 两类凭证，以 Secret 形式存储在集群 etcd 中。Oauth-code 存储用户 token 信息，session-secret 用于存储 token 与 session 的对应关系。

• 创建：客户端、控制台服务、oauth-server 完成认证后，控制台服务获取签发的 token，生成对应 sessionID 并创建 Secret
• 调用：客户端请求到达控制台服务时，后者遍历 Secret 匹配 session 字段，获取对应 token 并添加到请求头；后端服务收到请求时，再请求 oauth-webhook 确认 token 是否有效
• 删除：遍历并删除对应 Secret；同时可用 CronJob 定期清理过期凭证

在短时间发生大量登入时，会产生大量凭证 Secret，导致控制面组件对 Secret 的遍历占用大量时间，影响接口时延。

可改用 Redis，以加密后的 sessionID 为 key，存储对应的 token、expiry 等信息。Redis 查找时间复杂度为 O(1)，更适合高并发下的 session/token 查找。

前端容器镜像体积

部分平台前端组件为静态页面，使用 Nginx 容器托管。若为与某 Linux 发行版社区保持一致而选用其官方 Nginx 镜像，可能出现：

• 社区维护镜像缺少裁剪，镜像本体可达数百 MB（前端静态资源通常仅约 10MB），冗余磁盘占用高
• 未跟随 Nginx 更新节奏，版本选择受限

Nginx 社区本身维护多种基础镜像的 Nginx 镜像，镜像大小通常在 70MB 到 250MB 之间，并严格跟随社区版本节奏发布。建议选型 Nginx 新版本后，将容器替换为 Nginx 社区 alpine 或 bookworm 镜像。