iT邦幫忙

第 11 屆 iThome 鐵人賽
DAY 5
1
DevOps

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

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

11th鐵人賽
6746 瀏覽

  • 分享至 

  • xImage
    •  

前言

今天我們來談一下關於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

Ｍaster是由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 篇
  1. 26
    [Day26] k8s管理篇延伸與EKS（二）：Resource Quota、Namespace、RBAC
  2. 27
    [Day27] k8s應用篇（一）：Helm部署apps、HPA和CA
  3. 28
    [Day28] k8s應用篇（二）：EBS和EFS的使用
  4. 29
    [Day29] k8s集群篇：HA、Federation
  5. 30
    [Day30] k8s總結：架構整合、圖表整理
完整目錄
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言
iThome鐵人賽
參賽組數
1064 組
團體組數
40 組
累計文章數
22205 篇
完賽人數
602 人
iT+看影片追技術 看影片追技術 看更多
熱門tag 看更多
15th鐵人賽 16th鐵人賽 13th鐵人賽 14th鐵人賽 12th鐵人賽 11th鐵人賽 鐵人賽 2019鐵人賽 javascript 2018鐵人賽 python 2017鐵人賽 windows php c# windows server linux css react vue.js
熱門問題
熱門回答
熱門文章
IT邦幫忙