当前位置：首页 > news >正文

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

news 来源：原创 2025/6/9 23:41:32

在 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/v1blockOwnerDeletion: truecontroller: truekind: Installationname: defaultuid: a2bfb722-eeac-4581-a9ff-f8da4fd01cf7

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

解决方案

方法 1：修改 `Installation` CR

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

查找 Installation CR：
```
kubectl get installation -n calico-system
```
你应该能看到一个名为 default 的 Installation 资源。
编辑 Installation CR：
```
kubectl edit installation default -n calico-system
```
在编辑器中找到与镜像相关的配置，例如 spec.imagePullSecrets 或类似字段，将 image 替换为 docker-0.unsee.tech。
保存修改后，Operator 会自动更新相关资源。

方法 2：禁用 Operator 管理

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

导出当前的 Deployment 资源：

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

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

ownerReferences:
- apiVersion: operator.tigera.io/v1blockOwnerDeletion: truecontroller: truekind: Installationname: defaultuid: a2bfb722-eeac-4581-a9ff-f8da4fd01cf7

重新应用修改后的文件：

kubectl apply -f calico-kube-controllers.yaml

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

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

方法 3：通过 Helm 修改

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

检查 Helm Release：
```
helm list -A
```
如果看到与 tigera-operator 相关的 Release，可以通过 Helm 更新配置。

更新 Helm 配置：

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

注意事项

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

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