一、先搞懂两个运维工具的核心区别

很多做云原生服务治理的朋友，肯定都用过Linkerd做服务网格，但不少人会纠结：到底用CLI还是Operator来运维？其实这俩工具根本不是“二选一”的关系，而是各有分工的“左右手”。 先给大家说个直白的类比：CLI就像你手机里的手动相机模式，所有参数都得自己调，想拍啥拍啥，想停就停；Operator就像手机里的自动相机模式，大部分场景能自动搞定，但复杂场景得手动调整。 再具体点讲，CLI是Linkerd官方提供的命令行工具，你敲啥命令它就干啥，所有操作的节奏、范围、程度完全由你控制；Operator是部署在K8s集群里的一个“运维机器人”，它会盯着你提前配置好的规则，自动帮你做安装、升级、扩容这些事，不用你反复敲命令。

1.1 CLI的特点

CLI最大的特点就是“完全可控”，就像你亲自下厨，每一步加多少盐、炒多久、什么时候关火，全由你说了算。比如你想只给某一个服务做升级测试，不想影响其他服务，CLI就能精准做到；但缺点也明显：所有操作都得你自己盯着，要是你忘了停，可能会出问题。

1.2 Operator的特点

Operator的特点是“自动化”，就像用炒菜机做饭，你提前选好菜的种类、口味，它会自动按步骤做，不用你一直盯着。比如你想让Linkerd每个月自动升级到最新稳定版，Operator就能帮你搞定；但缺点是它的自动化规则是提前写死的，要是遇到突发情况（比如升级时某台节点出问题），它可能会按规则继续走，不会灵活调整。

二、核心场景：滚动升级和回滚的选择逻辑

咱们做运维，最关心的就是升级和回滚这两个场景，毕竟搞不好就会出故障。下面就给大家拆解这两个场景下，怎么选CLI和Operator。

2.1 滚动升级：要安全还是要省心？

滚动升级的核心是“逐步替换旧版本，保证服务不中断”，但不同的业务场景，对升级的要求不一样。 比如第一种场景：核心业务的大版本升级，比如Linkerd从2.10升到2.11，这个升级可能会改服务治理的核心逻辑，要是出问题影响范围大。这种场景下，就得选CLI。 给大家举个完整的例子，这个例子用的技术栈是Kubernetes + Linkerd CLI 2.11.4，所有操作都有注释，大家能直接跟着做。

# 第一步：先备份当前的Linkerd配置，防止出问题能快速恢复
linkerd install --output k8s > linkerd-2.10-backup.yaml

# 第二步：只升级控制平面的核心组件（比如控制器），先测试，不碰数据平面
# 这里的--control-plane-only参数是关键，只升级控制平面，数据平面保持旧版本，降低风险
linkerd upgrade --control-plane-only --output k8s > linkerd-2.11-upgrade-control.yaml

# 第三步：应用升级后的控制平面配置，观察状态
kubectl apply -f linkerd-2.11-upgrade-control.yaml
# 等5分钟，检查控制平面的状态，确保没有报错
linkerd check

# 第四步：如果控制平面没问题，再升级数据平面，而且只升级某一个测试服务的Pod
# 这里的-n test是指定命名空间，只给test命名空间里的服务升级，其他服务不受影响
linkerd upgrade --namespace test --output k8s > linkerd-2.11-upgrade-test-data.yaml
kubectl apply -f linkerd-2.11-upgrade-test-data.yaml

# 第五步：观察测试服务的状态，要是没问题，再全量升级所有数据平面
linkerd upgrade --output k8s > linkerd-2.11-upgrade-all-data.yaml
kubectl apply -f linkerd-2.11-upgrade-all-data.yaml

你看，用CLI做核心业务的升级，每一步都能停下来检查，要是某一步出问题，直接回滚到之前的备份就行，完全可控。 再比如第二种场景：非核心业务的小版本升级，比如Linkerd从2.11.3升到2.11.4，这个升级只是修bug，没有核心逻辑改动。这种场景下，就可以选Operator，省心。 给大家举个Operator的例子，技术栈还是Kubernetes + Linkerd Operator，先给大家说下Operator的配置逻辑：你提前写好一个自定义资源（CR），告诉Operator升级的规则，Operator会自动按规则升级。

# 这是Linkerd Operator的自定义资源配置，用来定义升级规则
apiVersion: linkerd.io/v1alpha2
kind: Linkerd
metadata:
  name: linkerd
