Kubernetes Architect 智能体实战指南：基于 agents24 插件市场构建云原生平台与 GitOps 交付体系

本篇技术指南以开源仓库 agents24（Multi-harness agentic plugin marketplace）中的 Kubernetes 运维插件为核心，系统解读 kubernetes-architect 智能体的能力边界、OpenGitOps 交付方法论及其配套技能栈（GitOps 工作流、Helm 图表脚手架、K8s 清单生成、安全策略）。读者读完后，可以掌握如何用该智能体完成从集群架构设计、GitOps 落地、渐进式发布到安全加固与成本优化的端到端 Kubernetes 平台工程方案。

一、智能体定位：从容器编排到平台工程的架构师

kubernetes-architect.md 的 frontmatter 明确定义了该智能体的身份：Expert Kubernetes architect specializing in cloud-native infrastructure, advanced GitOps workflows (ArgoCD/Flux), and enterprise container orchestration，并指定使用 opus 模型承载。它被设计为在 K8s 架构设计、GitOps 落地、云原生平台规划 三类场景下被主动（PROACTIVELY）调用。

其 Purpose 声明聚焦于：跨主流云厂商（EKS、AKS、GKE、OKE）与本地部署的 Kubernetes 精通，目标是构建可扩展、安全、成本可控的平台工程解决方案，进而提升开发者生产力。在仓库结构中，该智能体与四个配套 Skill 同属 plugins/kubernetes-operations 插件包，形成"智能体 + 技能"的完整能力闭环：

• gitops-workflow：ArgoCD / Flux 的声明式持续交付落地
• helm-chart-scaffolding：Helm 图表的设计、组织与管理
• k8s-manifest-generator：生产级 K8s 清单生成
• k8s-security-policies：NetworkPolicy、Pod Security Standards、RBAC 纵深防御

二、能力全景：九大领域的平台工程知识体系

智能体文档用九个 Capabilities 小节勾勒出一名资深 K8s 架构师的知识版图，下面逐域展开并结合配套技能给出落地抓手。

2.1 集群平台专业能力

能力方向	覆盖范围
托管 Kubernetes	EKS（AWS）、AKS（Azure）、GKE（Google Cloud）、OKE（OCI）的高级配置与优化
企业级发行版	Red Hat OpenShift、Rancher、VMware Tanzu 及平台特性
自管集群	kubeadm、kops、kubespray、裸金属安装、离线（air-gapped）部署
集群生命周期	升级、节点管理、etcd 运维、备份/恢复策略
多集群管理	Cluster API、集群舰队管理、联邦、跨集群网络

2.2 GitOps 与持续交付

• 工具链：ArgoCD、Flux v2、Jenkins X、Tekton 的高级配置与最佳实践
• OpenGitOps 原则（见本文第三节）
• 渐进式交付：Argo Rollouts、Flagger、金丝雀发布、蓝绿策略、A/B 测试
• 仓库模式：App-of-apps、mono-repo 与 multi-repo 取舍、环境晋升策略
• 密钥管理：External Secrets Operator、Sealed Secrets、HashiCorp Vault 集成

配套的 gitops-workflow 技能提供了完整实操路径，第四节将详细展开。

2.3 现代基础设施即代码（IaC）

• K8s 原生 IaC：Helm 3.x、Kustomize、Jsonnet、cdk8s、Pulumi Kubernetes Provider
• 集群供给：Terraform/OpenTofu 模块、Cluster API、基础设施自动化
• 配置管理：高级 Helm 模式、Kustomize overlays、环境差异化配置
• 策略即代码：OPA、Gatekeeper、Kyverno、Falco 规则、准入控制器
• GitOps 工作流：自动化测试、校验管道、漂移检测与修复

其中 Helm 3.x 与 Kustomize 是清单模板化的两条主线，前者由 helm-chart-scaffolding 技能专门支撑，后者内嵌于 gitops-workflow 的仓库结构示例中。

2.4 云原生安全

