kubernetes常用對象

1. Master

集羣的控制節點，負責整個集羣的管理和控制，kubernetes的所有的命令基本都是發給Master，由它來負責具體的執行過程。

1.1. Master的組件

• kube-apiserver：資源增刪改查的入口
• kube-controller-manager：資源對象的大總管
• kube-scheduler：負責資源調度（Pod調度）
• etcd Server:kubernetes的所有的資源對象的數據保存在etcd中。

2. Node

Node是集羣的工作負載節點，默認情況kubelet會向Master註冊自己，一旦Node被納入集羣管理範圍，kubelet會定時向Master彙報自身的情報，包括操作系統，Docker版本，機器資源情況等。

如果Node超過指定時間不上報信息，會被Master判斷爲“失聯”，標記爲Not Ready，隨後Master會觸發Pod轉移。

2.1. Node的組件

• kubelet:Pod的管家，與Master通信
• kube-proxy：實現kubernetes Service的通信與負載均衡機制的重要組件
• Docker：容器的創建和管理

2.2. Node相關命令

kubectl get nodes

kuebctl describe node {node_name}

2.3. describe命令的Node信息

• Node基本信息：名稱、標籤、創建時間等
• Node當前的狀態，Node啓動後會進行自檢工作，磁盤是否滿，內存是否不足，若都正常則切換爲Ready狀態。
• Node的主機地址與主機名
• Node上的資源總量：CPU,內存，最大可調度Pod數量等
• Node可分配資源量：當前Node可用於分配的資源量
• 主機系統信息：主機唯一標識符UUID，Linux kernel版本號，操作系統，kubernetes版本，kubelet與kube-proxy版本
• 當前正在運行的Pod列表及概要信息
• 已分配的資源使用概要，例如資源申請的最低、最大允許使用量佔系統總量的百分比
• Node相關的Event信息。

3. Pod

Pod是Kubernetes中操作的基本單元。每個Pod中有個根容器(Pause容器)，Pause容器的狀態代表整個容器組的狀態，其他業務容器共享Pause的IP，即Pod IP，共享Pause掛載的Volume，這樣簡化了同個Pod中不同容器之間的網絡問題和文件共享問題。

圖片 - pod

1. Kubernetes集羣中，同宿主機的或不同宿主機的Pod之間要求能夠TCP/IP直接通信，因此採用虛擬二層網絡技術來實現，例如Flannel，Openvswitch(OVS)等，這樣在同個集羣中，不同的宿主機的Pod IP爲不同IP段的IP，集羣中的所有Pod IP都是唯一的，不同Pod之間可以直接通信。
2. Pod有兩種類型：普通Pod和靜態Pod。靜態Pod即不通過K8S調度和創建，直接在某個具體的Node機器上通過具體的文件來啓動。普通Pod則是由K8S創建、調度，同時數據存放在ETCD中。
3. Pod IP和具體的容器端口（ContainnerPort）組成一個具體的通信地址，即Endpoint。一個Pod中可以存在多個容器，可以有多個端口，Pod IP一樣，即有多個Endpoint。
4. Pod Volume是定義在Pod之上，被各個容器掛載到自己的文件系統中，可以用分佈式文件系統實現後端存儲功能。
5. Pod中的Event事件可以用來排查問題，可以通過kubectl describe pod xxx 來查看對應的事件。
6. 每個Pod可以對其能使用的服務器上的計算資源設置限額，一般爲CPU和Memory。K8S中一般將千分之一個的CPU配置作爲最小單位，用m表示，是一個絕對值，即100m對於一個Core的機器還是48個Core的機器都是一樣的大小。Memory配額也是個絕對值，單位爲內存字節數。

7. 資源配額的兩個參數

8. Requests:該資源的最小申請量，系統必須滿足要求。

9. Limits:該資源最大允許使用量，當超過該量，K8S會kill並重啓Pod。

圖片 - pod2

4. Label

1. Label是一個鍵值對，可以附加在任何對象上，比如Node,Pod,Service,RC等。Label和資源對象是多對多的關係，即一個Label可以被添加到多個對象上，一個對象也可以定義多個Label。
2. Label的作用主要用來實現精細的、多維度的資源分組管理，以便進行資源分配，調度，配置，部署等工作。
3. Label通俗理解就是“標籤”，通過標籤來過濾篩選指定的對象，進行具體的操作。k8s通過Label Selector(標籤選擇器)來篩選指定Label的資源對象，類似SQL語句中的條件查詢（WHERE語句）。

4. Label Selector有基於等式和基於集合的兩種表達方式，可以多個條件進行組合使用。

5. 基於等式：name=redis-slave（匹配name=redis-slave的資源對象）;env!=product(匹配所有不具有標籤env=product的資源對象)

6. 基於集合：name in (redis-slave,redis-master);name not in (php-frontend)（匹配所有不具有標籤name=php-frontend的資源對象）

