摘要：標識是與操作對象間的紐帶。集群為每個對象維護三類信息對象元數據期望狀態與實際狀態元數據指對象的基本信息，比如命名標簽注釋等等，用于識別對象期望狀態一般由用戶配置來描述的實際狀態是由集群各個組件上報的集群實際的運行情況。

學習Kubernetes時，發現它的概念和術語還是比較多的，光靠啃官方文檔比較晦澀。所以邊學習邊整理，對主要的概念和術語做一下分類及簡要說明。感覺把重要概念都理解了，對Kubernetes的設計思想，整體框架也就有了初步的認識。

從功能上來說，我把Kubernetes的概念或術語大概分為以下三類：

組件：指實際在集群中運行的Kubernetes程序集，分為Master組件、Node組件及附加組件。

對象：對象是一個抽象的概念實體，Kubernetes把應用、運行場景、功能、集群狀態等都抽象成一個個對象，并通過API對這些對象進行管理，從而管理整個集群的狀態。

標識：對組件和對象的各種表示方式，例如命名、標簽、注釋等。標識是KubernetesAPI與操作對象間的紐帶。

Master組件提供了k8s管理集群的核心功能，k8s通過Master組件實現整個集群的調度管理，它就像集群的大腦，會根據集群當前的狀態，不斷進行調整，使集群一直保持在期望的狀態。Master組件包括以下幾個進程：

kube-apiserver
apiserver進程對外暴露REST API接口給外部客戶端及內部組件調用，它封裝了對各個對象的增、刪、改、查操作，可以說是整個集群管理的總入口。

kube-scheduler
kube-scheduler做的事情說來簡單--監控新pod的創建，并把pod分配到合適的node來運行。但實際上，選擇“合適的Node”是一個很復雜的過程，需要考慮的因素包括單node及整個集群的資源需求、軟硬件資源的限制策略、數據存儲、工作負載間的干擾等等。

kube-controllers-manager
controllers-manager進程從字面上理解，是用來做控制器管理的。controllers-manager其實是一組守護進程，通過監控集群各組件的狀態，并不斷調整集群實際狀態，使的集群向期望狀態調整，它由一組子進程構成：

replication controller

endpoints controller

namespace controller

serviceaccounts controller

Etcd是Kubernetes集群的基礎組件，用于保存集群所有的元數據信息、配置信息、對象狀態等。

運行Node組件的節點稱為Node節點，是k8s集群實際的工作負載節點。Node節點可以是物理機、虛擬機或任何可以運行Node組件的設備。所有的業務應用都運行在Node節點中。Node組件包括以下幾個部分：

Kubelet
kubelet負責實際的容器管理，Kubernetes通過apiserver給kubelet發送Pod管理請求，同時把Pod及Node的運行狀態匯報給apiserver。

kube-proxy
kube-proxy負責集群內部的請求轉發及負載均衡工作。它通過Service對象的配置信息，為Pod創建代理服務，實現請求從Service到Pod的路由轉發。

容器運行時

實際的容器運行引擎。Kubernetes其實支持其他的容器技術比如rkt，但是Docker相比與它們處于絕對的優勢地位。所以，Kubernetes生態中的容器也基本特指指Docker容器。

在說明對象之前，先區分下Kubernetes中的三個名詞：對象(objects)、資源(resources)和工作負載(workload).

對象：指的是KubernetesAPI中定義好的操作對象，是抽象概念。

資源：抽象API對象被創建后，對象就被實例化了。實例化后的對象被稱為資源。

工作負載：特指有運行容器的資源，例如Deployment資源就是工作負載，而service資源不是。

Kubernetes集群為每個對象維護三類信息：對象元數據(ObjectMeta)、期望狀態(Desired State)與實際狀態(Autual State),元數據指對象的基本信息，比如命名、標簽、注釋等等，用于識別對象；期望狀態一般由用戶配置spec來描述的；實際狀態是由集群各個組件上報的集群實際的運行情況。Kubernetes努力使每個對象的實際狀態與期望狀態相匹配，從而使整個集群的狀態與用戶配置的期望狀態一致。
Kubernetes對象一般用yaml文件來描述，有幾個個字段是必須的：

apiVersion: 創建該對象所使用的 Kubernetes API 的版本

kind: 想要創建的對象的類型

metadata: 幫助識別對象唯一性的數據，包括一個 name 字符串、UID 和可選的 namespace

spec: 對象期望狀態的描述

用戶通過命令行工具kubectl來操作這些對象，Kubectl吧yaml轉換成JSON格式來執行API請求。下面是一個POD對象的描述文件示例及注釋：

apiVersion: v1
kind: Pod  # 對象名稱
metadata:  # 對象的基本信息
  name: pod-example # 對象唯一標示
