1:容器內部時間和node節點的系統時間不一致
詳細描述：
容器內部時間和node節點的系統時間不一致
例如： kubectl exec -it <pod-name> date
UTC 2019
node 上的date CST
解題思路：
無
原因分析：
這個不單單是K8s問題， 單純使用docker也存在類似的問題
解決步驟：
將物理機的時區文件以hostpath方式只讀掛載，這樣只要保證物理機的系統時間正確即可
修改yaml文件中：
containers:
-mountPath: /etc/localtime
name: vol-localtime
readOnly: true
volumes:
-name: vol-localtime
hostpath:
path: /etc/localtime
2:pod內部hosts文件問題
詳細描述：
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文件的初衷有兩個：
1: 有些微服務之間的調用走的是公網的解析，效率低且DNS有時候會出現響應超時問題
2:目前開放、測試和現網環境，本質上代碼是同一套
我們可以通過配置hosts記錄，可以將程序連接mysql、mongodb、mq這些公共服務的名稱固定，不同的環境對應的公共服務的IP地址通過hostalias方式注入，可以有效避免由於配置的原因導致的問題。
對應yaml中的內容：
spec：
hostAliases：
- ip: "xx.xxx.xx.xxx"
hostnames:
- "mysql-master"
- "proxysql-server"
- "redis-server"
3:Pod 滾動更新問題
詳細描述：
Pod 滾動更新問題
在只配置一個POD副本且爲配置滾動升級的情況下，需要對POD進行升級重啓的時候，會馬上把僅有的一個正常的POD關閉掉，同時啓動一個新的POD，這個過程中服務會短暫不可用。
解題思路：
無
原因分析：
無
解決步驟：
配置滾動更新策略
strategy：
type： RollingUpdate
rollingUpdate：
maxUnavailable： 25%
maxSurge： 25%
revisionHistoryLimit： 10
progressDeadlineSeconds： 600
4: 存活檢測和工作負載檢測
詳細描述：
存活檢測和工作負載檢測
當POD內的進程不工作或者OOM了，需要進行自我重啓工作，未配置liveness情況下是無法檢測和處理類似情況
解題思路：
無
原因分析：
無
解決步驟：
配置liveness和readiness探針
livenessProbe：
exec：
command：
- curl
- "http://127.0.0.1:8080"
initialDelaySeconds: 60
timeoutSeconds: 2
periodSeconds: 10
successThreshold: 1
failureThreshold: 3
readlinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 90
timeoutSeconds: 3
periodSeconds: 10
successThreshold: 1
failureThreshold: 3
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
這裏需要說明一下liveness探針主要用來判斷POD內的進程是否存活，readiness探針用來判斷pod內的進程是否已準備就緒，在未就緒之前，對應service的流量不會轉發到pod內。
5:java應用時區同步問題
詳細描述：
java應用時區同步問題
JVM啓動時候的時區。如果不指定，則默認取系統時區，這就會導致java應用的時間和容器時間差8個小時。
解題思路：
無
原因分析：
無
解決步驟：
通過配置JAVA_OPTS設置java時區（同樣JVM的內存參數也可以通過這種方式配置）
-Duser.timezone=GMT+08 或者 -Duser.timezone=Asia/Shanghai
yaml文件：
env：
-name: JAVA_OPTS
value: >-
-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之間的網絡暢通無阻，實際應用中，會有配置網絡隔離的需求，比如需要在pod間做流量的精細控制。
解決步驟：
使用networkpolicy（要求集羣的CNI插件可以支持networkpolicy）