kubernetes-pod控制器-4

pod控制器

controller

​ 對於k8s系統的來說API Server是整個集羣入口的gateway，並且它還是一個Restfull系統, 做爲一個Restfull風格的系統, 其所管理的內容通通會被抽象成resources， pod控制器就是一個resources, 並且我們創建出的每一個pod都是一個具體的Object；

​ API Server爲整個Kubernetes的數據管理提供了一種數據範式，所有存取於API Server的數據，都必須遵循於Resources這樣的一個規範，比如我們需要創建一個Pod時候，應該在Pod上調用哪個屬性，給哪個值，所有的數據都保存在etcd當中;

​ 保存在etcd中的數據將會被構建爲k8s的活動對象，而活動對象狀態成爲什麼的結構，則取決於各種各種樣的 controller， controller負責創建修改各種 活動對象， 當活動對象創建時它的基本標準是由存儲於etcd用戶定義的存儲對象， 所以在etcd當中，我們稱爲用戶期望的對象 ;

​ controller 從中取出來用戶所期望的標準， 負責將它創建在當前的k8s集羣上成爲活動對象， 並且Controller 還會負責通過和解Reconcilation Loops，確保在每一個時刻Live Objects要與用戶所定義的Objects要保持一致， status狀態需要與spec中狀態保持一致， status由controller負責維護， 而spec則由用戶負責維護

k8s通過將控制器代碼打成成一個統一的守護進程， kube-controller-manage管理k8s集羣中各式各樣的控制器的和解循環(control loop)的實現, 後續所有的controller都會在它的維護中來確保控制器的正常運行；

​ 比如k8s控制器用於控制Pod, Pod出現故障時由Pod控制器來進行銷燬重建， Pod控制器內部也有和解循環， 而我們 controller-manage可以高可用， 如果用戶不需要這個Pod控制器的話，那麼也會自動將Pod控制器下面的Pod對象刪除；

• yaml創建的就是自主式pod，而自主式pod不是由控制器控制和管理的資源
• pod控制器用於實現代爲管理Pod的中間層，並確保pod資源始終處於自行定義所期望的資源狀態(status)
• 當pod出現故障，pod控制器會嘗試着重啓容器，如果重啓一直失敗那麼它將會重新編排，如果pod低於用戶所定義的資源狀態，那麼控制器將會刪除或增加資源

kube-controller-manager

​ 黃色的控制器是Pod控制器，其他的是其他資源的控制器，這些纔是Kubernetes背後的資源管理大腦，所以整個Kubernetes的各種高級功能都是藉助於Contrller完成的，對於Contrller來講，它們纔是真正的確保任務編排系統之所以成爲編排系統的核心組件，因爲編排任務當中的比如像自動創建、自動恢復等等高級功能，基本都是依賴於Contrller完成的，所以從某種意義上來講，Contrller如果複雜一點的話，我們甚至可以把它稱爲運維器或者操作器；
​ 那麼對於kube-controller-manager來講，它是整個Kubernetes控制平面一個非常重要的守護進程，其實Kubernetes每一個守護進程都可以通過配置選項來配置，只不過我們在此之前將其運行成爲了一個Pod，如果我們期望自定義的kube-controller-manager的類型被啓用，可以在啓動這個進程時通過 --controllers來指定要啓用的控制器，默認是*;

​ 使用kubeadm安裝kube-controller-manager的時候，默認配置文件地址：/etc/kubernetes/manifests/kube-controller-manager.yaml 修改完成之後不需要重啓，會自動重建；

​ 當我們在定義Pod時，不應該手動去創建, 因爲Pod控制器是建立在基礎資源之上的進一步抽象， k8s之所以能夠自動編排， 是完全依賴於控制器來實現的, 因爲我們應該創建控制器對象來管理這些基礎資源類型， Pod控制器是隻是一種統稱，早期的Kubernetes版本只有一種控制器，ReplicationController，現在這一個控制器被劃分爲多種類型，第一種叫守護進程型，守護進程型，又可以分爲有狀態應用，和無狀態應用，第二種非守護進程型，例如備份任務；

控制器分類

守護進程型：
    無狀態：
        非系統級：Deployment ReplicaSet
        系統級：DaemonSet
    有狀態：
        SataefulSet
