K8S問題集錦

經過在內網自建K8S環境及使用華爲雲CCE對現網平臺進行一輪容器化改造測試後，積累一些k8s的常見問題和應對方案，整理以下。

問題1、POD時間同步問題

容器內部時間和node節點的系統時間不一致，這個問題其實不是k8s問題，單純使用docker也存在相似問題。

解決方案，將物理機的時區文件以hostpath方式只讀掛載，這樣只要保證物理機的系統時間是正確的便可。

問題2、POD內部hosts文件問題

默認狀況下，k8s會將pod的hostname和ip地址添加到hosts文件裏面，實際應用場景下會有手工去追加hosts文件記錄的需求，而pod的生存週期是不固定的，所以官方提供了hostalias的解決方案。
https://kubernetes.io/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases/

經過配置pod內部hosts文件的初衷有兩個。
一、有些微服務之間的調用走的是公網解析，效率低且DNS有可能響應超時。
二、目前開發、測試和現網環境，本質上代碼是同一套。
咱們經過配置hosts記錄，能夠將程序鏈接mysql、mongodb、mq這些公共服務的名稱固定。不一樣的環境對應的公共服務的IP地址經過hostalias方式注入（須要保證三套環境的公共服務用戶名、密碼、端口這些信息是一致的）能夠有效避免因爲配置的緣由致使的問題。

問題3、滾動更新問題

在只配置一個POD副本且爲配置滾動升級的狀況下，當咱們須要對POD進行升級重啓的時候，會立刻把僅有的一個正常POD關閉掉，同時啓動一個新的POD，這個過程當中，服務將會短暫不可用。

解決方案，配置滾動更新策略

問題4、存活檢測和工做負載檢測

當POD內的進程不工做或者OOM了，須要進行自我重啓工做。未配置liveness狀況下是沒法檢測和處理相似狀況的。

解決方案，配置liveness和readiness探針


這裏須要說明一下liveness探針主要用來判斷POD內的進程是否存活，readiness探針用來判斷pod內的進程是否已準備就緒，在未就緒以前，對應service的流量不會轉發到pod內。

問題5、java應用時區同步問題

JVM啓動時候的時區。若是不指定，則默認取系統時區，這就會致使java應用的時間和容器時間差8個小時。

解決方案，經過配置JAVA_OPTS設置java時區（一樣JVM的內存參數也能夠經過這種方式配置）
-Duser.timezone=GMT+08 或者 -Duser.timezone=Asia/Shanghai

問題6、集羣內外網絡互通問題

K8s集羣不一樣node上的pod網絡通訊是經過cni網絡插件（例如flannel、calico等）實現的，路由信息保存在etcd中，pod網絡訪問互聯網經過node的iptables nat實現。

但在實際應用環境中，需求老是多樣的，當在k8s集羣外部的主機須要直接訪問pod網絡的時候，就須要經過配置路由手段才能實現。對應的解決方案就是添加路由。

和node節點在同一個網段內的主機，將對應網絡的下一跳地址指向相應的node節點便可。

和node節點不在同一個網段內的主機，須要在上層路由上進行配置。

問題7、POD間網絡隔離

默認 Pod 是未隔離的，POD之間的網絡暢通無阻。實際應用中，會有配置網絡隔離的需求。
好比須要在pod間作流量的精細控制。

解決方案，使用networkpolicy (要求集羣的CNI插件能支持networkpolicy)

後記

還有一些例如elb、Ingress關聯進行服務發佈、APM應用性能監控、AOM容器監控和日誌收集、容器鏡像倉庫、CI\CD流水線的集成，目前國內公有云三巨頭（阿里雲、華爲雲、騰訊雲）都有詳盡的解決方案和文檔，就不在一一介紹了，感興趣的同窗能夠看看三巨頭的官方文檔。