Kubernetes 核心概念

概述

Kubernetes 有各種資源對象來描述整個集羣的運行狀態。這些對象都須要經過調用 kubernetes api 來進行建立、修改、刪除，能夠經過 kubectl 命令工具，也能夠直接調用 k8s api，或者使用對象語言的客戶端庫（例如：golang ， pythion ）。

每一個 kubernetes 對象都會包含兩個關鍵字段：Object Spec 和 Object Status。spec 描述了對象所指望達到的狀態，status 描述了該對象的實際狀態。

下面會寬泛的介紹一些 Kubernetes 的核心概念，便於初步的理解它們特徵及工做模式。

核心概念

Pod

Pod 是 Kubernetes 最小的調度單元，能夠由一個或者多個容器組成。

Pod 的設計理念是支持多個容器在一個 Pod 中共享網絡和文件系統，能夠經過進程間通訊和文件共享這種簡單高效的方式組合完成服務。

Pod 的特徵：

• 能夠包含多個容器，它們之間共享 IPC、Network 、UTC、PID namespace，能夠直接經過 localhost 進行通訊。
• 支持 CPU / Mem 超賣
• 支持一個或者多個 init containers
• Pod 能夠共享 Volume，使得多個容器之間能夠共享數據。
• Pod 生命週期短暫，且不會自愈。須要結合 Deployment、DaemonSet、StatefulSet 等控制器來達到容錯。
• 優雅退出：Pod 刪除的時候先給其進程發送 SIGTERM，等待一段時間（grace period）後才強制中止依然還在運行的進程。
• 支持（反）親和性
• 支持指定調度器
• 支持優先級和搶佔性調度（v1.8 及以上）
• 支持配置 serviceAccount

kubernetes v1.8+ 且 docker >= 1.13.1 才支持容器之間共享 PID namespace，還須要配置 kubelet —docker-disable-shared-pid=false

Init Containers - Kubernetes

Labels & Selectors

Labels 是 Key-Value 對，k8s 用於標識其全部資源；而 Selectors 是標籤選擇器，用於選擇特定 labels 的資源。

Selectors 目前支持兩種選擇器：Equality-based（基於平等） 和 Set-based（基於集合）。

1. Equality-based

基於相等的或者不想等的條件用標籤的 keys 和 values 進行過濾。支持三種運算符：「=」，「==」 和 「!=」。還可使用逗號操做符，鏈接多個運算符。

2. Set-based

Set-based 的選擇器容許用一組 value 來過濾 key。
支持三種操做符：in，notin 和 exists（僅針對於 key 符號）。

例如：

env in (dev, test, staging, prod)
env notin (staging, prod)
partition
!partition

Set-based 能夠和 Equality-based 條件結合使用。

Deployment

Kubernetes 有幾個版本的副本控制器，好比 Replication Controller、Replica Set（RC 升級版）和 Deployments。

Deployment 是邏輯層的一種抽象，爲 Pod 和 ReplicaSet 提供了一種聲明式定義，來代替之前的 Replication Controller 更方便的管理應用。

在 Kubernetes 的實際使用中，RS 也屬於底層概念，由 Deployment 來管理，所以用戶通常都是與 Deployment 打交道。

Deployment 有幾種 典型的應用場景，好比：

• 定義 Deployment 來建立 Pod 和 ReplicaSet
• 滾動升級和回滾應用，好比藍綠髮布，金絲雀發佈等等
• 擴容和縮容
• 暫停和繼續 Deployment

RC、RS、Deployment 等對象都是爲了解決無狀態服務而設計，下面還會針對有狀態服務，介紹對應的對象。

Service

Kubernetes Pod 有本身的生命週期，能夠隨時被建立和銷燬，而一旦銷燬就永遠結束了。而每一個 Pods 都有本身的 IP，而 Pod 的生命週期也意味着 這些 IP 地址不老是穩定可靠的。因此須要有針對容器的服務發現與負載均衡機制，來訪問這個 Pod 邏輯分組。

service 是對一組提供相同功能的 Pods 集合的抽象，爲這組Pods提供統一的訪問入口。藉助 Service 能夠方便的實現服務發現與負載均衡，並實現應用的零宕機升級。

在 Kubernetes 集羣中，每一個 Node 都會部署一個 kube-proxy 進程。kube-proxy 負責爲 Service 實現了一種 VIP (虛 IP)。

