13-Architecture-nodes

/concepts/architecture/nodes/

node是kubernetes中的工作機，以前稱為“minion”`. 可以是虛擬機器或物理機，具體取決於叢集。每個節點包含執行pods 所需的服務，並由master管理。

node上的服務包括容器環境-符合CRI標準-container runtime,kubelet和kube-proxy。請參閱架構設計文件中的The Kubernetes Node 一節以瞭解更多詳細資訊。

Node Status

節點的狀態包含以下資訊：

可以使用以下命令顯示節點狀態和有關節點的其他詳細資訊：

kubectl describe node <insert-node-name-here>

下面將詳細介紹每個部分。

Addresses

這些欄位的使用取決於雲提供商或裸機配置.

HostName: 需要自定義主機名. 在 kubelet 啟動前--hostname-override引數指定主機名覆蓋系統預設主機名.
ExternalIP: Typically the IP address of the node that is externally routable (available from outside the cluster).外網也可以訪問的ip
InternalIP: 通常是隻能在叢集內路由的節點的IP地址.

Conditions

Conditions 欄位描述節點 Running 狀態. 有以下幾種狀態:

Node Condition	Description
`OutOfDisk`	`True` if there is insufficient free space on the node for adding new pods, otherwise `False`, 如果磁碟空間不夠新增新的pod則為`True`, 正常情況是`False`
`Ready`	`True` if the node is healthy and ready to accept pods, `False` if the node is not healthy and is not accepting pods, and `Unknown` if the node controller has not heard from the node in the last `node-monitor-grace-period` (default is 40 seconds), 1.如果節點正常且接受pod執行則為`True`,2.如果不能接受pod執行則為`False`,3.在指定時間內Master(`Node控制器`)接收不到node上報狀態資訊則為`Unknown`
`MemoryPressure`	執行記憶體不足則為`True`, 否則是`False`
`PIDPressure`	`True` if pressure exists on the processes – that is, if there are too many processes on the node; otherwise `False` 執行的程式過多則為`True`,否則為`False`
`DiskPressure`	`True` if pressure exists on the disk size – that is, if the disk capacity is low; otherwise `False`如果磁碟大小存在壓力)即磁碟容量低)，則為true；否則為false
`NetworkUnavailable`	`True` if the network for the node is not correctly configured, otherwise False`` true如果節點的網路配置不正確，則為false`

nodeconditions表示為json物件。例如，下面的響應描述一個正常的節點。

"conditions": [
  {
    "type": "Ready",
    "status": "True",
    "reason": "KubeletReady",
    "message": "kubelet is posting ready status",
    "lastHeartbeatTime": "2019-06-05T18:38:35Z",
    "lastTransitionTime": "2019-06-05T11:41:27Z"
  }
]

如果就緒條件的狀態保持Unknown或False的時間超過pod-eviction-timeoutpod逐出超時時間, 引數被傳遞給kube controller manager ，節點上的所有pod都被節點控制器計劃刪除。預設逐出超時持續時間為5分鐘。在某些情況下，當無法訪問節點時，APIServer無法與node上的kubelet通訊。在與APIServer重新建立通訊之前，無法將刪除pod的決定傳達給Kubelet。同時，計劃刪除的pod可以繼續在分割槽節點上執行。

(node失聯(異常關機,或者kubelet程式異常退出, 執行於此node上的pods並不會被驅逐到新的node上, 且不會更新pods狀態一直認為其是正常執行))

In versions of Kubernetes prior to 1.5, the node controller would force delete these unreachable pods from the apiserver. However, in 1.5 and higher, the node controller does not force delete pods until it is confirmed that they have stopped running in the cluster. You can see the pods that might be running on an unreachable node as being in the Terminating or Unknown state. In cases where Kubernetes cannot deduce from the underlying infrastructure if a node has permanently left a cluster, the cluster administrator may need to delete the node object by hand. Deleting the node object from Kubernetes causes all the Pod objects running on the node to be deleted from the apiserver, and frees up their names.在1.5之前的kubernetes版本中，節點控制器將強制從apiserver中刪除這些無法訪問的pod。但是，在1.5和更高版本中，節點控制器不會強制刪除pod，直到確認它們已停止在叢集中執行。您可以看到可能正在無法訪問的節點上執行的pod處於終止或未知狀態。在kubernetes無法從底層基礎設施推斷節點是否永久離開叢集的情況下，叢集管理員可能需要手動刪除節點物件。從kubernetes中刪除node物件會導致從apiserver中刪除節點上執行的所有pod物件，並釋放它們的名稱。