• Pod Security Standards：restricted / baseline / privileged 三档策略与迁移路径
• 网络安全：NetworkPolicy、服务网格安全、微隔离
• 运行时安全：Falco、Sysdig、Aqua Security 与威胁检测
• 镜像安全：容器扫描、准入控制器、漏洞管理
• 供应链安全：SLSA、Sigstore、镜像签名、SBOM 生成
• 合规：CIS Benchmark、NIST 框架、合规自动化

这一领域的实操细节集中沉淀在 k8s-security-policies 技能中，本文第五节系统还原。

2.5 服务网格架构

• Istio：高级流量管理、安全策略、可观测性、多集群网格
• Linkerd：轻量网格、自动 mTLS、流量拆分
• Cilium：eBPF 网络、NetworkPolicy、负载均衡
• Consul Connect：与 HashiCorp 生态集成的服务网格
• Gateway API：下一代 Ingress、流量路由、多协议支持

2.6 容器与镜像管理

• 容器运行时：containerd、CRI-O、Docker 运行时考量
• 镜像仓库策略：Harbor、ECR、ACR、GCR、OCIR，多区域复制
• 镜像优化：多阶段构建、distroless 镜像、安全扫描
• 构建策略：BuildKit、Cloud Native Buildpacks、Tekton Pipelines、Kaniko
• 制品管理：OCI artifacts、Helm Chart 仓库、策略分发

2.7 可观测性与监控

• 指标：Prometheus、VictoriaMetrics、Thanos 长期存储
• 日志：Fluentd、Fluent Bit、Loki、集中式日志策略
• 追踪：Jaeger、Zipkin、OpenTelemetry、分布式追踪模式
• 可视化：Grafana、自定义 Dashboard、告警策略
• APM 集成：DataDog、New Relic、Dynatrace 的 K8s 专项监控

2.8 多租户与平台工程

• 命名空间策略：多租户模式、资源隔离、网络分段
• RBAC 设计：高级授权、ServiceAccount、ClusterRole 与 Namespace Role
• 资源管理：ResourceQuota、LimitRange、PriorityClass、QoS 类
• 开发者平台：自助供给、开发者门户、抽象基础设施复杂度
• Operator 开发：CRD、控制器模式、Operator SDK

2.9 弹性伸缩与性能

• 集群自动扩缩：HPA、VPA、Cluster Autoscaler
• 自定义指标：KEDA 事件驱动扩缩、自定义 metrics API
• 性能调优：节点优化、资源分配、CPU/内存管理
• 负载均衡：Ingress Controller、服务网格 LB、外部负载均衡器
• 存储：PV、StorageClass、CSI 驱动、数据管理

2.10 成本优化与 FinOps

• 资源优化：合理 sizing、Spot 实例、预留容量
• 成本监控：KubeCost、OpenCost、云厂商原生成本分摊
• 装箱优化：节点利用率提升、工作负载密度
• 集群效率：requests/limits 优化、过度供给分析
• 多云成本：跨厂商成本分析、工作负载放置优化

2.11 灾备与业务连续性

• 备份策略：Velero、云原生备份方案、跨区域备份
• 多区域部署：active-active、active-passive、流量路由
• 混沌工程：Chaos Monkey、Litmus、故障注入测试
• 恢复流程：RTO/RPO 规划、自动故障切换、灾备演练

三、OpenGitOps 四大原则（CNCF）

智能体将 OpenGitOps 原则 作为 GitOps 实践的指导思想，这也是配套技能 gitops-workflow 的立论基础，原文以四条不可动摇的准则呈现：

1. Declarative（声明式）：整个系统用声明式的期望状态描述，而非命令式指令序列
2. Versioned and Immutable（版本化与不可变）：期望状态存储在 Git 中，具备完整版本历史，任何变更都可追溯、可回滚
3. Pulled Automatically（自动拉取）：软件代理自动从 Git 拉取期望状态，而非由 CI 向集群推送
4. Continuously Reconciled（持续调和）：代理持续观察实际状态与期望状态，出现漂移即自动收敛

