插件完整配置：Metrics Server 与 Argo CD

验证：未记录

适用版本: 未记录
验证范围: 尚未登记验证记录。

补齐安装后“自行加生产配置”的缺口。选择一个可复核组合：Metrics Server chart 3.13.1 / app 0.8.1，Argo CD chart 10.9.2 / app v3.5.3。这是本文锁定的渲染基线，不代表所有集群均兼容；先核对其官方 Kubernetes 支持矩阵，托管集群已有组件时不重复安装。

1. Metrics Server：资源、分散与中断预算#

至少两台可调度节点、有效 kubelet 服务证书、可达的聚合 API（应用程序接口）链路。下载 metrics-values.yaml：

helm template metrics-server metrics-server --repo https://kubernetes-sigs.github.io/metrics-server/ --version 3.13.1 -n kube-system -f metrics-values.yaml > metrics-rendered.yaml
kubectl apply --dry-run=server -f metrics-rendered.yaml
helm upgrade --install metrics-server metrics-server --repo https://kubernetes-sigs.github.io/metrics-server/ --version 3.13.1 -n kube-system -f metrics-values.yaml --atomic --wait --timeout 10m
kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes
kubectl -n kube-system get pods -l app.kubernetes.io/name=metrics-server -o wide

验收两个副本位于不同节点；一个 Pod 重建期间持续执行 metrics API 与订单业务测试，记录指标可用性及 HPA（水平扩缩容）行为。证书失败必须修复 CA（证书颁发机构）与 SAN（证书备用名称），禁止加入 insecure-tls。资源值是起始预算，大集群按实测扩大；PDB（Pod 中断预算）只约束自愿驱逐。

2. Argo CD：先准备身份与 TLS#

沿用 Argo CD 的 commerce AppProject。至少三节点，准备受信任内部域名证书、OIDC（OpenID Connect，身份认证协议）客户端、平台管理员组和 commerce-deployers 组。客户端回调为 https://argocd.internal.example.com/auth/callback，签发 groups claim；替换示例域名为企业真实域名。

kubectl create namespace argocd --dry-run=client -o yaml | kubectl apply -f -
# 路径指向秘密系统投递的本地文件，权限 600，不能入 Git。
kubectl -n argocd create secret generic argocd-oidc --from-file=client-secret=/secure/argocd-client-secret
kubectl -n argocd label secret argocd-oidc app.kubernetes.io/part-of=argocd
kubectl -n argocd create secret tls argocd-server-tls --cert=/secure/argocd-chain.pem --key=/secure/argocd-key.pem

私有 Git 只读凭据：创建权限 600 的文件 repo.env，包含 type=git、url=https://git.example.com/commerce/orders-deploy.git、username、password（受限短期 token）；使用 kubectl create secret generic orders-repo --from-env-file=/secure/repo.env -n argocd，加标签 argocd.argoproj.io/secret-type=repository。使用私有 CA 时将证书加入 argocd-tls-certs-cm，不能关闭仓库 TLS 校验。

3. 渲染、网络与安装#

下载 argocd-values.yaml，替换域名、issuer 和组；默认禁用本地 admin，安装前必须确认 OIDC 可用，平台保留受审计的 Kubernetes 应急管理员用于恢复配置。

helm template argocd argo-cd --repo https://argoproj.github.io/argo-helm --version 10.9.2 -n argocd -f argocd-values.yaml > argocd-rendered.yaml
kubectl apply --dry-run=server -f argocd-rendered.yaml
helm upgrade --install argocd argo-cd --repo https://argoproj.github.io/argo-helm --version 10.9.2 -n argocd -f argocd-values.yaml --atomic --wait --timeout 15m

Chart 提供控制器、服务端、repo-server、ApplicationSet 多副本及 Redis/Sentinel HA（高可用）、资源、分散、PDB 和组件 ingress NetworkPolicy。另下载 argocd-egress.yaml，填写实际 API Server、Git、OIDC 的最窄 CIDR 后 apply；NodeLocal DNS（节点本地域名解析）需加入其地址。Git/IdP 是公网动态地址时，应走固定企业出口代理，不能在策略里填一次 DNS 解析结果后认为长期有效。