非守護進程型：
    Job
    CronJob

一、ReplicaSet

​ 主要用來控制非系統級的無狀態守護進程的應用, 代用戶創建指定數據的pod副本，並確保Pod副本一直滿足用戶所期望的數量狀態，資源將遵行多退少補概念，並支持擴縮機制， ReplicationController已被廢棄，推薦使用：ReplicaSet， 主要由三個組件組成， k8s不建議直接使用ReplicaSet，推薦使用 Deployment

1.1、組件說明

組件功能	說明
pod副本	用戶期望的pod副本數量， 管控副本有多少個
標籤選擇器	選定由自己管理和控制的pod副本， 以此判定哪些pod由自己管理
pod資源模板	當控制器中的pod數量少於定義的pod數量，那麼就會根據模板來完成pod 資源的新建，

1.2、參數說明

• 查看狀態

~]# kubectl explain rs   # 簡寫 replicaSet
    KIND:     ReplicaSet
    VERSION:  apps/v1

• 副本數量

replicase:  # 創建幾個副本數量  replicas <integer> 

• 標籤選擇器

selector：  # 標籤選擇器    selector	<Object> -required-
    matchExpressions	<[]Object>              # 匹配表達式,這個標籤可以指定一段
    matchLabels	        <map[string]string>     # 等值標籤選擇，   語法爲鍵值對

• 副本模板

template：  # 副本模板      template	<Object> 
  metadata:   # pod資源本身的元數據，由selector控制的元數據
    labels:  # 必須符合selector的標籤器中的標準，否則創建將會永無休止， 也可以是其它的標籤
  spec:   # 模板的資源

• spec: pod資源本身的資源

1.3、demo

1.3.1、創建yaml

apiVersion: apps/v1      # 正式版本
kind: ReplicaSet         # pod控制器
metadata:                # 元數據類型
    name: first-rs-app   # 新創建pod的名稱
    labels:
       app: first-app    # 這裏定義的是 rs的標籤
       release: firsts
spec:
    replicas: 4          # 定義副本數據爲4個
    selector:            # 標籤選擇器，定義匹配的pod標籤
        matchLabels:     # pod只要符合下面兩個標籤就會歸該選擇器
            app: first-app
            release: firsts
    template:           # pod的模板
        metadata:       # pod源數據
            name: apps  # pod名稱， 在describe中也不會顯示
            namespace: default  # 名稱空間
            labels:    # pod的標籤， 需要與 matchLables一致，否則該yaml就無法控制pod
                app: first-app
                release: firsts
                envs: apps  # 也可以多出其它的
        spec:
            containers:         # pod的資源
            - name: my-container   # 名稱
              image: ikubernetes/myapp:v1     # pod容器鏡像
              imagePullPolicy: IfNotPresent   # 如果沒有就下載
              ports:           # 定義expose的端口
              - name: http
                containerPort: 80
              readinessProbe:    # 存活性探測
                initialDelaySeconds: 3   # 初始化3秒之後開始
                failureThreshold: 3      # 失敗三次就認爲失敗
                httpGet:         # 檢測80端口以及訪問index.html頁面
                   port: http
                   path: index.html

1.3.2、查看pod資源

# 創建pod
]# kubectl  create -f first_replicaset.yaml

# 查看rs詳細信息
]# kubectl get rs -o wide
NAME    DESIRED CURRENT READY  AGE  CONTAINERS   IMAGES    SELECTOR
first-rs-app    4     4     4    11m   my-container   ikubernetes/myapp:v1   app=first-app,release=firsts

# 查看更詳細的rs狀態
]# kubectl describe rs
Name:         first-rs-app
Namespace:    default
Selector:     app=first-app,release=firsts
Labels:       app=first-app
              release=firsts