这四条原则贯穿于 ArgoCD 的 selfHeal 语义、Flux 的 reconciliation 循环，以及"配置漂移检测与修复"的全部最佳实践中，是理解后面所有 YAML 配置背后设计动机的钥匙。

四、GitOps 落地实操：ArgoCD 与 Flux 双路线

gitops-workflow 技能将 OpenGitOps 原则翻译为可直接执行的双工具链方案。该技能在以下场景触发：搭建 GitOps、实现 Git 驱动的自动部署、落地渐进式交付、多集群部署管理、自动化同步策略配置、GitOps 中的密钥管理。

4.1 ArgoCD 安装与初始化

标准安装三步曲：

# 创建命名空间
kubectl create namespace argocd

# 安装 ArgoCD
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# 获取管理员密码
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

argocd-setup.md 进一步补充了三种部署形态：标准安装、高可用安装（manifests/ha/install.yaml）、以及 Helm 安装（helm install argocd argo/argo-cd -n argocd --create-namespace）。初始配置阶段，可通过 kubectl port-forward svc/argocd-server -n argocd 8080:443 端口转发访问 UI，或 argocd admin initial-password -n argocd 获取初始密码；生产环境则建议配置 Ingress + cert-manager 签发 TLS 证书。

CLI 侧初始化流程：

# 登录
argocd login argocd.example.com --username admin

# 添加仓库
argocd repo add https://github.com/org/repo --username user --password token

# 创建应用
argocd app create my-app \
  --repo https://github.com/org/repo \
  --path apps/my-app \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace production

4.2 GitOps 仓库结构

技能给出了一套成熟的目录组织范式——应用（apps）按环境分目录、基础设施（infrastructure）单独成区、argocd 自身声明（Application 与 Project）集中管理：

gitops-repo/
├── apps/
│   ├── production/
│   │   ├── app1/
│   │   │   ├── kustomization.yaml
│   │   │   └── deployment.yaml
│   │   └── app2/
│   └── staging/
├── infrastructure/
│   ├── ingress-nginx/
│   ├── cert-manager/
│   └── monitoring/
└── argocd/
    ├── applications/
    └── projects/

4.3 创建 ArgoCD Application 与 App of Apps

单应用声明（含自动化同步策略）：

# argocd/applications/my-app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/gitops-repo
    targetRevision: main
    path: apps/production/my-app
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true          # 删除 Git 中已移除的资源
      selfHeal: true       # 自动调和集群内手工改动
    syncOptions:
      - CreateNamespace=true

面对大量微服务，App of Apps 模式用一个"根 Application"统一管理所有子应用，实现集中编排：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: applications
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/gitops-repo
    targetRevision: main
    path: argocd/applications
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated: {}

4.4 Flux CD 安装与引导

Flux 采用 CLI 引导（bootstrap）方式，一次性完成 CLI 安装、Git 仓库初始化和集群端组件的部署：

# 安装 Flux CLI
curl -s https://fluxcd.io/install.sh | sudo bash

# Bootstrap Flux（自动生成 flux-system 组件清单并提交到 Git）
flux bootstrap github \
  --owner=org \
  --repository=gitops-repo \
  --branch=main \
  --path=clusters/production \
  --personal

Flux 模型由两层对象组成：GitRepository（声明源码来源与轮询间隔）与 Kustomization（声明应用到集群的方式）：

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: my-app
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/org/my-app
  ref:
    branch: main
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: my-app
  namespace: flux-system
spec:
  interval: 5m
  path: ./deploy
  prune: true
  sourceRef:
    kind: GitRepository
    name: my-app

4.5 同步策略深度配置

sync-policies.md 对同步策略做了专门化展开，覆盖自动同步、手动同步、同步窗口与重试策略。

ArgoCD 自动同步 + 重试退避：

syncPolicy:
  automated:
    prune: true      # 删除 Git 中已移除的资源
    selfHeal: true   # 调和集群内手工改动
    allowEmpty: false # 阻止空同步
  retry:
    limit: 5
    backoff:
      duration: 5s
      factor: 2
      maxDuration: 3m

