今天我們來談一下關於k8s的架構,這個觀點是從節點的角度去觀察的,也就是Node,當然早在前面我們有先提過一些,小複習:k8s的基礎架構,在這個章節,我們來詳細說下Node的架構。
節點是k8s中的工作機器,以前稱為minion。節點可以是VM或物理機,具體取決於集群。每個節點都包含運行pod所需的服務,並由主節點組件管理。節點上服務包括了容器運行時的kubelet和kube-proxy。
節點有以下4個狀態:
我們來詳細看一下
有三種定義方式:
描述節點上可用的資源:CPU,記憶體以及可以在節點上調度的最大pod數
描述有關節點的一般信息,例如內核版本,k8s版本(kubelet和kube-proxy版本),Docker版本(如果有用的話)和操作系統名稱。此信息由Kubelet從節點收集。
我們看個例子比較清楚,簡單理解就是如果狀態不是Ready就是節點有問題
還記得我們架設的minikube嗎?我們來看看他的狀態吧!
$kubectl get no
NAME STATUS ROLES AGE VERSION
minikube Ready master 171d v1.13.4
關於minikube詳細的節點訊息:
$kubectl describe no minikube
Name: minikube
Roles: master
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
hardware=high-spec
kubernetes.io/hostname=minikube
node-role.kubernetes.io/master=
Annotations: kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
node.alpha.kubernetes.io/ttl: 0
volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp: Thu, 21 Mar 2019 00:24:19 +0800
Taints: <none>
Unschedulable: false
Addresses:
InternalIP: 10.0.2.15
Hostname: minikube
Capacity:
cpu: 2
ephemeral-storage: 16888216Ki
hugepages-2Mi: 0
memory: 2038624Ki
pods: 110
Allocatable:
cpu: 2
ephemeral-storage: 15564179840
hugepages-2Mi: 0
memory: 1936224Ki
pods: 110
System Info:
Machine ID: d01d0dc5fe7c454d8961d95d66b3d1bb
System UUID: AF704AB3-A7BB-47C7-9138-D4C41EE32C87
Boot ID: bcd8de88-0b91-4a0b-a7ad-5d5bf0dcc873
Kernel Version: 4.15.0
OS Image: Buildroot 2018.05
Operating System: linux
Architecture: amd64
Container Runtime Version: docker://18.6.2
Kubelet Version: v1.13.4
Kube-Proxy Version: v1.13.4
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 755m (37%) 0 (0%)
memory 190Mi (10%) 340Mi (17%)
ephemeral-storage 0 (0%) 0 (0%)
Events: <none>
Capacity:
cpu: 2
ephemeral-storage: 16888216Ki
hugepages-2Mi: 0
memory: 2038624Ki
pods: 110
Allocatable:
cpu: 2
ephemeral-storage: 15564179840
hugepages-2Mi: 0
memory: 1936224Ki
pods: 110
值得注意的是,其中有個訊息叫做ephemeral-storage,這個參數是限制容量用的,後面管理篇會介紹
System Info:
Machine ID: d01d0dc5fe7c454d8961d95d66b3d1bb
System UUID: AF704AB3-A7BB-47C7-9138-D4C41EE32C87
Boot ID: bcd8de88-0b91-4a0b-a7ad-5d5bf0dcc873
Kernel Version: 4.15.0
OS Image: Buildroot 2018.05
Operating System: linux
Architecture: amd64
Container Runtime Version: docker://18.6.2
Kubelet Version: v1.13.4
Kube-Proxy Version: v1.13.4
試著在minikube的群集加一個節點
$vim add-node.yaml
{
"kind": "Node",
"apiVersion": "v1",
"metadata": {
"name": "192.168.10.2",
"labels": {
"name": "my-first-k8s-node"
}
}
}
用kubectl增加節點,除了用apply外,也可以用create,不過要注意兩者是有差別的,參考:kubectl中apply和create的差別
$kubectl apply -f add-node.yaml
node/192.168.10.2 created
檢查node狀態
$kubectl get no
NAME STATUS ROLES AGE VERSION
192.168.10.2 Unknown <none> 42s
minikube Ready master 171d v1.13.4
過一陣子狀態會變為
$kubectl get no
NAME STATUS ROLES AGE VERSION
192.168.10.2 NotReady <none> 4m26s
minikube Ready master 171d v1.13.4
檢查它的詳細狀態
$kubectl describe no 192.168.10.2
Name: 192.168.10.2
Roles: <none>
Labels: name=my-first-k8s-node
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Node","metadata":{"annotations":{},"labels":{"name":"my-first-k8s-node"},"name":"192.168.10.2"}}
node.alpha.kubernetes.io/ttl: 0
CreationTimestamp: Sun, 08 Sep 2019 22:47:02 +0800
Taints: node.kubernetes.io/unreachable:NoExecute
node.kubernetes.io/unreachable:NoSchedule
Unschedulable: false
Addresses:
System Info:
Machine ID:
System UUID:
Boot ID:
Kernel Version:
OS Image:
Operating System:
Architecture:
Container Runtime Version:
Kubelet Version:
Kube-Proxy Version:
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 0 (0%) 0 (0%)
memory 0 (0%) 0 (0%)
ephemeral-storage 0 (0%) 0 (0%)
Events: <none>
通常這樣的狀態是設置不全造成的,因為我們區網內並沒有這台機器,所以這種情況我們應該先暫時將它不列入排程中
將該節點從排程移除
$kubectl cordon 192.168.10.2
node/192.168.10.2 cordoned
我們來看看現在群集的所有節點狀態
$kubectl get no
NAME STATUS ROLES AGE VERSION
192.168.10.2 NotReady,SchedulingDisabled <none> 10m
minikube Ready master 171d v1.13.4
接著若機器設置妥當,我們就可以將它重新加入排程
$kubectl uncordon 192.168.10.2
node/192.168.10.2 uncordoned
反之,若是要棄用該節點的話,我們可以這麼做
$kubectl delete -f add-node.yaml
node "192.168.10.2" deleted
這邊我們其實也可以用kubectl delete no 192.168.10.2去刪除它,這種情況下是沒有差別的,不過在某些情況下,前者的方式是比較好的,因為YAML定義了整個架構,刪除的時候會把全部相關的一起刪掉,後面管理篇會詳細介紹。
今天我們理解了什麼是節點,並詳加介紹了它本身的特性及操作方式,關於節點其實還有些更細緻的操作,不過截至目前為止我們已經知道它是跟群集比較接近的範疇,部署好後大多的情況是不太需要更動的,除非是定期維護的時候就另當別論,當然這邊為了區分方便,我們就把Node稱作Slave,這是為了和主節點區分,也就是Master,避免混淆,我們來看張架構圖:
其中在群集與Master的溝通是以apiserver作為通信的,當apiserver需要獲得Slave的資訊時,它會向Slave上的kubelet詢問。
這個cloud是指雲端,雲端上的k8s建置會用到CCM(Cloud Controller Manager),這個部分會在後續k8s架設在雲端的實作部分作(EKS)介紹。敬請期待!我們明天見!!
本文同步刊載於https://github.com/x1y2z3456/ironman
感謝您撥冗閱讀此文章,不喜勿噴,有任何問題建議歡迎下方留言:)
說個笑話,希望我能寫滿30天啊(笑