Annotations:  <none>
Replicas:     4 current / 4 desired
Pods Status:  4 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  app=first-app
           envs=apps
           release=firsts
  Containers:
   my-container:
    Image:        ikubernetes/myapp:v1
    Port:         80/TCP
    Host Port:    0/TCP
    Readiness:    http-get http://:http/index.html delay=3s timeout=1s period=10s #success=1 #failure=3
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Events:
  Type    Reason            Age   From                   Message
  ----    ------            ----  ----                   -------
  Normal  SuccessfulCreate  12m   replicaset-controller  Created pod: first-rs-app-q7bnc
  Normal  SuccessfulCreate  12m   replicaset-controller  Created pod: first-rs-app-xrtdw
  Normal  SuccessfulCreate  12m   replicaset-controller  Created pod: first-rs-app-jrkhh
  Normal  SuccessfulCreate  12m   replicaset-controller  Created pod: first-rs-app-xzksd
  Normal  SuccessfulCreate  11m   replicaset-controller  Created pod: first-rs-app-n55kh

1.3.3、操作pod

# 隨便刪除一個pod，  它會自動生成pod
]# kubectl delete pod first-rs-app-xrtdw 
	pod "first-rs-app-xrtdw" deleted

# 編輯 rs 
]# kubectl edit rs first-rs-app 
	# 修改replicase可以立即生效
	# 修改 spec.containers.image不會立即生效，需要手動一個個操作
	
# 刪除rs
]# kubectl delete rs first-rs-app 
	replicaset.apps "first-rs-app" deleted

​ 使用控制器創建一組不分彼此的pod資源時，控制器創建的pod要想能夠被客戶端不受生命週期所影響，用戶就需要有一個固定的訪問端點，而訪問端點需要在pod外在加一個server選擇器，server需要與pod是同一個標籤，以便關連pod資源，而後用戶通過server訪問，server會直接代理pod資源， server與Pod並不需要與控制器有一一對應關係

二、Deployment

​ 當使用ReplicaSet時，創建的Pod並不會因爲在配置文件中修改版本應用而生效，所以在rs下要想真正更新Pod， 每次刪一個Pod等它重建完成，再刪第二個，依次類推完成灰度發佈 (滾動發佈)， 但是因爲Pod的會實時收到監控，一旦數量少於預定義的數量就會創建，因此就需要使用先加後減的策略進行，先加後減是確保當前的可用節點數量，但是如果這樣的話，就比較繁瑣；

​ 那麼我們的Kubernetes就專門提供了一個控制器來負責，完成此類功能，它被稱爲Deployment，也就意味着在Kubernetes之上我們不應該人爲去手動使用ReplicaSet存在的目的，只是用來管理底層Pod的，但我們用戶來管理的是Deployment，Deployment負責由Controller來管理RS，RS負責管理Pod，它能利用RS功能幫用戶完成各種操作，比如版本升級，回滾，灰度發佈，金絲雀發佈等

• 灰度 ： 刪一個加一個， 真正做到了滾動發佈
• 金絲雀: 當使用deployment發佈時，使用先加後減的方式, 但對於金絲雀發佈只加不減，新老版本並存，暫停了,我們可以使用路由策略把一部分用戶量不大的區域的流量放到新的Pod裏面，而用戶量比較大的地區還是使用老版本的Pod，而這一切在Deployment上，都可用自動進行，你只需要告訴它更新一批並且暫停下來，那就是金絲雀

​ 如果需要實現流量調度，Kubernetes目前默認提供的組件還沒這個能力，需要藉助其他的網絡組件實現， deployment支持回滾操作,deploymnet實現方式是將歷史Pod進行保留不刪除，在其必要的時候還能夠基於歷史的Pod進行回滾， 默認保存十個版本， 而現在應該是保留所有版本；

​ 而且對於回滾來說，它還是基於灰度發佈， 刪完重建依次循環，假設有6個Pod那麼依次刪除並建立消耗的時間會很長，但對於deployment來說它可以在原有的基礎上先增加一個或多個然後在刪除原有老版的， 或者先刪除多個然後在創建， 所以說RS不應該是我們直接使用，rs存在的目的只是爲了管理底層的Pod；

​ 對於我們用戶應該使用的是Deployment，Deployment負責由控制器來管理ReplicaSet，ReplicaSet來管理Pod，所以Deployment是一個更高級的功能，它能利用ReplicaSet的功能幫我們完成各種更新策略；

• 工作在ReplicaSet之上，Deployment控制ReplicaSet來控制pod，用於管理無狀態應用，目前來說最好的控制器。

• 擁有ReplicaSet所有的功能，支持滾動更新和回滾功能，也提供聲明式配置。

• 一個節點可以運行多個Deployment副本，也可以一個不運行， pod數量可以大於節點數