同步窗口（Sync Windows）：用于在维护窗口内限制同步行为，例如允许每天 8:00 同步 1 小时，22:00 后全面禁止：

syncWindows:
  - kind: allow
    schedule: "0 8 * * *"
    duration: 1h
    applications:
      - my-app
  - kind: deny
    schedule: "0 22 * * *"
    duration: 8h
    applications:
      - "*"

Flux 侧同步参数：interval（调和周期）、prune（删除漂移资源）、wait（等待资源就绪）、timeout（超时）、retryInterval（失败重试间隔）、force（强制替换不可变字段）。

常用同步选项：PrunePropagationPolicy=foreground（等待被删资源完成删除）、CreateNamespace=true（自动创建命名空间）、Validate=false（跳过 kubectl 校验）、PruneLast=true（同步后清理）、RespectIgnoreDifferences=true（尊重差异忽略）、ApplyOutOfSyncOnly=true（仅应用不同步资源）。

4.6 渐进式交付

技能为金丝雀发布与蓝绿发布分别给出了 Argo Rollouts 的声明式配置：

金丝雀发布（分步放量）：

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    canary:
      steps:
        - setWeight: 20
        - pause: { duration: 1m }
        - setWeight: 50
        - pause: { duration: 2m }
        - setWeight: 100

蓝绿发布（双服务切换）：

strategy:
  blueGreen:
    activeService: my-app
    previewService: my-app-preview
    autoPromotionEnabled: false

4.7 GitOps 中的密钥管理

External Secrets Operator 将云端密钥（如 AWS Secrets Manager）同步为集群 Secret，实现"Git 中零明文密钥"：

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: db-credentials
  data:
    - secretKey: password
      remoteRef:
        key: prod/db/password

Sealed Secrets 则走另一条路线：在集群外加密、在 Git 中存密文：

# 加密 secret（生成 sealed-secret.yaml 提交到 Git）
kubeseal --format yaml < secret.yaml > sealed-secret.yaml

4.8 GitOps 排障与最佳实践

技能给出的同步排障命令：

# 查看应用状态与手动同步
argocd app get my-app
argocd app sync my-app --prune

# 查看差异与强制同步
argocd app diff my-app
argocd app sync my-app --force

10 条最佳实践清单：不同环境使用独立仓库或分支；为 Git 仓库实施 RBAC；为同步失败配置通知；为自定义资源配置健康检查；生产环境设置审批门禁；密钥不进入 Git（用 External Secrets）；用 App of Apps 组织应用；打版本标签便于回滚；用告警监控同步状态；先在 staging 测试变更。

五、安全纵深：Pod Security Standards 与 NetworkPolicy

k8s-security-policies 技能把智能体文档中"安全默认、纵深防御"的行为特质落实为可执行的策略清单。

5.1 Pod Security Standards 三档模型

通过命名空间标签启用强制（enforce）、审计（audit）与告警（warn）三种模式。Privileged（无限制） 用于系统级工作负载：

apiVersion: v1
kind: Namespace
metadata:
  name: privileged-ns
  labels:
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/audit: privileged
    pod-security.kubernetes.io/warn: privileged

Baseline（最小限制） 禁止已知的特权提升路径；Restricted（最严格） 全面遵循加固最佳实践（对应 restricted-ns 标签示例）。三档配置结构一致，仅将标签值替换为 baseline 或 restricted。

5.2 NetworkPolicy 核心模板

技能配套资产 network-policy-template.yaml 提供了 8 个可直接套用的模板，涵盖从"零信任起步"到"跨命名空间通信"的完整场景。

默认拒绝全部流量（一切网络策略的起点）：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

允许前端访问后端（同命名空间内 Pod 间通信，端口级收敛）：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

允许 DNS 出口（保证集群核心服务可用性的关键放行）：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              name: kube-system
      ports:
        - protocol: UDP
          port: 53

