修改Kubernetes Service配置后不生效，如何强制其识别更新？

问题场景 #

将namespace-a中的service-a从ClusterIP类型修改为ExternalName类型后配置正常生效，但回滚回ClusterIP类型后，service-a仍持续转发至namespace-b的service-b。删除并重建service-a也无法解决，仅重建namespace-b的service-b才能恢复正常。

结论 #

这不属于预期行为，正常情况下Kubernetes Service的配置变更（包括回滚操作）应该触发CoreDNS同步更新对应的DNS记录。

可能原因分析 #

• CoreDNS缓存残留：CoreDNS默认会缓存Service的DNS记录，默认TTL为30秒。如果缓存未及时失效，或者集群中其他组件（如客户端Pod的本地DNS缓存）留存了旧记录，会导致解析结果未更新。即使删除重建service-a，若CoreDNS缓存未清空，旧的ExternalName解析记录依然会被返回。
• Service类型转换的同步延迟：ExternalName类型Service不需要关联Endpoints对象，而ClusterIP类型需要绑定对应Pod的Endpoints。从ExternalName转回ClusterIP时，kube-controller-manager创建Endpoints的动作与CoreDNS的记录更新可能存在时序差，导致DNS记录未及时切换回ClusterIP的解析结果。
• DNS组件版本bug：部分旧版本的CoreDNS或kube-dns在处理Service类型频繁切换时，存在DNS记录同步不及时的问题，无法正确识别Service配置的回滚操作。

强制Kubernetes识别Service配置修改的方法 #

• 清空CoreDNS缓存：
  1. 找到kube-system命名空间下的CoreDNS Pod：kubectl get pods -n kube-system | grep coredns
  2. 进入Pod执行缓存刷新命令：kubectl exec -n kube-system <coredns-pod-name> -- rndc flush
  3. 或者直接删除CoreDNS Pod（无状态组件，重建后缓存自动清空）：kubectl delete pods -n kube-system -l k8s-app=kube-dns
• 确认Endpoints状态：
  检查service-a对应的Endpoints是否存在且正确关联Pod：kubectl get endpoints service-a -n namespace-a，若Endpoints未生成，可等待控制器自动同步，或重启kube-controller-manager（生产环境需谨慎操作）。
• 调整DNS缓存TTL：
  修改CoreDNS的ConfigMap配置，缩短cache插件的TTL值（例如设置为10秒），减少缓存留存时间：

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: coredns
    namespace: kube-system
  data:
    Corefile: |
      .:53 {
          cache 10
          # 其他原有配置...
      }
  

  修改后重启CoreDNS Pod使配置生效。

关于重建service-b生效的原因 #

重建service-b会触发其自身Endpoints的更新，CoreDNS在同步service-b的DNS记录时，可能连带清理了与service-a相关的旧缓存记录，属于间接解决方式，并非针对service-a配置回滚问题的正确处理手段。

内容的提问来源于stack exchange，提问作者Datz