2.1、更新方式

• 更新方式一： 允許節點多創建一個
• 更新方式二： 允許節點少一個

​ 升級步驟 從v1逐步升級至v2, v1最後全部遷移之後, v1的控制器也不會被刪除, 用於版本回退，更新時默認是灰度\滾動的方式進行，根據粒度滾動更新(一次新增幾個或一次允許少幾個)， 在更新時livenessProbe或readnessProbe時最爲重要。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-nZJ2MjaD-1591840603154)(C:\Users\xiong\AppData\Roaming\Typora\typora-user-images\dev\1576217581894.png)]

deployment 建立在replicaSet之上， 可管理多個rs控制器，但其中只有一個處於活躍狀態，默認只會保存10個rs

2.2、參數說明

• 查看狀態

  ~]# kubectl explain deploy  
      KIND:     Deployment
      VERSION:  apps/v1
  

• 副本數量

  replicase:  # 創建幾個副本數量  replicas <integer> 
  

• **strategy: ** 更新策略

  屬性	說明
  Recreate	重建更新,刪除一個更新一個
  RollingUpdate	滾動更新， 允許臨時多幾個或少幾個， 創建更新的粒度

  RollingUpdate屬性	說明
  maxSurge	對應的更新過程當中，最多能超出的目標副本數有多少個， 兩個指定方式： %(百分比)跟 數字
  maxUnavaiable	最多有幾個不可用，

• 標籤選擇器

  selector：  # 標籤選擇器    selector	<Object> -required-
      matchExpressions	<[]Object>              # 匹配表達式,這個標籤可以指定一段
      matchLabels	        <map[string]string>     # 等值標籤選擇，   語法爲鍵值對
  

• 副本模板

  template：  # 副本模板      template	<Object> 
    metadata:   # pod資源本身的元數據，由selector控制的元數據
      labels:  # 必須符合selector的標籤器中的標準，否則創建將會永無休止， 也可以是其它的標籤
    spec:   # 模板的資源 
  

• spec: pod資源本身的資源

2.3、demo

2.3.1、創建yaml

]# cat deployment.yaml 
apiVersion: apps/v1      # 版本爲 正式版本
kind: Deployment         # pod控制器類型
metadata:                # 控制器的元數據
    name: my-deploy      # 控制器名稱
    labels:              # 控制器labels
      app: dly
spec:
    replicas: 2          # pod副本數  三要素-1 
    selector:
      matchLabels:      # 標籤選擇器  三要素-2
        app: my-deploy
        release: base1
    strategy:            # 更新策略
      rollingUpdate:     # 滾動更新
        maxSurge: 2      # 臨時可以多創建2個
        maxUnavailable: 1  # 可以少一個，  假設有五個1個不可用，多創建二個 最多4-7個可用
    template:            # pod模板   三要素-3， 每一個模板都是一個標準的對象
      metadata:          # pod元數據
        name: my-app     # pod名稱
        namespace: default
        labels:          # pod標籤， 必須要與matchLabels保存一致可以多,少了就不歸該控制器了
          app: my-deploy
          release: base1
      spec:              # pod屬性
        containers:      # pod容器屬性
        - name: my-app   # 名稱
          image: ikubernetes/myapp:v1   # 容器鏡像
          imagePullPolicy: IfNotPresent  # 如果不存在就下載
          ports:           # 暴露端口
          - name: http
            containerPort: 80
          readinessProbe:   # 存活性探測
            failureThreshold: 3    # 可接受3次失敗，3次之後就直接error
            initialDelaySeconds: 3  # 初始化3秒之後開始探測
            httpGet:               # 探測類型爲http
              port: http
              path: index.html
              

spec.paused:  暫停
spec.revisionHistoryLimit:   保存多少個回滾的版本, 默認爲10個
spec.strategy   更新策略
	Recreate:  重建更新，刪除一個建立一個，在創建出新的Pod之前會先殺掉所有已存在的Pod
    RollingUpdate:  滾動更新，  允許臨時多幾個或少幾個
        maxSurge:   對應的更新過程當中，最多能超出的目標副本數有多少個， 兩個指定方式：  %跟數字
        maxUnavaiable：  最多有幾個不可用， 

2.3.2、查看資源