spec:      # 期望狀態
  containers: # 指定pod中運行的容器鏡像及運行參數(類似Dockerfile)
  - name: ubuntu
    image: ubuntu:trusty
    command: ["echo"]
    args: ["Hello World"]

其中，kind字段描述對象類型"Pod"，spec之前是對象的ObjectMeta，spec開始，就是對象期望狀態的描述。

根據官方API對象參考文檔的分類，下面我們把對象分為幾大類來分別簡要說明。計劃以后的文章，會結合實際操作，對各個重要對象做更深入的說明。

- workloads類的對象用于管理運行容器實例

Pod：
Pod是Kubernetes里最重要的對象，也是Kubernetes集群中運行部署應用或服務的最小單位。Pod對象描述一個Pod由哪些容器鏡像構成，以及這些容器應該怎么運行。類比傳統的業務架構，Pod更接近于虛擬機的角色而不是應用進程的角色。

ReplicaSet：
ReplicaSet對象是對Pod的更高一層抽象，它用來管理一組相同POD副本，并確保這組相同Pod的數量始終與用戶期望一致，并實現Pod的高可用。即如果有容器異常退出，ReplicaSet會自動創建新的Pod來替代，保證Pod數量永遠與用戶配置一致。

Deployment：
Deployment對象是Kubernetes中最常用的對象之一，用于部署無狀態服務。它在ReplicaSet對象的基礎上，又做了一層抽象。通過管理多組ReplicaSet對象，來實現POD的滾動升級、回滾、擴容縮容等。

StatefulSet：
不同于Deployment，StatefulSet對象顧名思義是對有狀態服務的一種抽象。所以，StatefulSet對象在定義時，相比與Deployment多了一些與狀態相關的內容，比如持久化存儲、服務對外的不變的唯一標示、部署、擴容、滾動升級時確保有序等等。

DaemonSet：
DaemonSet對象是Kubernetes對守護進程的抽象。當我們需要集群中的每個Node都跑一些如日志收集、監控等守護進程時，就可以把這類型進程包裝成Pod，并用調用DaemonSet來部署了。DaemonSet做的事情其實和Deployment差不多，只不過Deployment對象部署的Pod，會根據集群情況，在不同Node間自動調度。而DaemonSet會指定的NODE上(默認是集群所有Node)，都部署定義Pod，確保這些NODE都有跑著守護進程Pod。

Job、CronJob：
除了上面幾個對象所抽象描述的應用工作場景外，實際業務場景中，還有一類應用或服務并不需要一直運行，比如一些一次性任務，或需要定時執行的任務。這種不需要長時間運行的任務，完成了就可以退出的服務，就可以用Job對象來定義。CronJob和Job對象的關系，和Deployment與ReplicaSet的關系很像，可以類比來理解。首先，Job也是直接用于管理Pod的，同時可以定義這個一次性任務Pod的執行時間、超時時間、錯誤處理（重啟還是生成新Pod）等任務屬性。而CronJob管理是用來管理Job，類似crobtab，它可以通過yaml文件中的schedule字段配置具體時間，來控制指定Job定時執行，從而實現定時執行特定的一次性任務。

- 該類對象用于服務發現和負載均衡的對象

Service：
上面提到的對象都是用于管理POD及容器實例的。但是，業務系統光有POD實例還不夠，還必須對外提供服務。這里就會衍生出兩個問題：

Pod的IP地址并不是固定，而是隨著編排不斷變化的，外面的請求怎么找到對應的POD，這個也就是大多數分布式業務都會遇到的服務發現問題

多個相同Pod一起提供服務的時候，它們的負載均衡怎么實現

而Service對象就是用來解決這兩個問題的。它用固定的VIP或DNS名稱和指定標識的一組Pod對應起來，不管Pod IP怎么變，Service對外的VIP都不會變化，并且，自動的將請求在這組Pod中負載均衡。

- 該類對象用于初始化容器配置及持久化容器存儲的對象

Volume：
前面說到，Pod里的不同容器可以共享存儲，這個共享存儲就靠Volume來配置的。要注意的是，這里Volume與Docker中的定義不用，Kubernetes中Volume跟Pod生命周期一致，Pod終止了，該Pod掛載的Volume就失效了（根據掛載volume的類型不同，數據可能丟失也可能不丟失）。

PV，PVC：
Volume可以支持多種類型的存儲，除了直接在Volume字段中去聲明所有存儲細節，K8S還抽象出了PV和PVC對象。簡單來說PV是對具體存儲資源的描述，比如存儲類型、地址、訪問賬戶等；而PVC，是對怎么使用資源的方法的描述，比如只讀只寫，需要的空間等；而Pod通過Volume字段掛載具體要使用的PVC。PV和PVC是獨立于Pod多帶帶定義的，這樣，就把共享存儲的配置、分割、掛載等操作都解耦了。比如，一個NFS遷移后ip地址變了，存儲管理員只需要修改PV中的配置，而不用關心具體哪個業務POD在使用這個NFS。