模板库其余场景包括：放行 Ingress Controller（80/443）、放行 Prometheus 抓取（9090）、放行外部 HTTPS 并拦截云元数据服务（except: 169.254.169.254/32）、数据库访问（5432）、跨命名空间通信（namespaceSelector + podSelector 组合）。

5.3 RBAC 最小权限设计

技能提供 Role / ClusterRole / RoleBinding 的完整示例。命名空间级只读 Role：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]

集群级 Secret 读取 ClusterRole：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get", "watch", "list"]

RoleBinding 将用户与 ServiceAccount 绑定到角色：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
  - kind: User
    name: jane
    apiGroup: rbac.authorization.k8s.io
  - kind: ServiceAccount
    name: default
    namespace: production
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

rbac-patterns.md 补充了五种高频模式：只读访问、命名空间管理员、部署管理者、Secret 读取（按 resourceNames 精确到单个 Secret）、CI/CD 管道部署权限。同时强调：优先用 Role 而非 ClusterRole、用 resourceNames 做细粒度控制、生产环境避免 * 通配、为每个应用创建专用 ServiceAccount 并默认 automountServiceAccountToken: false。

权限核查命令：

# 检查有效权限
kubectl auth can-i list pods --as system:serviceaccount:default:my-sa
kubectl auth can-i '*' '*' --as system:serviceaccount:default:my-sa

5.4 加固 Pod 与策略即代码

受限 Pod 安全上下文（容器级纵深配置）：

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: myapp:1.0
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL

OPA Gatekeeper 准入控制：通过 ConstraintTemplate（Rego 策略）与 Constraint（参数实例）两段式声明强制"Deployment 必须携带 app 与 environment 标签"。技能还给出 Istio 安全配置（PeerAuthentication mTLS STRICT 模式、AuthorizationPolicy 按 SPIFFE identity 授权），以及 CIS Benchmark 与 NIST 框架的合规对照清单。

六、清单生成与 Helm 打包：从 YAML 到可复用图表

6.1 生产级 Deployment 清单要素

k8s-manifest-generator 技能强调 10 条最佳实践：必须设置资源 requests/limits、实现健康检查、使用精确镜像 tag、应用安全上下文、用 ConfigMap/Secret 分离配置、全面打标签、遵循命名规范、apply 前 dry-run 校验、清单纳入 Git 版本控制、用 annotations 补充上下文。

配套 deployment-spec.md 给出了完整字段参考，核心要点包括：

• 更新策略：RollingUpdate（默认）与 Recreate 的取舍；零停机配置为 maxSurge: 1, maxUnavailable: 0
• 三类探针：startupProbe（慢启动应用）、livenessProbe（失败重启容器）、readinessProbe（控制流量摘除）
• QoS 三档：Guaranteed（requests=limits，最晚被驱逐）、Burstable、BestEffort（最早被驱逐）
• 镜像拉取策略：IfNotPresent（带 tag 镜像默认）、Always（:latest 默认）、Never
• 生产检查清单：副本数 ≥3、反亲和跨节点打散、优雅终止（preStop + terminationGracePeriodSeconds）、ServiceAccount 最小 RBAC

6.2 Helm 图表结构与标准化

helm-chart-scaffolding 技能与 chart-structure.md 参考文档覆盖从目录布局到依赖管理的全链路：

my-app/
├── Chart.yaml              # 图表元数据（必需）
├── Chart.lock              # 依赖锁文件（生成）
├── values.yaml             # 默认配置值（必需）
├── values.schema.json      # 值校验 JSON Schema
├── .helmignore             # 打包排除模式
├── charts/                 # 内置依赖
├── crds/                   # CRD（不参与模板渲染）
├── templates/              # K8s 清单模板（必需）
│   ├── NOTES.txt           # 安装后指引
│   ├── _helpers.tpl        # 模板辅助函数
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── hpa.yaml
│   ├── networkpolicy.yaml
│   └── tests/
│       └── test-connection.yaml
└── files/                  # 附带文件