In version 1.12, TaintNodesByCondition feature is promoted to beta, so node lifecycle controller automatically creates taints that represent conditions. Similarly the scheduler ignores conditions when considering a Node; instead it looks at the Node’s taints and a Pod’s tolerations.在版本1.12中，TaintNodesByCondition特性被提升為beta版，因此節點生命週期控制器會自動建立表示條件的taints。類似地，排程器在考慮一個節點時會忽略條件；相反，它會檢視節點的汙點和pod的容忍度。

Now users can choose between the old scheduling model and a new, more flexible scheduling model. A Pod that does not have any tolerations gets scheduled according to the old model. But a Pod that tolerates the taints of a particular Node can be scheduled on that Node.現在使用者可以在舊的排程模型和新的、更靈活的排程模型之間進行選擇。一個沒有任何耐受性的pod將根據舊模型進行排程。但是一個能夠容忍特定節點汙染的pod可以在該節點上排程。

Caution: Enabling this feature creates a small delay between the time when a condition is observed and when a taint is created. This delay is usually less than one second, but it can increase the number of Pods that are successfully scheduled but rejected by the kubelet.啟用此功能將在觀察到條件和建立汙點之間建立一個小延遲。這種延遲通常小於1秒，但它可以增加成功排程但被kubelet拒絕的吊艙數量。

Capacity and Allocatable容量和可分配

Capacity:
 cpu:                2
 ephemeral-storage:  51175Mi
 hugepages-2Mi:      0
 memory:             4045652Ki
 pods:               110
Allocatable:
 cpu:                2
 ephemeral-storage:  48294789041
 hugepages-2Mi:      0
 memory:             3943252Ki
 pods:               110

描述節點上可用的資源：CPU、記憶體和可排程到節點上的最大pod數量

Capacity欄位描述當前節點的資源總量, Allocatable欄位表示最多可分配的資源總量

在學習如何在節點上資源保留reserve compute resources 您可以閱讀更多有關容量和可分配資源的資訊。

Info

System Info:
 Machine ID:                 7138b458771f48e99760b4a14e10e7ad
 System UUID:                423677FD-9A2E-A62D-7F4A-0A8390F257E7
 Boot ID:                    835eec1e-cd1c-4830-b0e9-015569f5f09d
 Kernel Version:             3.10.0-957.21.3.el7.x86_64
 OS Image:                   CentOS Linux 7 (Core)
 Operating System:           linux
 Architecture:               amd64
 Container Runtime Version:  docker://19.3.1
 Kubelet Version:            v1.15.4
 Kube-Proxy Version:         v1.15.4

Describes general information about the node, such as kernel version, Kubernetes version (kubelet and kube-proxy version), Docker version (if used), and OS name. This information is gathered by Kubelet from the node. 描述有關節點的一般資訊，例如核心版本、kubernetes版本)kubelet和kube代理版本)、docker版本)如果使用)和os名稱。此資訊由kubelet從節點收集。

Management

與pods 和services不同, 節點不是由k8s叢集建立的, : 而是由雲服務商例如Google Compute Engine, 在外部建立的，或者它存在於物理或虛擬機器池中kubelet, kube-proxy, docker是使用者自行安裝.因此，當kubernetes建立一個節點時，它會建立一個表示該節點的物件。建立後，kubernetes檢查節點是否有效。例如，如果嘗試從以下內容建立節點：

{
  "kind": "Node",
  "apiVersion": "v1",
  "metadata": {
    "name": "10.240.79.157",
    "labels": {
      "name": "my-first-k8s-node"
    }
  }
}

kubernetes在內部建立一個節點物件)表示)，並基於metadata.name欄位通過執行狀況檢查來驗證節點。如果節點有效)也就是說，如果所有必要的服務都在執行)，那麼它就有資格執行pod。否則，任何群集活動都將忽略它，直到它變為有效。

