修复 Kubernetes Deployment 修改后未生效的问题

在 Kubernetes 集群中，当尝试修改某些 Deployment 资源（如 calico-kube-controllers）的 image 配置时，发现修改总是未生效，并恢复到原样。这种问题通常是因为 Deployment 资源受到其他控制器（如 Operator）的管理，以下是详细的原因分析和解决方案。

---

问题背景

通过以下命令查看 calico-kube-controllers 的 YAML 文件：

kubectl get deploy calico-kube-controllers -n calico-system -o yaml

可以看到资源中有以下字段：

ownerReferences:
  - apiVersion: operator.tigera.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: Installation
    name: default
    uid: a2bfb722-eeac-4581-a9ff-f8da4fd01cf7

ownerReferences 表明该 Deployment 是由 tigera-operator 的 Installation CR（Custom Resource，自定义资源）管理的。当 tigera-operator 检测到资源被手动更改时，会自动将其恢复到 Operator 定义的状态。

---

解决方案

方法 1：修改 Installation CR

这是推荐的方法，直接从根本上修改 Operator 管理的自定义资源。

1. 查找 Installation CR：

   kubectl get installation -n calico-system
   

   你应该能看到一个名为 default 的 Installation 资源。

2. 编辑 Installation CR：

   kubectl edit installation default -n calico-system
   

   在编辑器中找到与镜像相关的配置，例如 spec.imagePullSecrets 或类似字段，将 image 替换为 docker-0.unsee.tech。

3. 保存修改后，Operator 会自动更新相关资源。

---

方法 2：禁用 Operator 管理

如果希望手动管理该资源，可以尝试移除 ownerReferences，但需注意这可能会带来不可预期的后果。

1. 导出当前的 Deployment 资源：

   kubectl get deploy calico-kube-controllers -n calico-system -o yaml > calico-kube-controllers.yaml
   

2. 移除 ownerReferences 字段：
   打开导出的 calico-kube-controllers.yaml 文件，找到以下内容并删除：

   ownerReferences:
   - apiVersion: operator.tigera.io/v1
     blockOwnerDeletion: true
     controller: true
     kind: Installation
     name: default
     uid: a2bfb722-eeac-4581-a9ff-f8da4fd01cf7
   

3. 重新应用修改后的文件：

   kubectl apply -f calico-kube-controllers.yaml
   

4. 编辑镜像配置并检查是否生效：

   kubectl edit deploy calico-kube-controllers -n calico-system
   

---

方法 3：通过 Helm 修改

如果 tigera-operator 是通过 Helm 部署的，可以通过修改 Helm 的 values.yaml 文件来更新镜像配置。

1. 检查 Helm Release：

   helm list -A
   

   如果看到与 tigera-operator 相关的 Release，可以通过 Helm 更新配置。

2. 更新 Helm 配置：

   helm upgrade <release-name> <chart-name> -n calico-system --set image.repository=docker-0.unsee.tech/<image-name>
   

---

注意事项

1. 优先选择修改 Operator 的 CR： 直接修改 Operator 管理的资源是推荐的方式，可以确保集群状态一致且不会破坏 Operator 的功能。
2. 小心禁用 Operator 管理： 禁用 Operator 管理后，可能会导致其他依赖该资源的功能异常。
3. 备份配置： 在进行重大修改前，务必备份现有配置，以便在出现问题时快速回滚。

---

通过以上方法，能够有效解决 Deployment 修改后无法生效的问题。