# 查看deployment屬性 
]# kubectl get deploy -o wide
NAME        READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                 SELECTOR
my-deploy   2/2     2            2           21s   my-app       ikubernetes/myapp:v1   app=my-deploy,release=base1

# 查看 replicaSet
]# kubectl get rs  -o wide
NAME                   DESIRED   CURRENT   READY   AGE   CONTAINERS   IMAGES                 SELECTOR
my-deploy-8574fcbdfd   2         2         2       20m   my-app       ikubernetes/myapp:v1   app=my-deploy,pod-template-hash=8574fcbdfd,release=base1

# 屬性說明：   deployment名稱-固定的hash碼  my-deploy-8574fcbdfd

# 查看pod
]# kubectl get pods -l app=my-deploy
NAME                         READY   STATUS    RESTARTS   AGE
# depl名稱-固定hash碼-隨機串
my-deploy-8574fcbdfd-2c9tn   1/1     Running   0          22m
my-deploy-8574fcbdfd-qzfcm   1/1     Running   0          22m

# 查看deployment詳細信息
# 換了個yaml，  查看最小跟最大， 如果不指定就是25%  不足1的會補齊1
]# kubectl describe deployments.apps my-deploy   
Name:                   my-deploy
Namespace:              default
CreationTimestamp:      Mon, 16 Dec 2019 09:35:38 +0800
Labels:                 type=deployment
Annotations:            deployment.kubernetes.io/revision: 1
                        kubectl.kubernetes.io/last-applied-configuration:
                          {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"type":"deployment"},"name":"my-deploy","namespace":"de...
Selector:               app=my-deploy,revese=deploy-v1.1
Replicas:               4 desired | 4 updated | 4 total | 4 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  1 max unavailable, 2 max surge
Pod Template:       # pod模板 labels
  Labels:  app=my-deploy
           revese=deploy-v1.1
  Containers:
   my-container:
    Image:        ikubernetes/myapp:v1
    Port:         80/TCP
    Host Port:    0/TCP
    Liveness:     http-get http://:http/index.html delay=0s timeout=1s period=10s #success=1 #failure=3

查看詳細版本

]#  kubectl rollout history deployment my-deploy --revision=1
# --record=true # 使用--record可以在查看歷史的時候查看此次記錄
deployment.apps/my-deploy with revision #1
Pod Template:
  Labels:	app=my-deploy
	pod-template-hash=5fbb68fb8c
	revese=deploy-v1.1
  Containers:
   my-container:
    Image:	ikubernetes/myapp:v1
    Port:	80/TCP
    Host Port:	0/TCP
    Liveness:	http-get http://:http/index.html delay=0s timeout=1s period=10s #success=1 #failure=3
    Environment:	<none>
    Mounts:	<none>
  Volumes:	<none>

2.3.3、操作資源

# 修改 deployment.yaml 
spec:
    replicas: 4    # 副本修改爲 4
    template:
      spec:
        containers:
        - name: my-app
          image: ikubernetes/myapp:v2   # 版本升級

]# kubectl get deploy -o wide   # 查看deploy
]# kubectl get rs -o wide    # 查看rs

# 查看升級的版本
]# kubectl rollout history deployment 
deployment.apps/my-deploy 
REVISION  CHANGE-CAUSE   # 如果不加 --record在版本中就看不到具體的操作過程
1         <none>
2         <none>

修改deployment

# patch,  從v1版本 升級v2版本
~]# kubectl patch deployments my-deploy -p '{"spec": {"template":{"spec":{"containers":[{"name":"my-container","image":"ikubernetes/myapp:v2"}]}}}}'
    deployment.apps/my-deploy patched
    
# 此時在查看history版本，就有兩個了
 ~]# kubectl rollout history deployment 
deployment.apps/my-deploy 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

# 查看deployment詳細信息
]# kubectl describe deployments.apps my-deploy 
Name:                   my-deploy
Namespace:              default
CreationTimestamp:      Mon, 16 Dec 2019 09:35:38 +0800
Labels:                 type=deployment
Annotations:            deployment.kubernetes.io/revision: 2
                        kubectl.kubernetes.io/last-applied-configuration:
                          {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"type":"deployment"},"name":"my-deploy","namespace":"de...