Note: kubernetes保留無效節點的物件，並不斷檢查它是否有效。必須顯式刪除節點物件才能停止此程式。

Currently, there are three components that interact with the Kubernetes node interface: node controller, kubelet, and kubectl.目前，有三個元件與kubernetes節點介面互動：node controller、kubelet和kubectl。

Node Controller

節點控制器(node controller)是一個kubernetes Master元件，它管理nodes的各個方面。

節點控制器在節點的生命週期中有多個角色。

第一種是在註冊節點時將cidr塊分配給該節點)如果啟用了cidr分配)分配網段

第二是讓節點控制器的內部節點列表與雲提供商的可用計算機列表保持最新。在雲環境中執行時，每當節點不正常時，節點控制器會詢問雲提供商該節點的虛擬機器是否仍然可用。否則，節點控制器將從其節點列表中刪除該節點。節點存活探測

第三是監測節點的健康狀況。節點控制器負責在節點變得不可訪問時將NodeStatus的NodeReady條件更新為ConditionUnknown)即節點控制器由於某些原因停止接收心跳訊號，例如由於節點關閉)，然後從節點中逐出所有pod)使用正常終止)如果節點仍然無法訪問。)預設超時為40秒以開始報告未知條件，5秒後開始逐出pod。)節點控制器通過此設定--node-monitor-period可以修改檢查週期秒為單位

在1.13之前的kubernetes版本中，nodestatus是來自節點的心跳。從kubernetes 1.13開始，node lease特性作為alpha特性引入(feature gate NodeLease, KEP-0009).啟用節點租用功能後，每個節點在kube-node-lease名稱空間中都有一個關聯的租用物件(Lease)，該物件由節點定期更新，NodeStatus和node lease都被視為來自節點的心跳。當nodestatus從一個節點報告到主節點時，只有在發生了一些更改或經過了足夠的時間)預設值為1分鐘，比無法訪問的節點的預設超時40秒長)，節點租約才會頻繁地更新。由於node lease比nodestatus輕量級得多，因此從可伸縮性和效能角度來看，此功能使node heartbeat顯著降低。簡而言之由節點上報資訊自動更新節點狀態資訊而不是心跳檢查, 如果超出租約時間不續租會觸發一個事件,k8smaster會做出相對應的操作

在kubernetes 1.4中，我們更新了節點控制器的邏輯，以便更好地處理大量節點在到達主節點時出現問題)例如，因為主節點有網路問題)的情況。從1.4開始，節點控制器在決定pod退出時檢視叢集中所有節點的狀態。

在大多數情況下，節點控制器將逐出速率限制為--node-eviction-rate)預設為0.1)每秒，這意味著它不會每10秒逐出超過1個節點的pod。

當給定可用性區域中的節點變得不正常時，節點逐出行為將更改。節點控制器同時檢查區域中不正常節點的百分比)NodeReady條件為ConditionUnknown或ConditionFalse)。如果不正常節點的部分至少為不正常區域閾值--unhealthy-zone-threshold)預設值為0.55)，則逐出率會降低：如果群集較小)即小於或等於-大型群集大小閾值節點---large-cluster-size-threshold預設值為50)，則逐出將停止，否則逐出率將降低到--次節點逐出率--secondary-node-eviction-rate )預設為0.01)每秒。每個可用性區域實現這些策略的原因是，一個可用性區域可能從主區域分割槽，而其他可用性區域則保持連線。如果叢集不跨越多個雲提供商可用性區域，則只有一個可用性區域)整個叢集)。

將節點分散到可用性區域的一個關鍵原因是，當一個完整的區域關閉時，工作負載可以轉移到正常區域。因此，如果一個區域中的所有節點都不正常，則節點控制器將以正常速率“節點逐出速率--node-eviction-rate”逐出。最糟糕的情況是所有區域都完全不正常)即叢集中沒有正常的節點)。在這種情況下，節點控制器假設主連線有問題，並停止所有收回操作，直到恢復某些連線。(不要把雞蛋放在一個籃子裡)

從kubernetes 1.6開始，NodeController還負責清除在帶有NoExecute 汙染的節點上執行的pod，而這些pod不能容忍這些汙染。此外，作為預設禁用的alpha特性，NodeController負責新增與節點問題)如節點不可訪問或未就緒)對應的汙點。請參閱本文件瞭解有關NoExecute 汙染和alpha特性的詳細資訊。

