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

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

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

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

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

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

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

kube-apiserver
apiserver進程對外暴露REST API接口給外部客戶端及內(nèi)部組件調(diào)用，它封裝了對各個對象的增、刪、改、查操作，可以說是整個集群管理的總?cè)肟凇?/p>

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

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

replication controller

endpoints controller

namespace controller

serviceaccounts controller

Etcd是Kubernetes集群的基礎(chǔ)組件，用于保存集群所有的元數(shù)據(jù)信息、配置信息、對象狀態(tài)等。

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

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

kube-proxy
kube-proxy負責集群內(nèi)部的請求轉(zhuǎn)發(fā)及負載均衡工作。它通過Service對象的配置信息，為Pod創(chuàng)建代理服務(wù)，實現(xiàn)請求從Service到Pod的路由轉(zhuǎn)發(fā)。

容器運行時

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

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

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

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

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

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

apiVersion: 創(chuàng)建該對象所使用的 Kubernetes API 的版本

kind: 想要創(chuàng)建的對象的類型

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

spec: 對象期望狀態(tài)的描述

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

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

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

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

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

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

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

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

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

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

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

- 該類對象用于服務(wù)發(fā)現(xiàn)和負載均衡的對象

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

Pod的IP地址并不是固定，而是隨著編排不斷變化的，外面的請求怎么找到對應(yīng)的POD，這個也就是大多數(shù)分布式業(yè)務(wù)都會遇到的服務(wù)發(fā)現(xiàn)問題

多個相同Pod一起提供服務(wù)的時候，它們的負載均衡怎么實現(xiàn)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kubernetes對容器應(yīng)用進行了抽象，例如把一個容器或強關(guān)聯(lián)的一組容器抽象為Pod，把各類存儲都抽象成Volume，把一組Pod抽象成Service等等基礎(chǔ)對象。

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

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

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

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