Selector:               app=my-deploy,revese=deploy-v1.1
Replicas:               4 desired | 4 updated | 4 total | 4 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  1 max unavailable, 2 max surge
Pod Template:
  Labels:  app=my-deploy
           revese=deploy-v1.1
  Containers:
   my-container:
    Image:        ikubernetes/myapp:v2  # 升級版本
    Port:         80/TCP
    Host Port:    0/TCP
    # 存活性檢測
    Liveness:     http-get http://:http/index.html delay=0s timeout=1s period=10s #success=1 #failure=3
    
# 查看pods 詳細信息
]# kubectl describe pods my-deploy-7ff6f44678-tvl74
Name:         my-deploy-7ff6f44678-tvl74
Namespace:    default
Priority:     0
Node:         node1/192.168.9.31
Start Time:   Mon, 16 Dec 2019 11:27:40 +0800
Labels:       app=my-deploy
              pod-template-hash=7ff6f44678
              revese=deploy-v1.1
Controlled By:  ReplicaSet/my-deploy-7ff6f44678
Containers:
  my-container:
    Container ID:   docker://xx
    Image:          ikubernetes/myapp:v2  

還原版本

]# kubectl rollout undo deployment my-deploy --to-revision=1
	deployment.apps/my-deploy rolled back

]# kubectl describe pods my-deploy-5fbb68fb8c-2b5xm 
    Image:          ikubernetes/myapp:v1 # 此時在查看就是v1版本了

# 需要注意的是 如果還原了1，那麼上一版本就是還原前的版本
]#  kubectl rollout history deployment my-deploy 
deployment.apps/my-deploy 
REVISION  CHANGE-CAUSE
2         <none>
3         <none>

# 查看rs的版本
]# kubectl get rs -o wide
NAME                   DESIRED   CURRENT   READY   AGE     CONTAINERS     IMAGES                 SELECTOR
my-deploy-5fbb68fb8c   4         4         4       3h54m   my-container    ikubernetes/myapp:v1   app=my-deploy,pod-template-hash=5fbb68fb8c,revese=deploy-v1.1
my-deploy-7ff6f44678   0         0         0       121m    my-container   ikubernetes/myapp:v2   app=my-deploy,pod-template-hash=7ff6f44678,revese=deploy-v1.1

三、daemonSet

• 要求在集羣的每一個節點或符合選擇器要求的節點運行，並且只運行一個pod副本，
• 通常用於實現系統級的管理功能，比如ELK服務
• daemonSet也是通過標籤選擇器來判定每一個節點的運行狀態。
• **特性：**服務是無狀態的，服務必須是守護進程

在整個集羣的每一個節點上，只運行某個指定pod的一個並且只能是一個副本或者是集羣中某些符合選擇器的節點上的某一個副本， 用於實現系統級的管理功能，可以直接把節點上的某個目錄做爲存儲卷關連至某個Pod中

# 查看創建的頭部信息
~]# kubectl  explain ds
    KIND:     DaemonSet
    VERSION:  apps/v1

3.1、參數說明

• minReadySeconds <integer> # 最少的準備節點數
• revisionHistoryLimit <integer> # 保存支持歷史版本數， 默認10個
• selector <Object> -required- # 選擇器
• template <Object> -required- # 模板對象
• updateStrategy <Object> # 更新策略
  • RollingUpdate： # 刪一個更新一個
  • OnDelete： # 刪除更新
• 在yaml配置文件中 通 — 分段，在一個配置文件中可以定義多個資源對象

3.2、demo

3.1、創建yaml

]# cat daemon.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
  labels:
    app: redis-v4
    release: stable
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-redis
      release: base01
  template:
    metadata:
      name: con-redis
      labels:
        app: my-redis
        release: base01
    spec:
      containers:
      - name: redis
        image: redis:4.0.14
        imagePullPolicy: IfNotPresent
        ports:
        - name: redis     # expose端口 定義別名
          containerPort: 6379  # 端口號 6379
        livenessProbe:    # 存活性探測 
          tcpSocket: 
            port: 6379    # 監聽6379端口

---  # 分段，可以用於定義多個資源
apiVersion: apps/v1 
kind: DaemonSet    # 一個節點生成一個副本，  無需在次定義副本數 replicas
metadata:
  name: daemons
  namespace: default
  labels:
    app: daemons
    release: stable
