背景
在部署新的paas平臺線上環境時，突發consul和es中間件無法創建。
排查過程
以consul
通過查詢k8s集羣中pod狀態發現原來3pod的consul集羣，其中2個pod一直重啓。
# kubectl get pods -n paasconsul-propaas
通過describe查看pod信息，發現是liveness失敗。
# kubectl describe pods -n paasconsul-propaas
查看liveness調用的是health-check的二進制文件，經過分析源碼發現這個二進制文件的作用爲連接本地consul節點，查看當前節點狀態。現在查看集羣狀態錯誤。此時懷疑consul集羣配置出現問題
通過查看operator的log發現集羣並沒有報錯。並且打印有副本集配置完成的日誌出現在最後一行。但是後續一直沒有日誌打印，此時懷疑是operator沒有收到events事件。
爲了驗證events事件沒有獲取到，通過修改cr文件的cpu和內存參數，想要觸發新的更新event。結果不出意外，operator並沒有觸發更新操作，日誌並無新增，節點狀態並沒有改變
看到operator無任何響應，懷疑其已經卡死，爲了驗證此想法，又從paas平臺創建一個集羣，發現出現新日誌，後續又到副本集配置完成日誌打印，然後卡死。判斷operator狀態存活正常，只是對更新cr信息無響應。
問題分析
針對無法更新cr的狀態無法獲取events時間。開始分析
懷疑etcd寫入失敗，通過查看etcd日誌發現一切正常。（❎）
想起之前遇見的pod名字受DNS Label Names 63位長度限制，懷疑其cr是否也存在其問題。通過將原cr的yaml信息保留下來，改其名稱再運行。結果發現其正常運行。(✅)
問題處理
爲什麼名稱長度限制會導致operator卡死無響應？
這時候想到了tcp的mtu設置。虛擬機mtu和容器mtu不匹配將會導致網絡不通。
因爲當前k8s集羣採用的是IP-IN-IP協議，此協議可以解決掉k8s生產擴容時，不會引起新老主機不通問題。
# 查看物理節點mtu：
netstat -i
# 發現其物理節點mtu值爲1450
# 查看calico配置的mtu參數
kubectl get configmap/cali-config -n kube-system | grep "veth_mtu"
# 發現其mtu值也爲1450
此時問題原因找到，calico啓用tunnel模式，因此經過tunnel會封裝一個新的20字節的ip包頭，所以當發送大量數據時，calico生成的1450大小的數據包再加上20大小的ip包頭爲1470字節的包。
本地網卡轉發calico通訊數據包1470，將失敗。
可以通過兩種方式解決此問題。1、更改物理節點mtu值大小。2.修改calicomtu值大小爲 物理節點mtu-20。
推薦使用第二種
kubectl patch configmap/calico-config -n kube-system --type merge -p '{"data":{"veth_mtu": "1430"}}
根據實際需要調整所在k8s node節點的 eth0或tunl0的mtu，需確保tunl0的mtu比eth0的mtu少20。