使用場景

1. kube-controller進程通過資源對象RC上定義的Label Selector來篩選要監控的Pod副本數，從而實現副本數始終保持預期數目。
2. kube-proxy進程通過Service的Label Selector來選擇對應Pod，自動建立每個Service到對應Pod的請求轉發路由表，從而實現Service的智能負載均衡機制。
3. kube-scheduler實現Pod定向調度：對Node定義特定的Label，並且在Pod定義文件中使用NodeSelector標籤調度策略。

5. Replication Controller(RC)

RC是k8s系統中的核心概念，定義了一個期望的場景。

主要包括：

• Pod期望的副本數（replicas）
• 用於篩選目標Pod的Label Selector
• 用於創建Pod的模板（template）

RC特性說明：

1. Pod的縮放可以通過以下命令實現：kubectl scale rc redis-slave --replicas=3
2. 刪除RC並不會刪除該RC創建的Pod，可以將副本數設置爲0，即可刪除對應Pod。或者通過kubectl stop /delete命令來一次性刪除RC和其創建的Pod。
3. 改變RC中Pod模板的鏡像版本可以實現滾動升級（Rolling Update）。具體操作見https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/
4. Kubernetes1.2以上版本將RC升級爲Replica Set，它與當前RC的唯一區別在於Replica Set支持基於集合的Label Selector(Set-based selector)，而舊版本RC只支持基於等式的Label Selector(equality-based selector)。
5. Kubernetes1.2以上版本通過Deployment來維護Replica Set而不是單獨使用Replica Set。即控制流爲：Delpoyment→Replica Set→Pod。即新版本的Deployment+Replica Set替代了RC的作用。

6. Deployment

Deployment是kubernetes 1.2引入的概念，用來解決Pod的編排問題。Deployment可以理解爲RC的升級版（RC+Reolicat Set）。特點在於可以隨時知道Pod的部署進度，即對Pod的創建、調度、綁定節點、啓動容器完整過程的進度展示。

使用場景

1. 創建一個Deployment對象來生成對應的Replica Set並完成Pod副本的創建過程。
2. 檢查Deployment的狀態來確認部署動作是否完成（Pod副本的數量是否達到預期值）。
3. 更新Deployment以創建新的Pod(例如鏡像升級的場景)。
4. 如果當前Deployment不穩定，回退到上一個Deployment版本。
5. 掛起或恢復一個Deployment。

可以通過kubectl describe deployment來查看Deployment控制的Pod的水平拓展過程。

7. Horizontal Pod Autoscaler(HPA)

Horizontal Pod Autoscaler(HPA)即Pod橫向自動擴容，與RC一樣也屬於k8s的資源對象。

HPA原理：通過追蹤分析RC控制的所有目標Pod的負載變化情況，來確定是否針對性調整Pod的副本數。

Pod負載度量指標：

• CPUUtilizationPercentage：Pod所有副本自身的CPU利用率的平均值。即當前Pod的CPU使用量除以Pod Request的值。
• 應用自定義的度量指標，比如服務每秒內響應的請求數（TPS/QPS）。

8. Service(服務)

8.1. Service概述

圖片 - service

Service定義了一個服務的訪問入口地址，前端應用通過這個入口地址訪問其背後的一組由Pod副本組成的集羣實例，Service與其後端的Pod副本集羣之間是通過Label Selector來實現“無縫對接”。RC保證Service的Pod副本實例數目保持預期水平。

8.2. kubernetes的服務發現機制

主要通過kube-dns這個組件來進行DNS方式的服務發現。

8.3. 外部系統訪問Service的問題

IP類型	說明
Node IP	Node節點的IP地址
Pod IP	Pod的IP地址
Cluster IP	Service的IP地址

8.3.1. Node IP

NodeIP是集羣中每個節點的物理網卡IP地址，是真實存在的物理網絡，kubernetes集羣之外的節點訪問kubernetes內的某個節點或TCP/IP服務的時候，需要通過NodeIP進行通信。

8.3.2. Pod IP

Pod IP是每個Pod的IP地址，是Docker Engine根據docker0網橋的IP段地址進行分配的，是一個虛擬二層網絡，集羣中一個Pod的容器訪問另一個Pod中的容器，是通過Pod IP進行通信的，而真實的TCP/IP流量是通過Node IP所在的網卡流出的。

8.3.3. Cluster IP

1. Service的Cluster IP是一個虛擬IP，只作用於Service這個對象，由kubernetes管理和分配IP地址（來源於Cluster IP地址池）。
2. Cluster IP無法被ping通，因爲沒有一個實體網絡對象來響應。
3. Cluster IP結合Service Port組成的具體通信端口才具備TCP/IP通信基礎，屬於kubernetes集羣內，集羣外訪問該IP和端口需要額外處理。
4. k8s集羣內Node IP 、Pod IP、Cluster IP之間的通信採取k8s自己的特殊的路由規則，與傳統IP路由不同。