spec:
  revisionHistoryLimit: 5   # 定義最多5個歷史版本，默認10個
  selector:                 # 二元素-選擇器
    matchLabels:
      app: daemon-v1
      release: base-v1
  template:                 # 二元素-模板
    metadata:
      name: my-node
      namespace: default
      labels:
        app: daemon-v1
        release: base-v1
    spec: 
      containers:
      - name: my-con
        image: ikubernetes/filebeat:5.6.5-alpine
        imagePullPolicy: IfNotPresent
        env:
        - name: REDIS_HOST   # 定義往哪個redis中發送日誌
          value: redis.default.svc.cluster.local

3.2、生成

]# kubectl apply -f daemon.yaml 
    deployment.apps/redis created
    daemonset.apps/daemons created

# 定義了 name: REDIS_HOST，  名稱爲redis,  dns解析默認後綴 default.svc.cluster.local
]# kubectl expose deployment redis --port=6379
    service/redis exposed

# 查看expose端口以及名稱
]# kubectl get svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
redis        ClusterIP   10.109.181.86    <none>        6379/TCP   2s

# 連接至daemon節點查看解析是否成功
]# kubectl exec -it daemons-5x2j8  /bin/sh
    Name:      redis.default.svc.cluster.local
    Address 1: 10.109.181.86 redis.default.svc.cluster.local

3.3、查看資源

# daemonSet資源，查看簡寫就是ds
]# kubectl get ds
NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemons   2         2         2       2            2           <none>          9m56s

# 查看pods分別在哪個節點中
]# kubectl  get pods -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP            NODE 
daemons-5x2j8            1/1     Running   0          11m   10.244.1.67   node1
daemons-f2d9g            1/1     Running   0          11m   10.244.2.59   node2

 # 查看pods節點信息
]#  kubectl describe pods daemons-f2d9g 
Name:         daemons-f2d9g
Node:         node2/192.168.9.32
Labels:       app=daemon-v1
              controller-revision-hash=5f9fdbdb4c
              pod-template-generation=1
              release=base-v1
Annotations:  <none>
Status:       Running
IP:           10.244.2.59
Controlled By:  DaemonSet/daemons

3.4、操作資源

]# kubectl get ds
NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemons   2         2         2       2            2           <none>          39m

# 升級版本
]# kubectl  set image daemonset daemons my-con=ikubernetes/filebeat:5.6.6-alpine
            # 設置屬性   方法      ds名稱   container名稱=image版本
	daemonset.apps/daemons image updated

# 查看版本 升級成功
]# kubectl describe pods daemons-vzhgk 
Name:         daemons-vzhgk
Image:          ikubernetes/filebeat:5.6.6-alpine

# 查看升級版本
]# kubectl rollout history daemonset daemons 
    daemonset.apps/daemons 
    REVISION  CHANGE-CAUSE
    1         <none>
    2         <none>

]# kubectl rollout history daemonset daemons --revision=1
    daemonset.apps/daemons with revision #1
    Containers:
      my-con:
        Image:	ikubernetes/filebeat:5.6.5-alpine
        Environment:
          REDIS_HOST:	redis.default.svc.cluster.local

]# kubectl rollout history daemonset daemons --revision=2
daemonset.apps/daemons with revision #2
   my-con:
    Image:	ikubernetes/filebeat:5.6.6-alpine
    Environment:
      REDIS_HOST:	redis.default.svc.cluster.local

3.4.1、刪除資源

# 刪除由這個yaml創建資源
    ]# kubectl delete -f daemon.yaml  

# 刪除ds
	]# kubectl delete ds daemons

3.4.2、暫停恢復更新

# 暫停更新   kubwx rollout pause deployment daemons
# 繼續升級   kubwx rollout resume deployment daemons

四、Job

​ Job控制器的主要作用是，一次性就業，非守護進程，它需要在後臺運行，任務執行完成之後，就退出，我們正常Pod控制器控制的Pod一旦宕機，會自動重建，這是我們的Deployment、ReplicaSet或者DaeonSet的特性，但是有些任務，比如像備份，我們只執行一次備份任務就行了，那這個時候可以使用我們的Job控制器，所以Job控制器就是用來創建一個或多個Pod，這個Pod就是執行相應的任務，完成之後終止就完了，如果要刪除Job，我們會刪除這個Pod所做的所有操作；

