Kubernetes之標籤與Pod控制器詳解

1、標籤

標籤的主要做用：解決同類型的資源對象愈來愈多，爲了更好的管理，按照標籤分組；

經常使用的標籤分類：

* release（版本）：stable（穩定版）、canary（金絲雀版本、能夠理解爲測試版）、beta（測試版）
* environment（環境變量）：dev（開發）、qa（測試）、production（生產）
* application（應用）：ui、as（應用軟件）、pc、sc
* tier（架構層級）：frontend（前端）、backend（後端）、cache（緩存、隱藏）
* partition（分區）：customerA（客戶A）、customerB（客戶B）
* track（品控級別）：daily（天天）、weekly（每週）
* K8s集羣中雖然沒有對有嚴格的要求，可是標籤仍是要作到：見名知意！方便本身也方便別人！

經常使用的命令有：

[root@master yaml]# cat labels.yaml 
kind: Pod
apiVersion: v1
metadata:
  name: pod-labels
  labels:
    env: qa
    tier: frontend
spec:
  containers:
  - name: myapp
    image: httpd

[root@master yaml]# kubectl get pod --show-labels    //顯示pod的標籤
[root@master yaml]# kubectl get pod -L env       //顯示鍵對應的值
[root@master yaml]# kubectl get pod -l env             //經過小l查看僅包含env標籤的資源
[root@master yaml]# kubectl get pod -l env  --show-labels      //顯示對應的鍵值
[root@master yaml]# kubectl label pod labels app=pc     //給pod打標籤
[root@master yaml]# kubectl label pod labels app-          //去除標籤
[root@master yaml]# kubectl label pod labels env=dev --overwrite    //修改標籤內容

**標籤與標籤選擇器的關係：**

* 若是標籤有多個，標籤選擇器選擇其中一個，也能夠關聯成功！
* 若是選擇器有多個，那麼標籤必須知足標籤選擇器的條件，纔可關聯成功！

標籤選擇器：標籤的查詢過濾條件

• 基於等值關係的（equality-based）：」=「、」==「、」！=「前兩個等於，最後一個不等於
• 基於集合關係（set-based）：in、notin、exists三種；

selector:
  matchLables:                 //指定等值關係的標籤選擇器
    app: nginx
  matchExpressions:             //基於集合的標籤選擇器。選擇器列表間爲」邏輯與「關係；使用In或NotIn操做是，其values不強制要求爲空的字符串列表，而使用Exists或DostNotExists時，其values必須爲空；
    - {key: name,operator: In,values: [zhangsan,lisi]}
    - {key: age,operator: Exists,values:}

使用標籤選擇器的邏輯：

* 同時指定的多個選擇器之間的邏輯關係爲」與「操做；
* 使用空值的標籤選擇器意味着每一個資源對象都將被選擇中；
* 空的標籤選擇器沒法選中任何資源；

2、常見的Pod控制器

Pod控制器基本概念：

Pod是kubernetes的最小單元，自主式建立的pod刪除就沒有了，可是經過資源控制器建立的pod若是刪除還會重建。pod控制器就是用於實現代替咱們去管理pod的中間層，並幫咱們確保每個pod資源處於咱們所定義或者所指望的目標狀態，pod資源出現故障首先要重啓容器，若是一直重啓有問題的話會基於某種策略從新編排。自動適應指望pod數量。

Kubernetes中內建了不少controller（控制器），這些至關於⼀個狀態機，⽤來控制Pod的具體狀態和⾏爲。

Pod控制器有不少種類型，可是目前kubernetes中經常使用的控制器有：

• Replication Controller（RC）：是Kubernetes系統中的核心概念，用於定義Pod副本的數量。在Master內，RC進程經過RC的定義來完成Pod的建立、監控、啓停等操做。根據RC定義，Kubernetes可以確保在任意時刻都能運行用於指定的Pod"副本"（Replica）數量。隨着kubernetes的迭代更新，RC即將被廢棄，逐漸被ReplicaSet替代；
• ReplicaSet（RS）：它的核心做用是代用戶建立指定數量的Pod副本，並肯定Pod副本一直處於知足用戶指望數量的狀態，多退少補，同時支持擴縮容機制。主要有三個組件：用戶指望的Pod副本數量；標籤選擇器，選擇屬於本身管理和控制的Pod；當前Pod數量不知足用戶指望數量時，根據資源模板進行新建；
• Deployment：工做在ReplicaSet之上，用於管理無狀態應用，除了ReplicaSet的機制，還增長了滾動更新和回滾功能，提供聲明式配置；
• DaemonSet：用於確保集羣中的每個節點只運行特定的pod副本，一般用於實現系統級後臺任務。好比ELK服務。要求：服務是無狀態的；服務必須是守護進程；

**Pod控制器一般包含三個組成部分：**