從版本1.8開始，節點控制器可以負責建立表示節點條件的汙點。這是1.8版的alpha特性。

Self-Registration of Nodes節點自注冊

# 啟動示例
/usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.1

當kubelet啟動新增引數 --register-node為true)預設值)時，kubelet將嘗試向api伺服器註冊自己。這是大多數發行版使用的首選模式。

對於自注冊，kubelet從以下選項開始：

--kubeconfig - 用於向APIServer驗證自身的憑據的路徑。
--cloud-provider - How to talk to a cloud provider to read metadata about itself.如何與雲提供商交談以讀取有關其自身的後設資料。
--register-node - Automatically register with the API server.自動註冊到API伺服器。
--register-with-taints - Register the node with the given list of taints (comma separated <key>=<value>:<effect>). No-op if register-node is false.使用給定的汙點列表)逗號分隔的“=：`”)註冊節點。如果“register node”為false，則不執行操作。
--node-ip - IP address of the node.
--node-labels - 在群集中註冊節點時要新增的標籤(請參閱1.13+中由[noderestriction admission plugin執行的標籤限制](https://kubernetes.io/docs/reference/acces... authn authz/admission controllers/noderestriction))。
--node-status-update-frequency - Specifies how often kubelet posts node status to master.指定kubelet向master傳送節點狀態的頻率。

當啟用節點授權模式(Node authorization mode)和noderestriction許可外掛(NodeRestriction admission plugin )時，kubelets只被授權建立/修改自己的節點資源。

Manual Node Administration手動節點管理

群集管理器可以建立和修改節點物件。

如果管理員希望手動建立節點物件，請在kubelet啟動前設定 --register-node=false.

管理員可以修改節點資源)不考慮--register-node的設定)。修改包括在節點上設定標籤並將其標記為不可排程。

節點上的標籤可以與pod上的節點選擇器一起使用，以控制排程，例如，將pod限制為僅能在節點的子集上執行。

將節點標記為不可排程可防止將新的pod排程到該節點，但不會影響節點上的任何現有pod。這對於節點重新啟動前的準備步驟非常有用。例如，要將節點標記為不可排程，請執行以下命令：

kubectl cordon $NODENAME

Note: Pods created by a DaemonSet controller bypass the Kubernetes scheduler and do not respect the unschedulable attribute on a node. This assumes that daemons belong on the machine even if it is being drained of applications while it prepares for a reboot.由於DaemonSet程式控制器建立的pod繞過kubernetes排程程式，忽略節點上的unschedulable屬性。這假設守護程式屬於計算機，即使它在準備重新啟動時正在耗盡應用程式即使屬於節點上關鍵程式,直至重啟它都不會被驅逐。

Node capacity節點容量

節點的容量)CPU數量和記憶體量)是節點物件的一部分。通常，節點在建立節點物件時會註冊自己並報告其容量。如果正在執行手動節點管理，則在新增節點時需要設定節點容量。

kubernetes排程程式確保節點上的所有pod都有足夠的資源。它檢查節點上容器的請求總數是否不大於節點容量。它包括由kubelet啟動的所有容器，但不包括由[容器執行時](https://kubernetes.io/docs/concepts/overvi... components)直接啟動的容器，也不包括在容器外部執行的任何程式。只關注kubelet啟動的pod中包含的容器

如果要顯式地為非pod程式保留資源，請按照本教程的說明[為系統守護程式保留資源](https://kubernetes.io/docs/tasks/administr... cluster/reserve compute resources/system reserved)。

Node topology節點拓撲

功能狀態：kubernetes v1.16alpha
如果啟用了“拓撲管理器”[功能門](https://kubernetes.io/docs/reference/comma... line tools reference/feature gates/)，那麼kubelet可以在做出資源分配決策時使用拓撲提示。

API Object

node是Kubernetes REST API中的頂級資源。有關api物件的更多詳細資訊，請參見：Node API object.

What's next

Read about node components
瞭解節點級拓撲：控制節點上的拓撲管理策略

本作品採用《CC 協議》，轉載必須註明作者和本文連結