iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 5
0
DevOps

Kubernetes的30天養成計劃系列 第 5

[Day5] 淺談k8s架構之一:Node是什麼?Master與Slave有何不同?

前言

今天我們來談一下關於k8s的架構,這個觀點是從節點的角度去觀察的,也就是Node,當然早在前面我們有先提過一些,小複習:k8s的基礎架構,在這個章節,我們來詳細說下Node的架構。

Node是什麼?

節點是k8s中的工作機器,以前稱為minion。節點可以是VM或物理機,具體取決於集群。每個節點都包含運行pod所需的服務,並由主節點組件管理。節點上服務包括了容器運行時的kubelet和kube-proxy。

Node的狀態

節點有以下4個狀態:

  • Addresses(地址)
  • Conditon(節點狀態)
  • Capacity and Allocatable(容量和可分配量)
  • Info(詳細資訊)

我們來詳細看一下

地址

有三種定義方式:

  • HostName(本機名稱): 節點內核報告的主機名
  • ExternalIP(外部IP): 可從外部連線的節點的IP地址(可從群集外部獲得)。
  • InternalIP(內網IP): 僅在群集內可連線的節點的IP地址。

節點狀態

https://ithelp.ithome.com.tw/upload/images/20190920/20120468P6sG8kcRKH.png

容量和可分配量

描述節點上可用的資源: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

Node管理初體驗

試著在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,避免混淆,我們來看張架構圖:

https://ithelp.ithome.com.tw/upload/images/20190920/20120468NrnLOHJaJz.png

Master是由etcd、kube-controller manager、kube-apiserver、kubescheduler構成

Slave是由kubelet、kube-proxy構成

其中在群集與Master的溝通是以apiserver作為通信的,當apiserver需要獲得Slave的資訊時,它會向Slave上的kubelet詢問。

這個cloud是指雲端,雲端上的k8s建置會用到CCM(Cloud Controller Manager),這個部分會在後續k8s架設在雲端的實作部分作(EKS)介紹。敬請期待!我們明天見!!

參考資料

本文同步刊載於https://github.com/x1y2z3456/ironman

感謝您撥冗閱讀此文章,不喜勿噴,有任何問題建議歡迎下方留言:)

說個笑話,希望我能寫滿30天啊(笑


上一篇
[Day4] 碼頭工的日常與舵手的逆襲:Docker與k8s常用指令集比較
下一篇
[Day6] 淺談k8s架構之二:什麼是Object?什麼是Abstraction?有何不同?
系列文
Kubernetes的30天養成計劃30

尚未有邦友留言

立即登入留言