* replicas：指望的pod對象副本數量；
* selector：當前控制器匹配Pod對此項副本的標籤選擇器；
* template：pod副本的模板；

1）Replication Controller（RC）

基本概念

Replication Controller 簡稱RC，它能確保任什麼時候候Kubernetes集羣中有指定數量的pod副本(replicas)在運行， 若是少於指定數量的pod副本(replicas)，Replication Controller會啓動新的Container，反之會殺死多餘的以保證數量不變。Replication Controller使用預先定義的pod模板建立pods，一旦建立成功，pod 模板和建立的pods沒有任何關聯，能夠修改pod 模板而不會對已建立pods有任何影響，也能夠直接更新經過Replication Controller建立的pods。對於利用pod 模板建立的pods，Replication Controller根據label selector來關聯，經過修改pods的label能夠刪除對應的pods。

最初Replication Controller 是用於複製和在異常時從新調度節點的惟一kubernetes組件，後來逐漸被replicaSet代替了。如今基本上不多見到Replication Controller，它即將被廢棄。可是有的kubernates容器環境仍是有可能會有RC，因此仍是有必要知道它的用法。

根據Replication Controller的定義，Kubernetes可以確保在任意時刻都能運行用於指定的Pod"副本"（Replica）數量。若是有過多的Pod副本在運行，系統就會停掉一些Pod；若是運行的Pod副本數量太少，系統就會再啓動一些Pod，總之，經過RC的定義，Kubernetes老是保證集羣中運行着用戶指望的副本數量。

Replication Controller（RC）的特色：

* 確保Pod數量；
* 確保Pod健康；
* 彈性伸縮；
* 滾動更新；

應用示例：

[root@master yaml]# vim rc.yaml 
kind:  ReplicationController 
apiVersion: v1
metadata:
  name: http-rc
spec:
  replicas: 2
    selector:
      name: http-rc
  template:
    metadata:
      labels:
        name: http-rc
    spec:
      containers:
      - name: http-rc
        image: httpd

[root@master yaml]# kubectl apply -f rc.yaml
[root@master yaml]# kubectl get rc http-rc 
NAME      DESIRED   CURRENT   READY   AGE
http-rc   2         2         2       103s
[root@master yaml]# kubectl get pod -o wide
NAME            READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
http-rc-l2sp6   1/1     Running   0          98s   10.244.1.5   node01   <none>           <none>
http-rc-xghkm   1/1     Running   0          98s   10.244.2.5   node02   <none>           <none>
[root@master yaml]# kubectl delete -f rc.yaml

2）ReplicaSet （RS）

基本概念

ReplicaSet是Replication Controller的替代者，確保Pod副本數在任一時刻都精確知足指望值。用來確保容器應用的副本數始終保持在用戶定義的副本數，即若是有容器異常退出，會自動建立新的Pod來替代；而若是異常多出來的容器也會自動回收。雖然ReplicaSet能夠獨立使用，但通常仍是建議使用 Deployment 來自動管理ReplicaSet，這樣就無需擔憂跟其餘機制的不兼容問題（好比ReplicaSet不支持rolling-update但Deployment支持）。也就是說Replicaset一般不會直接建立，而是在建立最高層級的deployment資源時自動建立。

RS與RC相比，RS不只支持等值的標籤器，並且還支持基於集合的標籤選擇器；

ReplicaSet（RS）主要功能：

* 確保Pod數量；
* 確保Pod健康；
* 彈性伸縮；
* 滾動更新；

應用示例

[root@master yaml]# cat rs.yaml 
kind:  ReplicaSet
apiVersion: apps/v1
metadata:
  name: http-rs
spec:
  replicas: 2
  selector:
    matchLabels:
      name: http-rs
  template:
    metadata:
      labels:
        name: http-rs
    spec:
      containers:
      - name: http-rs
        image: httpd

[root@master yaml]# kubectl apply -f rs.yaml 
[root@master yaml]# kubectl get rs http-rs 
NAME      DESIRED   CURRENT   READY   AGE
http-rs   2         2         2       11s
[root@master yaml]# kubectl get pod -o wide
NAME            READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
http-rs-2sstf   1/1     Running   0          19s   10.244.1.6   node01   <none>           <none>
http-rs-jm8ph   1/1     Running   0          19s   10.244.2.6   node02   <none>           <none>
[root@master yaml]# kubectl delete -f rs.yaml

根據上面的yaml文件能夠看出，ReplicaSet和Replication Controller的template部分是同樣的，可是selector處不同。Replication Controller用selector , ReplicaSet用 selector.matchLables選擇器 ，這樣更簡單，更具備表達力！

RS支持的spec.selector 支持matchLabels和matchExpressions兩種匹配機制!

ReplicaSet 與 Replication Controller 的區別：

* ReplicaSet 標籤選擇器的能力更強；
* Replication Controller只能指定標籤名：標籤值；
* Replicaset 能夠指定env=pro,env=devel ,也能夠指定只要包含env標籤就行，理解爲env=*；

