kubectl apply -f 仅是手动触发的声明式更新，缺乏自动感知变更、配置校验、环境隔离、失败回滚和状态追踪能力；真正的自动化部署需依托 GitOps（如 Argo CD）或 CI/CD 流水线实现闭环管理。
直接用 kubectl apply -f 不算自动化部署，只是手动触发一次声明式更新。真正的自动化部署必须满足：配置变更自动感知、校验通过后自动生效、失败可回退、状态可追踪——这需要 GitOps 或 CI/CD 流水线介入。
为什么不能只靠 kubectl apply
单纯执行 kubectl apply 缺少关键闭环能力：
- 没有变更来源审计：谁改了 YAML？什么时候改的？改了哪几行？
- 无法阻止非法配置：比如
replicas: -1或错误的imagePullPolicy值，kubectl apply会报错但不拦截提交 - 缺乏环境隔离：dev/staging/prod 共用同一份清单时，容易误操作
- 无自动回滚：部署失败后不会自动切回上一版本，得人工干预
GitOps 是当前最主流的自动化部署路径
核心是把 Git 当作唯一可信源，让集群状态与 Git 仓库内容保持最终一致。常用工具是 Argo CD 或 Flux。
典型做法：
- YAML 清单（
Deployment、Service、Ingress等）全部存入 Git 仓库，按环境分目录（如environments/prod/） - 在集群中部署
Argo CD，配置它监听指定分支和路径 - 当 Git 提交变更，
Argo CD自动检测差异、执行apply、并标记同步状态（SyncStatus: Synced） - 若部署失败（如镜像拉取失败），
Argo CD会停留在OutOfSync状态，不自动重试，避免雪崩
示例 Argo CD Application CR：
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: myapp-prod
spec:
project: default
source:
repoURL: https://github.com/myorg/k8s-manifests.git
targetRevision: main
path: environments/prod
destination:
server: https://kubernetes.default.svc
namespace: myapp
syncPolicy:
automated:
prune: true
selfHeal: false
CI/CD 流水线中集成部署需绕开几个坑
如果团队还在用 Jenkins/GitLab CI 等传统 CI 工具做部署，注意这些实操细节：
-
kubectl必须在 CI runner 中预装，且配置好KUBECONFIG；建议用 service account token + RBAC 控制权限，别用 admin kubeconfig - 镜像 tag 推荐用
$CI_COMMIT_SHA或$CI_PIPELINE_ID，避免用latest—— 否则kubectl apply无法感知镜像变更 - 必须加健康检查步骤：部署后调用
kubectl rollout status deployment/myapp，超时或失败则中断流水线 - 多环境部署时，用
--namespace和-l environment=prod隔离资源，别依赖文件名或路径
自动化部署的边界在哪
很多人误以为“自动部署”等于“全自动上线”。实际上，生产环境中至少有三类操作仍需人工确认：
- 涉及数据迁移的变更（如数据库 schema 更新）
- 影响 SLA 的重大版本升级（如从 v1.23 升到 v1.25）
- 首次部署新服务（需要人工验证 Service、Ingress、监控是否就绪）
这些环节适合用 approval 步骤卡点，而不是追求全链路无人值守。真正的难点不在脚本怎么写，而在于定义清楚哪些变更可以自动放行、哪些必须人工兜底——这需要和 SRE、业务方一起对齐 SLI/SLO 后才能落地。