8.3.4. 外部訪問Kubernetes集羣

通過宿主機與容器端口映射的方式進行訪問，例如：Service定位文件如下：

可以通過任意Node的IP 加端口訪問該服務。也可以通過Nginx或HAProxy來設置負載均衡。

9. Volume(存儲卷)

9.1. Volume的功能

1. Volume是Pod中能夠被多個容器訪問的共享目錄，可以讓容器的數據寫到宿主機上或者寫文件到網絡存儲中
2. 可以實現容器配置文件集中化定義與管理，通過ConfigMap資源對象來實現。

9.2. Volume的特點

k8s中的Volume與Docker的Volume相似，但不完全相同。

1. k8s上Volume定義在Pod上，然後被一個Pod中的多個容器掛載到具體的文件目錄下。
2. k8s的Volume與Pod生命週期相關而不是容器是生命週期，即容器掛掉，數據不會丟失但是Pod掛掉，數據則會丟失。
3. k8s中的Volume支持多種類型的Volume：Ceph、GlusterFS等分佈式系統。

9.3. Volume的使用方式

先在Pod上聲明一個Volume，然後容器引用該Volume並Mount到容器的某個目錄。

9.4. Volume類型

9.4.1. emptyDir

emptyDir Volume是在Pod分配到Node時創建的，初始內容爲空，無須指定宿主機上對應的目錄文件，由K8S自動分配一個目錄，當Pod被刪除時，對應的emptyDir數據也會永久刪除。

作用：

1. 臨時空間，例如程序的臨時文件，無須永久保留
2. 長時間任務的中間過程CheckPoint的臨時保存目錄
3. 一個容器需要從另一個容器中獲取數據的目錄（即多容器共享目錄）

說明：

目前用戶無法設置emptyVolume的使用介質，如果kubelet的配置使用硬盤則emptyDir將創建在該硬盤上。

9.4.2. hostPath

hostPath是在Pod上掛載宿主機上的文件或目錄。

作用：

1. 容器應用日誌需要持久化時，可以使用宿主機的高速文件系統進行存儲
2. 需要訪問宿主機上Docker引擎內部數據結構的容器應用時，可以通過定義hostPath爲宿主機/var/lib/docker目錄，使容器內部應用可以直接訪問Docker的文件系統。

注意點：

1. 在不同的Node上具有相同配置的Pod可能會因爲宿主機上的目錄或文件不同導致對Volume上目錄或文件的訪問結果不一致。
2. 如果使用了資源配額管理，則kubernetes無法將hostPath在宿主機上使用的資源納入管理。

9.4.3. gcePersistentDisk

表示使用谷歌公有云提供的永久磁盤（Persistent Disk ,PD）存放Volume的數據，它與EmptyDir不同，PD上的內容會被永久保存。當Pod被刪除時，PD只是被卸載時，但不會被刪除。需要先創建一個永久磁盤，才能使用gcePersistentDisk。

使用gcePersistentDisk的限制條件：

• Node(運行kubelet的節點)需要是GCE虛擬機。
• 虛擬機需要與PD存在於相同的GCE項目中和Zone中。

10. Persistent Volume

Volume定義在Pod上，屬於“計算資源”的一部分，而Persistent Volume和Persistent Volume Claim是網絡存儲，簡稱PV和PVC，可以理解爲k8s集羣中某個網絡存儲中對應的一塊存儲。

• PV是網絡存儲，不屬於任何Node，但可以在每個Node上訪問。
• PV不是定義在Pod上，而是獨立於Pod之外定義。
• PV常見類型：GCE Persistent Disks、NFS、RBD等。

PV是有狀態的對象，狀態類型如下：

• Available:空閒狀態
• Bound:已經綁定到某個PVC上
• Released:對應的PVC已經刪除，但資源還沒有回收
• Failed:PV自動回收失敗

11. Namespace

Namespace即命名空間，主要用於多租戶的資源隔離，通過將資源對象分配到不同的Namespace上，便於不同的分組在共享資源的同時可以被分別管理。

k8s集羣啓動後會默認創建一個“default”的Namespace。可以通過kubectl get namespaecs查看。

可以通過kubectl config use-context namespace配置當前k8s客戶端的環境，通過kubectl get pods獲取當前namespace的Pod。或者通過kubectl get pods --namespace=NAMESPACE來獲取指定namespace的Pod。

Namespace yaml文件的定義

12. Annotation(註解)

Annotation與Label類似，也使用key/value的形式進行定義，Label定義元數據（Metadata）,Annotation定義“附加”信息。

通常Annotation記錄信息如下：

• build信息，release信息，Docker鏡像信息等。
• 日誌庫、監控庫等。

參考《Kubernetes權威指南》