ConfigMap,Securet
K8S中除了常見的存儲，還有一類特殊的Volume，不是為了Pod存放數據，而是為了給Pod提供數據的。ConfigMap和Secret對象就是用來定義這類型的Volume。簡單來說，可以將它們理解為一份Key:Value格式的數據，Pod可以通過Volume掛載它們，將這份數據保存成文件隨時調用。唯一的區別是，ConfigMap對象保存的數據是明文，一般作為應用配置文件；而Secret對象保存的對象要求是經過Base64轉碼的，用于提供數據庫密碼等對安全要求比較高的配置。不過這些配置，直接在做容器鏡像時就配置不就好了，為啥要多此一舉呢？原因和上面PV和PVC一樣，都是為了盡可能解耦業務核心與經常可能變化的依賴配置。比如數據庫更換了賬號，只需要修改Secret對象，不用重新去構建容器鏡像。

- 該類對象定義整個K8S集群運行方式的對象

Namespace
Kubernetes作為一個集群管理平臺，為不同用戶劃分不同權限管理，例如多租戶等，是必備的功能。而不同用戶作用域的隔離，就是靠Namespace對象實現的。Namespace是Kubernetes項目中的一個邏輯管理單位，不同Namespace的API對象，在調用API進行操作是，是相互隔離開的。通過不同用戶角色與Namespace關聯，從而實現權限管理。

- 除了上述分類外的其他對象都歸為這一類，一般用來管理集群的特殊功能比如彈性伸縮等

Horizontal Pod Autoscaling
容器作為一個輕量級的承載應用的技術，快速啟動和快速部署是它的優點之一。自然的，根據業務負載自動擴縮容等需求，在容器集群的可行性和效率就可以變得很高。而Kubernetes中 Horizontal Pod Autoscaling對象，就是用于進行POD自動水平縮放的，這也是Kubernetes最能體現運維優勢的特性之一。
Horizontal Pod Autoscaling具體的操作對象是Deployment和ReplicaSet，通過不同循環獲取每個Pod的資源情況，比如CPU利用率，并根據設定的目標利率來計算目前需要的Pod副本縮放的比例，然后通過訪問相應的Deployment或ReplicaSet對象，來對Pod數量進行自動縮放，從而提高了集群資源整體利用率。

標識是Kubernetes中最重要的概念，因為它是所有API的操作與操作對象間的紐帶。Kubernetes中的標識主要有以下幾種：

Label
Label可以說是Kubernetes中最最重要的核心概念，一個Lable是一個KEY=Value的鍵值對。任何對象資源都可以有一個或多個Label，而同個Label，也可以配置在多個對象上。然后重點來了，大多數API對象的yaml字段中，都有Label Selector字段，可以實現對Label中的key或value的多維度選擇，例如in、not in、and、or等等。這樣，Kubernetes對API作用對象就能進行多維度，細粒度的選擇，從而實現比較精細化的容器編排調度工作，比如,對所有"ENV:release"執行擴容操作，或者把部分請求灰度到有"ver:v1.14.0"的pod上等等。Label把資源對象和應用、基礎設施都解耦了，你不用關心這個Pod具體在那個Node上運行，也不用關心具體是什么應用用了哪個容器鏡像，只要Label符合Label Selector，就可以通過API調用統一進行操作。

Names
除了Label，所有資源對象肯定還必須有一個全局唯一的標識，即Names字段。

Annotation
Annotation很好理解，與通常意義的注釋一樣，用于描述作者、版本、配置說明等等任何需要的信息，需要說明的是，Annotation也必須是Key：Value格式的。

通過上面對Kubernetes重要概念的說明，我們可以大致梳理出Kubernetes的一些設計理念：

Kubernetes對容器應用進行了抽象，例如把一個容器或強關聯的一組容器抽象為Pod，把各類存儲都抽象成Volume，把一組Pod抽象成Service等等基礎對象。

在基礎對象的層面上，Kubernetes又對應用使用場景，做了一層抽象。極客時間的Kubernetes課程有一張圖畫的很好：可以看到，Kubernetes中各個對象實際就是對生產業務場景的各類需求的抽象。

抽象出各類型對象以后，用戶可以通過yaml文件（或直接命令行調用API）來描述這些對象的期望狀態，確認了各對象些期望狀態的集合，也就確認了整個集群的期望狀態。這些所有的操作，都是聲明式的，而不是命令集群要怎么做

Kubernetes通過控制器循環不斷將各組件收集來的集群實際狀態與各對象的期望狀態對比，并自動化的將集群實際狀態向期望狀態轉移，這個過程，也就是Kubernetes最核心的概念：編排。

本文對Kubernetes中的重要概念做了分類和簡要，后面的文章會結合集群的實際操作，對每個概念做更詳細的說明。