[k8s]k8s的控制層kubelet+docker配合調度機制(k8架構)

意外停掉一臺node的kubelet,發現調度有問題,研究了下調度的細節

k8s架構

控制層- kubelet(配合節點docker工做)

數據層- kube-proxy

邏輯圖:

object

參考: https://kubernetes.io/docs/concepts/#

各個組件各司其職

參考: http://www.cnblogs.com/jianyuan/p/5063530.html

pod rc svc之間的關係

參考: 啓動一個簡單的集羣: tomcat+mysql

測試pod調度

停掉n1的kubelet,等幾min後
kubectl get node 顯示n1 not ready
在等幾min後
kubectl get no -o wide AGE字段顯示unkown.
在等幾min.
發現開始調度了,調度結果

注: 調度完成後即便掛掉的n1起來,pod也不會從新迴歸了.

在跑道n1上去看,之前老的容器依舊running,待下次啓動kubelet後,這些容器立馬被kubelet幹掉.
這是n1啓動後kubelet的日誌

出現的問題: kubelet和docker很差好配合,致使kubelet掛掉後沒法調度.沒查清楚什麼問題

難道是內核和docker兼容問題? 不得而知,已上嘗試調度好幾回,有一次出現這個問題
參考:
https://docs.docker.com/engine/userguide/storagedriver/selectadriver/#docker-ee-and-cs-engine
http://blog.csdn.net/styshoo/article/details/60715942

爲了給Docker配置overlay存儲驅動，你的Docker host必須運行在Linux kernel3.18版本之上，並且加載了overlay內核驅動。對於overlay2驅動，kernel版本必須在4.0或以上。OverlayFS能夠運行在大多數Linux文件系統之上。不過，如今最建議在生產環境中使用ext4。

kube api-versions不一樣版本對比

參考: https://www.youtube.com/watch?v=bMiU4xH8pLw&t=1862s

[k8架構]k8s架構及調度機制圖解參考
http://www.cnblogs.com/iiiiher/p/8043444.html

$ kubectl api-versions
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1beta1
apps/v1beta1
authentication.k8s.io/v1
authentication.k8s.io/v1beta1
authorization.k8s.io/v1
authorization.k8s.io/v1beta1
autoscaling/v1
batch/v1
bitnami.com/v1alpha1
certificates.k8s.io/v1beta1
extensions/v1beta1
k8s.io/v1
networking.k8s.io/v1
policy/v1beta1
rbac.authorization.k8s.io/v1alpha1
rbac.authorization.k8s.io/v1beta1
settings.k8s.io/v1alpha1
storage.k8s.io/v1
storage.k8s.io/v1beta1
v1

node掛了後到底多久會notready 多久開始調度? 40s判死刑,緩期5min善後

參考: https://kubernetes.io/docs/reference/generated/kube-controller-manager/
參考: 崔秀龍的博客: http://blog.fleeto.us/content/node-chong-shang-zhi-hou

注: 這個由kube-controller-manager的兩個參數決定的

--pod-eviction-timeout：缺省爲 5m，五分鐘，在 Pod 驅逐行爲的超時時間。
--node-monitor-grace-period：缺省爲 40s，也就是 40 秒，無響應 Node 在標記爲 NotReady 以前的等候時間。


--pod-eviction-timeout duration                                     The grace period for deleting pods on failed nodes. (default 5m0s)
--node-monitor-grace-period duration                                Amount of time which we allow running Node to be unresponsive before marking it unhealthy. Must be N times more than kubelet's nodeStatusUpdateFrequency, where N means number of retries allowed for kubelet to post node status. (default 40s)

exit狀態的pod超過多少會觸發gc

--terminated-pod-gc-threshold=12500 #默認,exit狀態的pod回收閥值

監控
參考: 崔秀龍的博客: http://blog.fleeto.us/content/node-chong-shang-zhi-hou

--healthz-bind-address：健康監測地址，缺省爲127.0.0.1。
--healthz-port：健康檢測端口，缺省爲 10248。
curl 訪問該地址，會獲得響應：ok。

另外若是使用kube-metrics exporter進行集羣監控，能夠關注 RC、Deploy 等對象的可用實例數量。

實現節點禁止調度

kubectl uncordon my-node                                              # Mark my-node as schedulable
kubectl cordon my-node

Kubernetes系統常見運維技巧