總之，目前來講，RS能夠代替RC的全部的功能，並且RC已經處於快被淘汰的邊緣！

3）Deployment

基本概念

Deployment構建於ReplicaSet之上，支持事件和狀態查看、回滾、版本記錄、暫停和啓動升級；Deployment有多種自動更新方案：Recreate，先刪除再新建；RollingUpdate，滾動升級，逐步替換。Deployment爲Pod和Replica Set（下一代Replication Controller）提供聲明式更新，它能夠更加方便的管理Pod和Replica Set。只須要在 Deployment 中描述想要的目標狀態是什麼，Deployment controller 就會幫您將 Pod 和ReplicaSet 的實際狀態改變到您的目標狀態。此外，也能夠定義一個全新的 Deployment 來建立 ReplicaSet 或刪除已有Deployment 並建立一個新的來替換。

Deployment控制器典型的應用以下：

* 使用Deployment來建立ReplicaSet (即RS)。RS在後臺建立pod。檢查啓動狀態，看它是成功仍是失敗；
* 接着經過更新Deployment的PodTemplateSpec字段來聲明Pod的新狀態；這會建立一個新的RS，Deployment會按照控制的速率將pod從舊的RS移動到新的RS中；
* 若是當前狀態不穩定，回滾到以前的Deployment revision。每次回滾都會更新Deployment的revision；
* 擴容Deployment以知足更高的負載；
* 暫停Deployment來應用PodTemplateSpec的多個修復，而後恢復上線；
* 根據Deployment 的狀態判斷上線是否hang住了；
* 清除舊的沒必要要的 ReplicaSet；

注：Deployment和RC、RS同樣都是Kubernetes的一個核心內容，主要職責一樣是爲了保證pod的數量和健康，90%的功能與Replication Controller徹底同樣，能夠看作新一代的Replication Controller。

可是，它又具有了Replication Controller以外的新特性：

RC的所有功能；
事件和狀態查看；
回滾；
版本記錄；
暫停和啓動；
多種升級方案；

通常狀況下，我的推薦使用Deployment！

應用示例

[root@master yaml]# cat deployment.yaml 
kind:  Deployment
apiVersion: extensions/v1beta1
metadata:
  name: http-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      name: http-deployment
  template:
    metadata:
      labels:
        name: http-deployment
    spec:
      containers:
      - name: http-deployment
        image: httpd

[root@master yaml]# kubectl apply -f deployment.yaml 
[root@master yaml]# kubectl get deployments. http-deployment 
NAME              READY   UP-TO-DATE   AVAILABLE   AGE
http-deployment   2/2     2            2           9s
[root@master yaml]# kubectl get pod -o wide
NAME                               READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
http-deployment-548ddf7b65-77vfk   1/1     Running   0          18s   10.244.1.7   node01   <none>           <none>
http-deployment-548ddf7b65-hdczk   1/1     Running   0          18s   10.244.2.7   node02   <none>           <none>
[root@master yaml]# kubectl delete -f deployment.yaml

4）DaemonSet（DS）

基本概念

DaemonSet確保所有（或者一些）Node節點上運行一個Pod 的副本，可以使用節點選擇器及節點標籤指定Pod僅在部分Node節點運行。當有Node加入集羣時，會爲他們新增一個Pod；當有Node從集羣移除時，這些Pod也會被回收。刪除 DaemonSet將會刪除它建立的全部Pod。DaemonSet經常使用於存儲、日誌、監控類守護進程。

DeamonSet簡單的用法是，在全部的 Node 上都存在一個 DaemonSet，將被做爲每種類型的 daemon 使用。 一個稍微複雜的用法多是，對單獨的每種類型的 daemon 使用多個 DaemonSet，但具備不一樣的標誌，和/或對不一樣硬件類型具備不一樣的內存、CPU要求。

應用示例

[root@master yaml]# cat ds.yaml 
kind:  DaemonSet
apiVersion: extensions/v1beta1
metadata:
  name: http-ds
spec:
  selector:
    matchLabels:
      name: http-ds
  template:
    metadata:
      labels:
        name: http-ds
    spec:
      containers:
      - name: http-ds
        image: httpd

[root@master yaml]# kubectl apply -f ds.yaml 
daemonset.extensions/http-ds created
[root@master yaml]# kubectl get ds http-ds 
NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
http-ds   2         2         2       2            2           <none>          17s
[root@master yaml]# kubectl get pod
NAME            READY   STATUS    RESTARTS   AGE
http-ds-gkscx   1/1     Running   0          39s
http-ds-nbq69   1/1     Running   0          39s
[root@master yaml]# kubectl delete -f ds.yaml

注：DaemonSet中不可寫replicas（副本）數量。它會根據當前k8s集羣中的node自動生成！