一次簡單的鏡像升級操作，為何會導致已移除的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這個強大的容器編排平台。
