次简单的镜像升级操作，为何会导致已移除的hostPort配置神秘回归？本文将揭示Kubernetes配置管理中这个常见陷阱。
回到顶部
问题背景：消失的配置又回来了
在日常的Kubernetes运维中，我们经常会遇到需要修改部署配置的情况。某天，我需要将某个服务的网络模式从hostPort改为ClusterIP。按照标准流程，我修改了Deployment的YAML文件：
# 修改前
ports:
- containerPort: 80
hostPort: 8000 # 需要移除的配置
protocol: TCP
# 修改后
ports:
- containerPort: 80
protocol: TCP
使用kubectl apply -f deployment.yaml应用更改后，一切正常——直到我通过Rancher UI升级镜像版本时，发现hostPort配置竟然又回来了！
回到顶部
深入排查：发现配置的“双重人格”
经过仔细比对，我发现了问题的根源：Kubernetes资源上存在两套独立的配置系统。
第一套：Kubernetes原生配置
这是我们都熟悉的Deployment的Pod模板规范，位于spec.template.spec.containers.ports下。
第二套：管理平台的注解配置
在Rancher这样的管理平台中，还有一个隐藏的配置源——field.cattle.io/ports注解：
# 问题配置（修改前）
field.cattle.io/ports: '[[{"containerPort":10002,"hostPort":10002,"kind":"HostPort","protocol":"TCP"}]]'
# 正确配置（修改后）
field.cattle.io/ports: '[[{"containerPort":10002,"kind":"ClusterIP","protocol":"TCP"}]]'
回到顶部
问题根源：两套配置的优先级冲突
问题的本质在于配置管理的不一致：
当我使用kubectl时，只修改了Kubernetes原生的Pod模板配置
但Rancher管理平台在执行操作（如升级镜像）时，会优先读取其注解中的配置
由于注解中的旧配置未被更新，Rancher操作时就用旧配置覆盖了新配置
这就像一个人有"双重人格"：周一到周五是A人格，周末却变成了B人格。
回到顶部
解决方案：统一配置管理
要彻底解决这个问题，需要确保两套配置同步更新：
完整的修正步骤
# 1. 导出当前完整配置
kubectl get deployment my-app -o yaml > deployment.yaml
# 2. 同时修改两处配置
# - 删除spec.template.spec.containers.ports中的hostPort
# - 更新metadata.annotations中的field.cattle.io/ports注解
# 3. 应用完整配置
kubectl apply -f deployment.yaml
配置对比示例
通过实际配置对比，可以清晰看到修改的关键点：
• 移除所有hostPort字段
• 将kind从HostPort改为ClusterIP
• 确保注解中的JSON格式正确
回到顶部
经验总结与最佳实践
这次经历让我总结了以下Kubernetes配置管理经验：
1. 理解管理平台的工作机制
使用Rancher、OpenShift等平台时，务必了解它们如何扩展Kubernetes的原生配置管理。
2. 坚持声明式配置管理
• 将完整的YAML配置纳入版本控制
• 所有变更都通过修改YAML文件+kubectl apply进行
• 避免混合使用命令式（kubectl edit）和声明式管理
3. 变更后全面验证
修改配置后，不仅要检查Pod状态，还要验证：
# 检查注解配置
kubectl get deployment my-app -o jsonpath='{.metadata.annotations}'
# 检查实际端口配置
kubectl describe pod my-app-pod | grep -i port
4. 建立配置检查清单
在修改网络、存储等关键配置时，建立检查清单确保不遗漏任何配置点。
回到顶部
结语
Kubernetes生态中的管理平台为我们提供了便利，但也引入了配置管理的复杂性。这次hostPort神秘复现的经历提醒我们：在云原生时代，理解工具的工作原理与掌握工具的使用同样重要。
只有深入了解底层机制，才能在问题出现时快速定位并解决，真正驾驭好Kubernetes这个强大的容器编排平台。
- 报数游戏（Java JS Python）)
