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

Kubernetes集羣將全部節點上的資源都整合到一個大的虛擬資源池裏，以代替一個個單獨的服務器。若是把集羣類比爲一臺傳統的服務器，那麼Kubernetes（Master）就比如是操做系統內核，其主要職責在於抽象資源並調度任務，而Pod資源對象就是那些運行於用戶空間中的進程。

資源對象

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

Pod資源對象

Pod資源對象是一種集合了一到多個應用容器、存儲資源、專用IP及支撐容器運行的其餘選項的邏輯組件，是Kubernetes的部署單元及原子運行單元。
Kubernetes的網絡模型要求其各Pod對象的IP地址位於同一網絡平面內（同一IP網段），能夠將每一個Pod對象想象成一個邏輯主機，相似常規的物理主機或VM，運行於同一個Pod對象中的多個進程也相似於物理機或VM上獨立運行的進程。
不過，Pod對象中的各進程均運行於彼此隔離的容器中，並於各容器間共享兩種關鍵資源：網絡和存儲卷

• 網絡：每一個Pod對象都會被分配一個集羣內專用的IP地址（PodIP），同一Pod內部的全部容器共享Pod對象的主機名、IP地址和端口等。所以，這些容器間能夠經過本地迴環地址進行通訊。
• 存儲卷：還爲Pod對象配置一組「存儲卷」資源，這些資源能夠共享給其內部的全部容器使用。

一個Pod對象表明某個應用程序的一個特定實例，若是須要擴展應用程序，就能夠經過爲此應用程序建立多個Pod實例來實現。

Controller資源對象

在工做節點甚至是調度器自身致使了運行失敗時，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資源對象

Service主要有三種經常使用類型：

1. 僅用於集羣內部通訊的ClusterIP類型
2. 接入集羣外部請求的NodePort類型
3. LoadBalancer類型

僅用於集羣內部通訊的ClusterIP類型

Pod對象重啓或被重建後IP地址一般會發生變化，Service資源對象的做用即是在被訪問的Pod對象與客戶端之間添加一個有着固定IP地址的中間層，客戶端向此地址發起訪問請求後，相關的Service資源會負責將請求調度並代理至後端的Pod對象。Service IP是一種虛擬IP，也稱爲Cluster IP，它專用於集羣內通訊。

Service是「微服務」的一種實現，事實上它是一種抽象：經過規則定義出由多個Pod對象組合而成的邏輯集合，並附帶訪問這組Pod對象的策略。Service對象挑選、關聯Pod對象的方式同Pod控制器同樣，都是要基於Label Selector進行。

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

ClusterIP僅對集羣內部開放，外部訪問集羣可經過NodePort，根據某個Node的IP和端口（NodePort）接入請求，並將其代理至相應的Service對象的Cluster IP上的服務端口，然後由Service對象將請求代理至後端的Pod對象的PodIP及應用程序監聽的端口。這種請求須要通過兩次轉發。

LoadBalancer類型

NodePort會部署於集羣中的每個節點，只能訪問到指定Node上的Service，若是存在集羣外部的LoadBalancer，便可將用戶請求負載均衡至集羣中的部分或者全部節點。LoadBalancer一般是由Cloud Provider自動建立並提供的軟件負載均衡器，也能夠是由管理員手工配置的硬件設備。

K8S部署應用程序的基本過程

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

部署某個應用程序時，用戶首先要向API Server請求建立一個Pod控制器，由控制器根據鏡像等信息向API Server請求建立出必定數量的Pod對象，並由Master之上的調度器指派至選定的工做節點以運行容器化應用。此外，用戶通常還須要建立一個具體的Service對象以便爲這些Pod對象創建起一個固定的訪問入口，從而使得其客戶端可以經過其服務名稱或ClusterIP進行訪問。
API Server的客戶端工具備kubectl和Dashboard。

kubectl的基礎使用

Kubernetes API（API Server）是管理其各類資源對象的惟一入口，它提供了一個RESTful風格的CRUD（Create、Read、Update和Delete）接口用於查詢和修改集羣狀態，並將結果存儲於集羣狀態存儲系統etcd中。
用戶能夠經過kubectl訪問API Server來操做Kubernetes的各類資源對象。

建立資源對象

kubectl run nginx-deploy --image=nginx:1.12 --replicas=1

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

查看資源對象
kubectl get命令用於查看資源對象

~ kubectl get namespaces
NAME              STATUS   AGE
default           Active   23h
kube-node-lease   Active   23h
kube-public       Active   23h
kube-system       Active   23h

~ kubectl get pods
NAME           READY   STATUS    RESTARTS   AGE
myapp          1/1     Running   0          14h
nginx-deploy   1/1     Running   0          14h

Kubernetes系統的大部分資源都隸屬於某個Namespace對象，缺省的名稱空間爲default，若須要獲取指定Namespace對象中的資源對象的信息，則須要使用-n或--namespace指明其名稱

打印資源對象的詳細信息
kubectl get -o {yaml|josn}或kubectl describe命令都可以打印出指定資源對象的詳細描述信息.
kubectl get -o {yaml|josn}能夠查看資源對象的用戶指望狀態（Spec）和現有的實際狀態（Status），好比查看default namespaces下全部pods的狀態信息並輸出爲yaml格式：

~ kubectl get pods -n default -o yaml

kubectl describe命令能夠顯示資源的event、controller等信息。

~ kubectl describe pods myapp

打印容器中的日誌信息
命令格式爲：

kubectl logs [-f] [-p](POD|TYPE/NAME) [-c CONTAINER][options]

可打印指定Pod內指定容器的日誌，若是Pod內只有一個容器，則容器名可省略，-f可用於持續監控日誌輸出。

在容器中執行命令
命令格式爲：

kubectl exec [-p](POD|TYPE/NAME) [-c CONTAINER][options] -- [COMMAND]

刪除資源對象
kubectl delete命令能夠刪除資源對象，但對於受控於控制器的對象來講，刪除以後其控制器可能會重建出相似的對象，例如，Deployment控制器下的Pod對象在被刪除時就會被重建。
有些資源類型（如Pod），支持優雅刪除的機制，它們有着默認的刪除寬限期，能夠在命令中使用--grace-period選項或--now選項來覆蓋默認的寬限期。

學習資料

《Kubernetes實戰進階》 馬永亮著