一、手动运维Kubernetes的那些糟心事

1.1 看不见的“配置漂移”坑

很多刚接触Kubernetes的开发者，初期都是靠kubectl apply命令把配置推到集群里，比如开发环境改了一个Pod的资源限制，就直接在集群里改，或者更新部署配置的时候，只在测试环境用kubectl apply，忘了把配置同步到Git仓库。时间久了，集群里的实际状态和Git里存的“官方配置”就会不一样——比如Git里写的是副本数2，集群里被人手动改成了3，等到下次要更新发布，直接用Git里的配置apply，就会把副本数改回2，突然出现服务扩容不足的问题，这就是大家常说的“配置漂移”。还有一种情况，多环境管理的时候，dev、test、prod三个环境的配置，靠人工复制粘贴，很容易写错路径或者改少参数，比如把prod的副本数设成2，dev设成3，结果发布的时候不小心把prod的配置推到dev，或者反过来，导致环境混乱。

1.2 为什么ArgoCD能解决这个问题

ArgoCD是专门用来做Kubernetes GitOps工具的，它的核心逻辑很简单：把Git仓库当成所有Kubernetes配置的“唯一真实来源”，集群里的实际运行状态必须和Git里的配置完全一致。如果集群里有人手动改了配置（比如改副本数、改镜像），或者配置没同步，ArgoCD会自动把集群里的配置改回和Git里一样的状态，这就是它的“配置漂移防御”能力。而且它还能直接区分多环境，不用手动维护不同环境的配置文件，只需要在Git里把不同环境的配置放在不同路径，ArgoCD就能分别部署到对应的环境里。

二、用ArgoCD搭多环境配置防御体系的具体步骤

2.1 先装ArgoCD到你的K8s集群

这里用的是标准的Kubernetes集群，安装命令都是官方推荐的，很简单：

# 先创建ArgoCD专属的命名空间，避免和业务资源混在一起
kubectl create namespace argocd
# 用官方的安装清单部署ArgoCD
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
# 等待所有ArgoCD的Pod都启动完成，避免后面操作出错
kubectl wait --for=condition=Ready pods --all -n argocd --timeout=300s

安装完之后，你可以用kubectl get pods -n argocd看看，会有api-server、repo-server等Pod，全部Running就说明安装成功了。

2.2 配置多环境的Application规则

ArgoCD里的每个“Application”对应一个要部署的Kubernetes应用，我们可以给每个环境（比如dev、test、prod）分别建一个Application，这样就能实现多环境隔离，每个环境的配置都独立管理。比如dev环境的Application配置，你需要新建一个YAML文件，内容如下：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  # Application的名字，这里对应dev环境的应用，方便识别
  name: my-app-dev
  # 这个Application要部署到哪个命名空间，一般和业务环境对应
  namespace: myapp-dev
spec:
  # 项目用默认的就行，多人协作的时候可以建专属项目
  project: default
  # 配置从哪里拉取Kubernetes的配置，这里是你的Git仓库
  source:
    repoURL: 'https://github.com/你的Git账号/你的K8s配置仓库.git'
    # targetRevision是拉取的分支，dev环境就用dev分支，prod用main分支
    targetRevision: dev
    # path是Git里dev环境配置的路径，你可以把不同环境的配置分文件夹放，比如仓库根目录的myapp/dev
    path: 'myapp/dev'
  # 配置要部署到哪个集群和命名空间，这里默认就是本地K8s集群，命名空间和上面对应
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: myapp-dev
  # 核心的同步策略，用来防配置漂移的关键设置
  syncPolicy:
    automated:
      # prune=true：如果Git里没这个资源，集群里的对应资源要删掉，避免多余资源
      prune: true
      # selfHeal=true：如果集群里的资源和Git里不一样，自动改回Git的版本，这就是防御漂移的核心
      selfHeal: true
    # 其他同步选项，比如如果命名空间不存在就自动创建
    syncOptions:
      - CreateNamespace=true

这个配置的意思是，my-app-dev这个应用，所有配置都从Git仓库的myapp/dev路径下的dev分支拉，部署到myapp-dev命名空间，而且只要集群里的配置和Git不一样，就自动修复成Git的版本——不管是副本数被改了，还是镜像被换了，都会自动改回来，完美防止人为导致的配置漂移。