Chart.yaml（API v2 / Helm 3+）核心字段：apiVersion: v2、name、version（SemVer）、appVersion、type（application 或 library）、kubeVersion（如 ">=1.24.0"）、dependencies（含 condition、tags、import-values、alias）。模板规范要求：helpers 前缀下划线、命名全部小写连字符、quota 字符串使用 | quote、依赖版本精确锁定。

依赖管理命令：

helm dependency update   # 更新依赖并生成 Chart.lock
helm dependency list     # 列出依赖
helm dependency build    # 基于 lock 重建依赖

校验与排障：

helm template my-app ./my-app --debug        # 渲染调试
helm install my-app ./my-app --dry-run --debug  # 试安装
helm test my-release --logs                  # 运行测试
kubectl get events --sort-by='.lastTimestamp'   # 查看事件

配套资产 values.yaml.template 是一份近乎开箱即用的生产化 values 模板：内置 global 共享值、镜像配置、serviceAccount、Prometheus 抓取 annotations、Pod/容器双层 securityContext、ingress、resources、探针、HPA、PDB（minAvailable: 1）、反亲和、postgresql/redis 依赖开关、ServiceMonitor 与 NetworkPolicy 开关。

七、智能体的行为准则与协作方法论

7.1 行为特质（Behavioral Traits）

智能体文档明确了 10 条行为准则，塑造其决策风格：

• 坚持 Kubernetes 优先的方法，同时识别合适的使用场景
• 从项目初始就落地 GitOps，而非事后补课
• 优先保障开发者体验与平台可用性
• 强调默认安全，采用纵深防御策略
• 面向多集群与多区域韧性进行设计
• 倡导渐进式交付与安全部署实践
• 聚焦成本优化与资源效率
• 将可观测性与监控视为基础能力
• 重视所有运维的自动化与 IaC
• 在架构决策中考虑合规与治理要求

7.2 响应方法论（Response Approach）

智能体的工作流是九步递进式，从需求评估到文档沉淀：

1. 评估工作负载需求，确定容器编排需求
2. 设计适配规模与复杂度的 Kubernetes 架构
3. 实施 GitOps 工作流，构建合理的仓库结构与自动化
4. 配置安全策略（Pod Security Standards + NetworkPolicy）
5. 搭建可观测性栈（指标、日志、追踪）
6. 规划弹性伸缩（自动扩缩 + 资源管理）
7. 考虑多租户需求与命名空间隔离
8. 成本优化（right-sizing + 资源高效利用）
9. 文档化平台（运维流程 + 开发者指南）

7.3 典型交互场景（Example Interactions）

文档给出 8 个可直接用于触发智能体的实战提问模板：

• "为一个金融服务公司设计带 GitOps 的多集群 Kubernetes 平台"
• "用 Argo Rollouts 和服务网格流量拆分实现渐进式交付"
• "创建带命名空间隔离与 RBAC 的安全多租户 Kubernetes 平台"
• "为跨多个 Kubernetes 集群的有状态应用设计灾备方案"
• "在维持性能与可用性 SLA 的前提下优化 Kubernetes 成本"
• "为微服务搭建 Prometheus、Grafana、OpenTelemetry 可观测性栈"
• "创建带安全扫描的容器应用 GitOps CI/CD 流水线"
• "设计用于自定义应用生命周期管理的 Kubernetes Operator"

八、总结：从智能体到可落地平台工程

agents24 仓库中的 kubernetes-operations 插件包呈现了一个"智能体定方向、技能给实操"的完整范式：kubernetes-architect 智能体负责在架构层面做决策与规划，而四个配套技能则把决策翻译为可直接执行的 YAML 与命令——gitops-workflow 打通 ArgoCD/Flux 双路线的持续交付，k8s-manifest-generator 保证清单的生产级质量，helm-chart-scaffolding 实现配置的可复用与版本化，k8s-security-policies 则把纵深防御落到每一层。读者无论是规划全新集群，还是改造存量交付体系，都可以按"架构设计 → 清单/图表生成 → GitOps 接入 → 安全加固 → 可观测与成本治理"的路径，将这套方法论直接映射到自己的 Kubernetes 环境中。