在某地出差做實施的時候，把以前沒遇到過的坑都遇到了，每天都在懷疑自己能力有問題。
1.k8s pod網絡不通。
這個問題特別詭異，部署了兩個pod，會有一個網絡出現問題，ping 不通docker網關，ping不通svc地址，ping不通其他pod 的ip。
pod-A通，pod-B不通。過幾分鍾變成了pod-A網絡不通，pod-B網絡通。
嘗試過的方法：
最開始安裝的是k8s1.18.16，使用默認的calico網絡插件的ipip模式，后修改為bgp模式，失敗
將calico改為flannel，失敗。
懷疑版本問題，將k8s升級到1.19.8，使用calico cni的ipip模式，修改為bgp模式，改為用flannel，失敗。
懷疑機房網絡有限制，聯系機房網絡人員對接，回復無任何限制。
找了幾個k8s大佬指導，也無效果。
仔細排查發現，pod出現網絡問題都是在k8sn3這台機器上，再一檢查，這台機器內核升級失敗了，還是默認的3.10.x，其余機器均為5.8.x，升級內核后
問題解決。
總結就是，要細心啊。
2.基礎不牢固
由於默認不能訪問互聯網如微信登錄等網頁的權限，所以需要走申請。機房開通后宿主機可以訪問外網，而k8s里不行。
正常情況下，k8s cni不管使用什么插件，都要通過宿主機的網卡進行轉發的。懷疑機房做的策略特別嚴格，還需要對
k8s的網段100.64.0.0/10做策略，機房說這個網段和其他業務有沖突，要求修改為 101.200.0.0/24。於是在網上查如何修改calico
，官方說需要刪除所有舊的pod才能生效，那我還不如重裝呢。於是重裝k8s，重新部署。又浪費一天時間。
哪里基礎不牢固呢？
kubectl edit ds calico-node -n kube-system
查到了calico的網段是value: 100.64.0.0/10，但是查看k8s的pod有 100.68.x.x、100.79.x.x，就覺得這不准啊。
后來被大佬教育了一番，通過ip計算機去計算這個網段，發現這些ip地址確實都是包含在內的。
總結就是，基礎太差了，好好學習吧。
3.elasticsearch啟動失敗
在其他城市使用過無數次的安裝方法，到這里就是啟動不了。換rpm包，換自帶的jdk、換啟動用戶，換配置文件都不好使。
后來自己查看了報錯，在網上找到了，居然是啟動時間太長，超過了預設的超時時間，於是啟動失敗。修改超時時間即可。。。
https://terryl.in/zh/elasticsearch-service-start-operation-timed-out/
elasticsearch.service: Start operation timed out. Terminating.
4.rocketmq集群異常。
反饋短信發不出去了，在mq控制台查看發現消息擠壓嚴重。將defaultTopicQueueNums設置到20，發現rocketmq啟動不了了，沒有任何日志，9876端口也未監聽。
震驚了，完全沒遇到過這的問題，於是打算在k8s里部署了一套應急，結果服務器上不了網，遲遲拉不到鏡像。於是生產環境使用測試環境的mq先將就着用。
后來無意中發現，9876端口又處於監聽狀態了。於是再測試一次nohup sh mqnamesrv & 啟動namesrv，過了5分鍾居然啟起來了！！！再啟broker，又等了差不多5分鍾，又起起來了。但是，問題並沒有解決。，於是嘗試在控制台修改了defaultTopicQueueNums，修改以后積壓的問題解決了。
網上查資料才知道，有數據以后再修改這個參數是不生效的，只能在控制台修改。
https://www.jianshu.com/p/ccdf6fc710b0
activemq控制台修改密碼不生效
參考的是官方文檔，https://activemq.apache.org/web-console
照着修改以后無效
開始去github，stackoverflow、google各種查資料，把甚至把代碼注釋掉也不好使。
即activemq.xml里的刪掉都無效。
<import resource="${activemq.base}/conf/jetty.xml" />
深深的懷疑自己的能力，最后無意間ps -ef查看進程，發現有七八個進程，才發現每次重啟都沒生效，深深的震驚了我。
使用 ./activemq stop && ./activqmq start 居然重啟無效果！！！
所有進程kill掉再啟動，問題解決。
未完待續