2.3 实际测试：模拟配置漂移和自动修复

现在我们来做个小测试，看看ArgoCD怎么防御漂移。首先，先确认Git里的myapp/dev路径下的Deployment配置，里面的replicas（副本数）是2，然后我们手动在集群里把这个Pod的副本数改成3，看看会发生什么： 首先，用命令查看当前集群里的副本数：

# 查看dev环境里myapp的Pod副本数
kubectl get deployment myapp -n myapp-dev

假设现在输出是3，说明我们手动改成功了，接下来等1-2分钟，再运行一次上面的命令，你会发现副本数自动变成了2——ArgoCD已经自动把集群里的配置同步回Git里的版本了，这就是自动修复配置漂移的效果。这个过程完全不需要你手动操作，ArgoCD会在后台一直监控集群和Git的状态，只要有差异就自动修复，这就是它的核心价值。

三、这个方案适合哪些场景？优缺点是什么？

3.1 适用场景

第一，多环境管理的项目，不管是dev、test还是prod，都需要配置统一，不会因为人工操作导致环境差异；第二，团队协作开发K8s项目，多人操作的时候，避免有人误改集群配置，ArgoCD作为统一的入口，所有配置都经过Git审核；第三，追求一致性的生产环境，生产环境必须和Git里的配置完全一致，不能有任何私自修改，这个方案能完全满足这个要求，减少生产故障；第四，大项目，配置多，用ArgoCD的Git管理，回滚方便，只要Git里的配置改坏了，直接切回旧版本就行，不用再找集群里的配置。

3.2 优缺点分析

优点很明显：一是完全自动化，减少手动操作的错误，比如之前手动apply容易漏参数，现在都由ArgoCD处理；二是实时防漂移，不用定期检查集群配置，后台自动监控；三是Git历史清晰，所有配置的修改都有记录，方便排查问题；四是多环境隔离，每个环境的配置独立，不会混乱。 当然也有缺点：一是新手需要适应GitOps的概念，刚开始可能会觉得不如直接用kubectl灵活；二是自动同步如果配置太激进，比如prune开启的话，Git里没的资源会被删掉，所以要小心配置；三是小项目没必要，安装和维护ArgoCD需要一点资源，对于只有两三个人的小项目，手动操作可能更简单。

四、使用过程中要注意的关键点

4.1 权限控制

ArgoCD的账号权限要严格控制，不能让它有太多权限，比如prod环境的Application，最好用独立的账号，只有有权限的人才能修改，避免误改生产环境的配置；dev环境的话可以宽松一点，方便开发调试。

4.2 自动同步的配置

dev环境可以开自动同步，方便快速迭代，但是prod环境最好开手动同步，或者至少加个审批步骤，比如每次同步前要有人确认，避免自动同步把错误的配置推到生产环境；或者可以配置同步超时，万一有问题能及时停止。

4.3 Git分支管理

最好给每个环境对应不同的Git分支，比如dev对应dev分支，test对应test分支，prod对应main分支，不要用同一个分支，这样能避免把dev的配置不小心推到prod，比如你在dev分支改了配置，不会自动同步到prod分支，更安全。

4.4 资源版本锁定

Kubernetes里的镜像最好用固定的标签，比如用v1.2.3，不要用latest标签，因为latest是动态的，Git里的配置如果用latest，实际部署的镜像可能和仓库里的不一样，导致同步的时候出问题，一定要用固定的版本标签，保证配置的一致性。

五、总结

之前很多开发者用kubectl apply手动维护Kubernetes配置，很容易遇到配置漂移、多环境混乱的问题，而用ArgoCD打造的多环境防御体系，通过Git作为唯一真实来源，自动同步集群配置，完全解决了这些痛点。不管是团队协作还是生产环境，这个方案都能大幅减少配置错误，提升运维效率，而且上手也不难，只要熟悉Git的基本操作，就能快速搭建起来。当然使用的时候要注意权限、同步策略、分支管理这些细节，才能发挥最大的效果。