一 Pod的驅逐需要的k8s組件的說明
kubelet：k8s-node的客戶端用來監控該node和pod（監控pod的增刪改查）的資源使用,pod的硬軟驅逐就是在該組件上設置。
etcd集羣：kubernetes之外的組件，k8s的所有的數據是存在該數據庫裏面的
kube-apiserver：數據交互中心，所有的數據通過kube-apiserver寫入etcd集羣
二 kubelet的優化
1、軟驅逐
當超過資源限制閾值時，先自己調整，若一段時間後還不能恢復，再進行驅逐
2、主要是針對硬驅逐的優化
參數設置：
–eviction-hard=memory.available<1024Mi \ 驅逐內存的限制當服務器的內存剩餘1024Mi的時候立馬執行硬驅逐策略（目前已經在使用中）
–kube-reserved=memory=512Mi \ k8s組件的內存預留
–system-reserved=memory=1024Mi \ 系統服務的內存預留 非k8s
–kube-reserved和–system-reserved涉及到cgroups目前還沒使用該參數
節點上可供Pod可request的資源總和allocatable計算如下：
allocatable = capacity -“ kube-reserved” - “system-reserved” - “eviction-hard”
節點上所有Pod實際使用的資源（驅逐內存包括在內）總和不會超過：
capacity - “kube-reserved” - “system-reserved”
例：只針對內存的請求舉例cpu的如法炮製，一臺node總共16G，剩餘可用內存4G，pod的實際可支配內存資源是16G-2.5G=13.5G，可供request請求資源是4G-2.5G=1.5G。
假如新發佈一個單副本的 pod ，假設目前只有一臺可調度的node節點
（1）request-memory<=1.5G，剛好可以調度到該節點，若是pod啓動之後的實際使用內存大於1.5G，則觸發驅逐，釋放資源。不然會導致該node的內存緊張，節點掛掉，該節點的容器全部不可用。
觸發驅逐的條件：
(A) kubelet 優先驅逐 BestEffort的pod和實際佔用資源大於requests的Burstable pod（在使用的pod級別）接下來驅逐實際佔用資源小於request的Burstable pod。
(B) QoS爲Guaranteed的pod最後驅逐，kubelet 會保證Guaranteed的pod 不會因爲其他pod的資源消耗而被驅逐。
© 當QoS相同時，kubelet 根據Priority計算驅逐的優先級。
我們目前使用的是一個pod裏面只有一個容器的場景所以pod級別的區分:
BestEffort：該容器沒有做任何request和limit的參數設置
Burstable：該容器設置了request和limit但是參數或值不一樣
Guaranteed：該容器設置了request和limit，參數和值都相同
（2）request-memory>1.5G pod的創建顯示內存資源不夠，該pod不能被創建，kubectl describe po 可查看是什麼資源不夠導致pod創建不了
2、後續可以優化的點
（1） 資源限制cgroups的優化，是linux內核的提供的一種機制，將資源按等級劃分，限制資源的使用，對進程分組管理，主要是針對cpu和內存的資源限制。
（2） Pod的級別的調整將重要的pod調整爲Guaranteed，可能需要的資源更多，尤其是cpu。
三deployment的參數優化
1、 jvm和request的參數值得調整
-Xms1536m -Xmx1536m
requests:
cpu: 200m
memory: 1536Mi
將jvm和request的內存值調整同一值，減少驅逐的發生