spec:
  controlPlane:
    image:
      version: "2.11.4"  # 指定要升级到的版本
    # 升级策略：逐步升级，每次只升级10%的Pod，防止同时挂太多
    upgradeStrategy:
      type: RollingUpdate
      rollingUpdate:
        maxSurge: 10%  # 最多同时新增10%的升级后的Pod
        maxUnavailable: 0  # 升级时最多有0个Pod不可用，保证服务不中断
  dataPlane:
    autoInject: true  # 自动给新的Pod注入新版本的数据平面

把这个配置应用到K8s集群后，Operator就会自动按这个规则升级，你不用盯着，它会慢慢升级，要是某一步出问题，它会按maxUnavailable的规则，保证不会有太多Pod挂掉。

2.2 回滚：要精准还是要快速？

回滚的核心是“出问题后快速恢复”，但不同的故障场景，对回滚的要求不一样。 比如第一种场景：升级后发现核心业务有故障，比如某个服务的超时时间突然变高，而且是全量升级后出的问题，这种场景下，得快速全量回滚，选CLI。

# 技术栈：Kubernetes + Linkerd CLI 2.11.4
# 第一步：先停止正在进行的升级操作（要是有的话）
kubectl delete deployment -n linkerd linkerd-controller linkerd-proxy-injector

# 第二步：应用之前备份的2.10版本的配置，快速回滚
kubectl apply -f linkerd-2.10-backup.yaml

# 第三步：检查所有组件的状态，确保回滚成功
linkerd check --all

你看，用CLI回滚，直接应用备份的配置，一步就能全量回滚，速度快，适合全量故障的场景。 再比如第二种场景：升级后发现只有某一个服务有故障，比如test命名空间里的订单服务出问题，其他服务都正常，这种场景下，得精准回滚这个服务，选Operator。 因为Operator可以提前配置好精准回滚的规则，比如只有当test命名空间里的订单服务的错误率超过5%时，自动回滚这个服务到旧版本，不用你手动操作。 给大家举个Operator的回滚规则配置例子：

# 技术栈：Kubernetes + Linkerd Operator
apiVersion: linkerd.io/v1alpha2
kind: Linkerd
metadata:
  name: linkerd
spec:
  controlPlane:
    version: "2.11.4"
  dataPlane:
    # 精准回滚规则：只针对test命名空间的订单服务
    rollbackPolicy:
      namespace: "test"
      service: "order-service"
      # 触发条件：订单服务的错误率超过5%，持续30秒
      trigger:
        errorRate:
          threshold: 5
          duration: 30s
      # 回滚动作：把订单服务的代理版本回滚到2.11.3
      action:
        proxyVersion: "2.11.3"

这个配置应用后，Operator会实时监控订单服务的错误率，要是错误率超过5%，它会自动把订单服务的代理版本回滚到旧版本，不会影响其他服务，非常精准。

三、两种工具的优缺点和注意事项

3.1 CLI的优缺点和注意事项

优点：完全可控，每一步操作都能自己决定，适合核心业务的升级、回滚，也适合需要精准控制的场景。 缺点：所有操作都得手动做，需要运维人员盯着，要是操作失误，可能会出大问题；而且要是集群规模大（比如有几百个服务），手动升级会非常耗时。 注意事项：用CLI操作前，一定要备份配置，而且每次操作后要检查状态，确保没问题再进行下一步；不要同时操作多个核心组件，防止出问题后不知道是哪个组件的原因。

3.2 Operator的优缺点和注意事项

优点：自动化，不用运维人员盯着，适合非核心业务的升级、回滚，也适合集群规模大的场景；可以提前配置规则，应对突发情况。 缺点：规则是提前写死的，要是遇到规则外的情况，可能会处理不好；而且要是配置的规则有问题，可能会导致更严重的故障。 注意事项：用Operator配置规则时，一定要先在测试环境验证，确保规则没问题再应用到生产环境；规则里的maxSurge和maxUnavailable参数要合理设置，防止同时挂太多Pod；不要给核心业务配置过于激进的规则，比如maxUnavailable设为50%，要是出问题会导致一半的服务不可用。

四、总结

总的来说，CLI和Operator没有好坏之分，只有适合不适合的区别。核心业务的大版本升级、全量回滚，选CLI，因为可控；非核心业务的小版本升级、精准回滚，选Operator，因为省心。 做运维的核心是“务实”，不要盲目追求自动化，也不要完全手动操作，要根据场景选最合适的工具。比如你做核心业务的升级，哪怕Operator能自动做，你也得用CLI，因为出问题的代价太高；要是你做非核心业务的升级，手动操作太麻烦，就用Operator，省心省力。 最后给大家一个小建议：不管用CLI还是Operator，一定要做好备份，备份是运维的生命线，哪怕你再熟练，也不能忘了备份。