内部入口只转发 Argo server TLS 端口；平台追加仅允许该私网 Gateway namespace 的 ingress 规则。Chart 自带规则和自定义策略按 Kubernetes 规则取并集，逐条核对，不能以为额外 deny 会覆盖已有 allow。完整平台入口接入按 Gateway API，不对公网暴露 Redis 或管理接口。

首次安装包含 CRD（自定义资源定义），没有安装 CRD 的集群应先受控安装 Chart crds/，再 dry-run 其他资源；升级前单独审查 CRD 兼容性与备份。

4. 必须完成的验收#

操作	预期
OIDC 平台管理员登录	能管理指定应用；审计记录可定位身份
普通员工／非 commerce 组	无部署权限；默认 role:none 不附带全局只读授权
commerce 提交 ClusterRole 或其他 namespace	AppProject/RBAC（基于角色访问控制）拒绝
不可信 namespace 访问 Redis／repo-server	网络策略拒绝
滚动重建一个 server/repo-server/Redis Pod	应用业务持续服务；Git 协调与登录恢复，记录中断窗口
Git 或 OIDC 不可达	同步/登录明确失败，现有业务不被删除；恢复后重新验证

对于 External Secrets、日志等插件，继续使用各专项文档的配置，按相同维度验收。DaemonSet（每节点守护进程）不机械套用三副本；云身份、webhook、持久化等仍需组件专属检查，不能以这一页替代。

5. 升级与恢复#

保存 helm get values -a、Chart 包、镜像清单与 AppProject/Secret 的加密备份。先在隔离环境升级并重做负向测试，再推广；回退前核对应用/CRD/Redis 格式兼容性。恢复 Git、OIDC、仓库与集群凭据后先查看 diff，禁止一恢复就自动 prune（删除多余资源）。清理仅删除本次安装的 release，先检查 Application finalizer，防止级联删除业务。

Metrics Server 要求、Argo Helm 配置。

6. 其他插件的渲染与验收#

KEDA、Cluster Autoscaler、Cilium、Linkerd 各自提供完整 values；环境身份与发行版仍按专项文章选择。本仓库渲染基线分别为 2.20.0、9.54.0、1.18.6、Linkerd edge 2026.9.3（仅字段验证，不构成生产发行版推荐）。CA 的镜像 minor 必须匹配实际集群；Linkerd 此版本要求 Kubernetes ≥1.31。

以 KEDA 为例，先完成专篇的身份输入，下载 check_render.py 与对应 values。检查脚本只解析 YAML，不连接集群：

python3 -m venv .venv
.venv/bin/pip install 'PyYAML==6.0.3'
helm template keda keda --repo https://kedacore.github.io/charts --version 2.20.0 -n keda -f keda-values.yaml > rendered.yaml
.venv/bin/python check_render.py rendered.yaml
kubectl apply --dry-run=server -f rendered.yaml

其他插件替换 release、Chart、版本、namespace 和 values；Linkerd 还必须合并发行方 HA 文件及真实 trust anchor。先安装所需 CRD，再对依赖它们的资源 dry-run。脚本核验资源、双副本、匹配本 Pod 标签的强制节点反亲和性及 PDB；它不证明网络/身份/调度已经成功。

安装后保存 kubectl -n <namespace> get deploy,pdb,pods -o wide（替换 namespace），核对副本跨节点。预生产每次只重建一个控制器 Pod，同时持续运行订单验收：KEDA 检查 external metrics 与扩缩容，CA 检查 leader 接替及新节点 Ready，Cilium 检查已有/新建连接和 Hubble 流，Linkerd 检查新 Pod 身份签发及授权拒绝。Pod 直接删除不受 PDB 保护；另在有替代容量时用节点 drain 验证自愿驱逐预算。任何业务错误超出既定 SLO（服务级别目标）即停止演练并恢复上一份配置；CNI 与 PKI 仍遵循专项恢复流程。