​ 只要完成就立即退出，不需要重啓或重建， 要不要重建pod, 就是任務是否完成, job只是一次性運行

五、Cronjob

週期性運行， 每一次退出都會有正常退出的時間，如果前一次任務執行到了正常退出時間還沒有退出，那就可能會有任務丟失的可能性

六、statefulSet

• 管理有狀態應用，當節點都有自己的特性時就是有狀態應用；
• 每一個pod副本都是被單獨管理的，它擁有着自己獨有標識和獨有數據集；
• 一旦節點故障，加入之前需要做很多的初始化操作

​ 假設有多個集羣，而每個集羣所提供的資源各不盡相同，statefulset提供了一個封裝的控制器，這個封裝指的是人爲的將手動操作, 複雜的執行邏輯將定義成腳本放置在statefules的模板定義當中，每一個節點故障之後通過腳本將自動恢復 (難度極大)

七、其它控制器

其它類型資源	說明
TPR (third party Resources)	第三方資源 1.2+支持, 1.7之後廢棄
CDR (curstom Defined Resources)	用戶自定義資源 1.8+ 默認
Operator	封裝運維技能，如etcd
helm	與 linux的yum安裝類型，直接安裝就不使用在手動創建腳本

垃圾收集器

Garbage Collction， 垃圾收集： 當一個Pod控制器終止的時候會將這個控制下面的所有Pod全部回收

​ 每一個依賴性的Object在它的metadata中都有一個ownerReferneces字段,你沒定義它也會自動填充, 比如由控制器創建的Pod，那麼Pod的ownerReferneces就屬於它的控制器,所以任意一個Object終止的時候, 一般都由它的ownerReferneces所指定的對象負責給它進行GC垃圾收集,大多數情況下會自動設置，當然也可以自己指定垃圾收集器，收集的方式一般是通過級聯的方式進行的；
​ 一個叫做後臺一個叫前臺， 通常情況下只要刪除Pod控制器, 那麼該控制器下的所有Pod都將會被級聯刪除，當然也可以設置不級聯刪除，pod控制器刪除之後下面的Pod也不會被刪除，會轉爲自助式Pod,沒有控制器了
​ 基本上有引用者的時候，刪除了引用者，那麼被引用的資源會一起刪除，而這個級聯操作，可以工作爲兩種模型，就是前臺和後臺，後臺就是刪除一個資源的過程不用管，全部會在後臺執行，所謂前臺就是用戶需要等待資源以及被引用的資源一起刪除之後再進行下一步的操作，會佔用終端；
~]# kubectl explain cj.metadata.ownerReferences

             |

| Operator | 封裝運維技能，如etcd |
| helm | 與 linux的yum安裝類型，直接安裝就不使用在手動創建腳本 |

垃圾收集器

Garbage Collction， 垃圾收集： 當一個Pod控制器終止的時候會將這個控制下面的所有Pod全部回收

​ 每一個依賴性的Object在它的metadata中都有一個ownerReferneces字段,你沒定義它也會自動填充, 比如由控制器創建的Pod，那麼Pod的ownerReferneces就屬於它的控制器,所以任意一個Object終止的時候, 一般都由它的ownerReferneces所指定的對象負責給它進行GC垃圾收集,大多數情況下會自動設置，當然也可以自己指定垃圾收集器，收集的方式一般是通過級聯的方式進行的；
​ 一個叫做後臺一個叫前臺， 通常情況下只要刪除Pod控制器, 那麼該控制器下的所有Pod都將會被級聯刪除，當然也可以設置不級聯刪除，pod控制器刪除之後下面的Pod也不會被刪除，會轉爲自助式Pod,沒有控制器了
​ 基本上有引用者的時候，刪除了引用者，那麼被引用的資源會一起刪除，而這個級聯操作，可以工作爲兩種模型，就是前臺和後臺，後臺就是刪除一個資源的過程不用管，全部會在後臺執行，所謂前臺就是用戶需要等待資源以及被引用的資源一起刪除之後再進行下一步的操作，會佔用終端；
~]# kubectl explain cj.metadata.ownerReferences