Kubernetes筆記 (2) - 資源對象、kubectl

Kubernetes叢集将所有節點上的資源都整合到一個大的虛拟資源池裡，以代替一個個單獨的伺服器。如果把叢集類比為一台傳統的伺服器，那麼Kubernetes（Master）就好比是作業系統核心，其主要職責在于抽象資源并排程任務，而Pod資源對象就是那些運作于使用者空間中的程序。

API Server提供了RESTful風格的程式設計接口，其管理的資源是Kubernetes API中的端點，用于存儲某種API對象的集合。Pod、Deployment和Service等都是最常用的核心對象。

Pod資源對象是一種集合了一到多個應用容器、存儲資源、專用IP及支撐容器運作的其他選項的邏輯元件，是Kubernetes的部署單元及原子運作單元。

Kubernetes的網絡模型要求其各Pod對象的IP位址位于同一網絡平面内（同一IP網段），可以将每個Pod對象想象成一個邏輯主機，類似正常的實體主機或VM，運作于同一個Pod對象中的多個程序也類似于實體機或VM上獨立運作的程序。

不過，Pod對象中的各程序均運作于彼此隔離的容器中，并于各容器間共享兩種關鍵資源：網絡和存儲卷

網絡：每個Pod對象都會被配置設定一個叢集内專用的IP位址（PodIP），同一Pod内部的所有容器共享Pod對象的主機名、IP位址和端口等。是以，這些容器間可以通過本地回環位址進行通信。

存儲卷：還為Pod對象配置一組“存儲卷”資源，這些資源可以共享給其内部的所有容器使用。

一個Pod對象代表某個應用程式的一個特定執行個體，如果需要擴充應用程式，就可以通過為此應用程式建立多個Pod執行個體來實作。

在工作節點甚至是排程器自身導緻了運作失敗時，Pod對象将會被删除；同樣，資源耗盡或節點故障導緻的回收操作也會删除相關的Pod對象。

Kubernetes使用Controller實作對一次性的（用後即棄）Pod對象的管理操作，例如，要確定部署的應用程式的Pod副本數量符合使用者的設定，以及基于Pod模闆來重建Pod對象等，進而實作Pod對象的擴縮容、滾動更新和自愈能力等。

Controller本身也是一種資源類型，它有着多種實作，其中與工作負載相關的實作如：

ReplicationController

Deployment

StatefulSet

DaemonSet

Jobs

也可統稱它們為Pod控制器，控制器的定義通常由期望的副本數量、Pod模闆和标簽選擇器（Label Selector）組成。它會根據标簽選擇器對Pod對象的标簽進行比對檢查，所有滿足選擇條件的Pod對象都将受控于目前控制器并計入其副本總數，并確定此數目能夠精确反映期望的副本數。

需要注意的是：在實際的應用場景中，在接收到的請求流量負載顯著低于或接近于已有Pod副本的整體承載能力時，使用者需要手動修改Pod控制器中的期望副本數量以實作應用規模的擴容或縮容。不過，若叢集中部署了HeapSter或Prometheus一類的資源名額監控附件時，使用者還可以使用“HorizontalPodAutoscaler”（HPA）計算出合适的Pod副本數量，并自動修改Pod控制器中期望的副本數以實作應用規模的動态伸縮，提高叢集資源使用率。

Service主要有三種常用類型：

僅用于叢集内部通信的ClusterIP類型

接入叢集外部請求的NodePort類型

LoadBalancer類型

Pod對象重新開機或被重建後IP位址通常會發生變化，Service資源對象的作用便是在被通路的Pod對象與用戶端之間添加一個有着固定IP位址的中間層，用戶端向此位址發起通路請求後，相關的Service資源會負責将請求排程并代理至後端的Pod對象。Service IP是一種虛拟IP，也稱為Cluster IP，它專用于叢集内通信。

Service是“微服務”的一種實作，事實上它是一種抽象：通過規則定義出由多個Pod對象組合而成的邏輯集合，并附帶通路這組Pod對象的政策。Service對象挑選、關聯Pod對象的方式同Pod控制器一樣，都是要基于Label Selector進行。

ClusterIP僅對叢集内部開放，外部通路叢集可通過NodePort，根據某個Node的IP和端口（NodePort）接入請求，并将其代理至相應的Service對象的Cluster IP上的服務端口，而後由Service對象将請求代理至後端的Pod對象的PodIP及應用程式監聽的端口。這種請求需要經過兩次轉發。

NodePort會部署于叢集中的每一個節點，隻能通路到指定Node上的Service，如果存在叢集外部的LoadBalancer，即可将使用者請求負載均衡至叢集中的部分或者所有節點。LoadBalancer通常是由Cloud Provider自動建立并提供的軟體負載均衡器，也可以是由管理者手工配置的硬體裝置。

容器技術使得部署程式時不再需要直接更改主機環境，而K8S又使得建立和運作容器的操作不必再關注其主機位置，并在一定程度上賦予了它動态擴縮容及自愈的能力，進而讓使用者從主機、系統及應用程式的維護工作中解脫出來。

部署某個應用程式時，使用者首先要向API Server請求建立一個Pod控制器，由控制器根據鏡像等資訊向API Server請求建立出一定數量的Pod對象，并由Master之上的排程器指派至標明的工作節點以運作容器化應用。此外，使用者一般還需要建立一個具體的Service對象以便為這些Pod對象建立起一個固定的通路入口，進而使得其用戶端能夠通過其服務名稱或ClusterIP進行通路。

API Server的用戶端工具有kubectl和Dashboard。

Kubernetes API（API Server）是管理其各種資源對象的唯一入口，它提供了一個RESTful風格的CRUD（Create、Read、Update和Delete）接口用于查詢和修改叢集狀态，并将結果存儲于叢集狀态存儲系統etcd中。

使用者可以通過kubectl通路API Server來操作Kubernetes的各種資源對象。

建立資源對象

這樣的指令建立了一個名為nginx-deploy的deployment控制器資源，然後由這個資源來根據指定的鏡像名稱、副本數量來負責pod的建立。

檢視資源對象

<code>kubectl get</code>指令用于檢視資源對象

Kubernetes系統的大部分資源都隸屬于某個Namespace對象，預設的名稱空間為default，若需要擷取指定Namespace對象中的資源對象的資訊，則需要使用-n或--namespace指明其名稱

列印資源對象的詳細資訊

<code>kubectl get -o {yaml|josn}</code>或<code>kubectl describe</code>指令都能夠列印出指定資源對象的較長的描述資訊.

<code>kubectl get -o {yaml|josn}</code>可以檢視資源對象的使用者期望狀态（Spec）和現有的實際狀态（Status），比如檢視default namespaces下所有pods的狀态資訊并輸出為yaml格式：

<code>kubectl describe</code>指令可以顯示資源的event、controller等資訊。

列印容器中的日志資訊

指令格式為：

可列印指定Pod内指定容器的日志，如果Pod内隻有一個容器，則容器名可省略，-f可用于持續監控日志輸出。

在容器中執行指令

删除資源對象

<code>kubectl delete</code>指令可以删除資源對象，但對于受控于控制器的對象來說，删除之後其控制器可能會重建出類似的對象，例如，Deployment控制器下的Pod對象在被删除時就會被重建。

有些資源類型（如Pod），支援優雅删除的機制，它們有着預設的删除寬限期，可以在指令中使用--grace-period選項或--now選項來覆寫預設的寬限期。

《Kubernetes實戰進階》 馬永亮著