Service 有四種類型：

• ClusterIP：默認類型，自動分配一個僅 cluster 內部能夠訪問的虛擬 IP。
• NodePort：該模式會在每臺機器上綁定一個端口，這樣能夠經過 NodeIP:NodePort 進行服務訪問。
• LoadBalancer：該模式會跟雲服務商有關，好比能夠經過 aliyun、aws 等建立一個外部的負載均衡器，將請求轉發到對應的服務組。
• ExternalName：支持將服務經過 DNS CNAME 記錄方式轉發到指定的域名（經過 spec.externalName 設定）。須要 kube-dns 版本大於 1.7。

Ingress

一般狀況下，Service 和 Pod 僅支持在集羣內部進行服務訪問。而 Ingress 能夠提供外部服務可訪問的 URL / 負載均衡器等。

Ingress 對象只是配置了一些規則，若要實現集羣外部的訪問，還須要部署一個 Ingress Controller，它會從 kube-apiserver 監聽 Ingress 和 Service 的變動，並根據 Ingress 的規則配置負載均衡來提供訪問入口。

Job

Job 負責批量處理短暫的一次性任務，僅執行一次，並保證處理的一個或者多個Pod成功結束。

具體的能夠查看：深刻K8S Job(一)：介紹

PV & PVC

PersistentVolume (PV) 和 PersistentVolumeClaim (PVC) 提供了方便的持久化卷：PV 提供網絡存儲資源，而 PVC 請求存儲資源。這樣，設置持久化的工做流包括配置底層文件系統或者雲數據卷、建立持久性數據卷、最後建立 PVC 來將 Pod 跟數據卷關聯起來。PV 和 PVC 能夠將 pod 和數據卷解耦，pod 不須要知道確切的文件系統或者支持它的持久化引擎。

PV 也是集羣的資源（等同於cpu / mem），但不一樣於 pod volume，它是獨立於 Pod 的生命週期。

支持類別劃分，好比不一樣的服務質量級別（SSD / SATA），不一樣的備份策略等。
支持動態 PV（StorageClass）。
支持卷的擴容及快照（v1.8+ 特性）。
支持 Local Volume，容許將 Node 本地的磁盤、分區或者目錄做爲持久化存儲使用。可是須要注意該模式不支持動態建立，使用前須要預先建立好 PV。

PV 是存儲資源，而 PVC 是對 PV 的請求。PVC 和 Pod 相似，Pod 消費 Node 資源，而 PVC 消費 PV 資源；Pod 可以請求 CPU 和內存資源，而 PVC 請求特定大小和訪問模式的數據卷。

StatefulSet

StatefulSet 用於支持部署有狀態服務，而有狀態的服務很關鍵的就是持久化存儲，這就依賴上面介紹的 PV & PVC 了。

StatefulSet 的應用場景包括：

• 穩定的持久化存儲，即不須要關心 Pod 的從新調度，服務訪問的仍是相同的持久化數據。
• 穩定的網絡標誌，即 Pod 從新調度後其 PodName 和 HostName 不變。
• 有序部署，即 Pod 的建立是有順序的，在部署或者擴展的時候要依據定義的順序依次進行建立，基於 init containers 來實現。
• 有序收縮（刪除）。

參考案例：Running ZooKeeper, A Distributed System Coordinator - Kubernetes

1. 推薦在 k8s v1.9 + 的版本使用 statefulSet。
2. 爲了保證數據安全，刪除 StatefulSet 是不會刪除 PV 的，須要考慮清理策略。
3. StatefulSet 須要提早建立一個 Headless Service 來定義 DNS domain。

Other

還有不少別的資源對象，這裏暫不一一介紹了，由於涉及的篇幅會比較長。
對於上面或者未說起的資源對象須要多瞭解一下的，建議查閱官方文檔。

好比：

• Namespace
• Node
• Secret：集羣的祕藥管理
• ConfigMap：集羣的配置管理
• Event：記錄k8s集羣運行所遇到的各類大事件
• HPA（HorizontalPodAutoscaler）：自動擴縮容
• DaemonSet：保證每一個Node上都運行一個容器副本，經常使用於部署一些集羣服務的agent(日誌／監控…), 也能夠基於Pod進行親和部署。