前言

Pod的分類

自助式pod

• 只要pod退出了叁鉴，此類型的pod不會被重建怜姿，該pod沒有管理者团搞，死亡后不會被拉起岗照。

控制器管理的pod【生產(chǎn)環(huán)境中大多數(shù)都是選擇控制器去管理pod】

• 在控制器的生命周期里始終要維持pod的副本數(shù)目

區(qū)別
生命周期被管理的機制不太一致

一、什么是控制器

Kubernetes 中內(nèi)建了很多 controller（控制器）亭病，這些相當(dāng)于一個狀態(tài)機鹅很，用來控制 Pod 的具體狀態(tài)和行為

二、控制器類型

①ReplicationController 和 ReplicaSet

②Deployment

③DaemonSet

④StateFulSet

⑤Job/CronJob

⑥Horizontal Pod Autoscaling

1罪帖、ReplicationController和ReplicaSet

ReplicationController（RC）用來確保容器應(yīng)用的副本數(shù)始終保持在用戶定義的副本數(shù)促煮，即如果有容器異常退出，會自動創(chuàng)建新的 Pod 來替代整袁；而如果異常多出來的容器也會自動回收菠齿；
在新版本的 Kubernetes 中建議使用 ReplicaSet 來取代 ReplicationController 。ReplicaSet 跟ReplicationController 沒有本質(zhì)的不同坐昙，只是名字不一樣绳匀，并且 ReplicaSet 支持集合式的 selector（標(biāo)簽 ）

2、Deployment 一般的應(yīng)用程序可用

Deployment 為 Pod 和 ReplicaSet 提供了一個聲明式定義 (declarative) 方法民珍，用來替代以前的ReplicationController 來方便的管理應(yīng)用。典型的應(yīng)用場景包括盗飒；

• ①定義 Deployment 來創(chuàng)建 Pod 和 ReplicaSet
• ②滾動升級和回滾應(yīng)用【Deployment自身具備的特點】
• ③擴容和縮容【RS就已經(jīng)實現(xiàn)嚷量，Deployment通過RS管理Pod因此也支持】
• ④暫停和繼續(xù) Deployment【Deployment自身具備的特點】

命令式編程：它側(cè)重于如何實現(xiàn)程序，就像我們剛接觸編程的時候那樣逆趣，我們需要將程序的實現(xiàn)過程按照邏輯結(jié)果一步一步實現(xiàn)寫下來
聲明式編程：它側(cè)重于定義想要什么蝶溶，然后告訴計算機 / 引擎，讓它幫你去實現(xiàn)宣渗。

滾動更新：會創(chuàng)建一個新副本的rs1抖所，舊的rs的pod減少一個時，rs1會新加一個痕囱，直到全部增減完成

回滾：同理田轧，需要恢復(fù)舊的rs時，會啟動rs鞍恢，再進行增減操作

3傻粘、DaemonSet 類似與守護進程的應(yīng)用程序可用

DaemonSet確保全部（或者一些）Node 上運行一個 Pod 的副本每窖。當(dāng)有 Node 加入集群時，也會為他們新增一個Pod 弦悉。當(dāng)有 Node 從集群移除時窒典，這些 Pod 也會被回收。刪除 DaemonSet 將會刪除它創(chuàng)建的所有 Pod

使用 DaemonSet 的一些典型用法：

• ①運行集群存儲 daemon稽莉，例如在每個 Node 上運行g(shù)lusterd瀑志、ceph
• ②在每個 Node 上運行日志收集 daemon，例如fluentd污秆、logstash
• ③在每個 Node 上運行監(jiān)控 daemon劈猪，例如Prometheus Node Exporter、collectd混狠、Datadog 代理岸霹、New Relic 代理，或 Ganglia gmond

4将饺、Job 批處理腳本程序可用

Job 負(fù)責(zé)批處理任務(wù)贡避，即僅執(zhí)行一次的任務(wù)，它保證批處理任務(wù)的一個或多個 Pod 成功結(jié)束

5予弧、CronJob【本質(zhì)上是在特定的時間循環(huán)創(chuàng)建Job去實現(xiàn)的】批處理腳本程序可用

管理基于時間的 Job刮吧，即：

• 在給定時間點只運行一次
• 周期性地在給定時間點運行
  使用前提條件：當(dāng)前使用的 Kubernetes 集群，版本 >= 1.8（對 CronJob）掖蛤。對于先前版本的集群杀捻，版本 <1.8，啟動 API Server時蚓庭，通過傳遞選項--runtime-config=batch/v2alpha1=true可以開啟 batch/v2alpha1API

典型的用法如下所示：

• 在給定的時間點調(diào)度 Job 運行
• 創(chuàng)建周期性運行的 Job致讥，例如：數(shù)據(jù)庫備份、發(fā)送郵件

6器赞、StatefulSet 有狀態(tài)服務(wù)的應(yīng)用程序可用

StatefulSet 作為 Controller 為 Pod 提供唯一的標(biāo)識垢袱。它可以保證部署和 scale 的順序
StatefulSet是為了解決有狀態(tài)服務(wù)的問題（對應(yīng)Deployments和ReplicaSets是為無狀態(tài)服務(wù)而設(shè)計），但到目前為止港柜，MySQL有狀態(tài)服務(wù)部署進K8s并不穩(wěn)定请契，其應(yīng)用場景包括：

• ①穩(wěn)定的持久化存儲，即Pod重新調(diào)度后還是能訪問到相同的持久化數(shù)據(jù)夏醉，基于PVC來實現(xiàn)
• ②穩(wěn)定的網(wǎng)絡(luò)標(biāo)志爽锥，即Pod重新調(diào)度后其PodName和HostName不變，基于Headless Service（即沒有Cluster IP的Service）來實現(xiàn)
• ③有序部署畔柔，有序擴展氯夷，即Pod是有順序的，在部署或者擴展的時候要依據(jù)定義的順序依次依次進行（即從0到N-1靶擦，在下一個Pod運行之前所有之前的Pod必須都是Running和Ready狀態(tài)）肠槽，基于init containers來實現(xiàn)
• ④有序收縮擎淤，有序刪除（即從N-1到0）

7、Horizontal Pod Autoscaling【自動擴展秸仙，可以理解為它并不是一個控制器嘴拢，而是一個控制器的附屬品，使用HPA去控制其他的控制器從而使其他的控制器具有自動擴展的功能】

應(yīng)用的資源使用率通常都有高峰和低谷的時候寂纪，如何削峰填谷席吴，提高集群的整體資源利用率，讓service中的Pod個數(shù)自動調(diào)整呢捞蛋？這就有賴于Horizontal Pod Autoscaling了孝冒，顧名思義，使Pod水平自動縮放

資源控制器之ReplicationController拟杉、ReplicaSet和Deployment

1庄涡、ReplicationController和ReplicaSet介紹

RC（ReplicationController）主要的作用就是用來確保容器應(yīng)用的副本數(shù)始終保持在用戶定義的副本數(shù)。即如果有容器異常退出搬设，會自動創(chuàng)建新的Pod來替代穴店；而如果異常多出來的容器也會自動回收
Kubernetes官方建議使用RS（Replicaset）替代RC（ReplicationController)進行部署，RS跟RC沒有本質(zhì)的不同拿穴，只是名字不一樣泣洞，并且RS支持集合式的 selector

查看RS完整模板信息：kubectl explain rs
ReplicaSet資源文件示例

apiVersion: extensions/v1beta1
kind: ReplicaSet 
metadata:
  name: frontend 
spec:
  replicas: 3 #有3個副本
  selector: #標(biāo)簽選擇器
    matchLabels:
      tier: frontend 
  template: #模板
    metadata:
      1abels:
        tier: frontend 
    spec:
      containers:
      - name: php-redis 
        image: gcr.io/google_samples/gb-frontend:v3 
        env:
        - name: GET_HOSTS_FROM 
          value:dns 
        ports:
        - containerPort: 80

資源控制器所創(chuàng)建的pod，刪除后會被新建
kubectl get pod --show-labels 查看標(biāo)簽

2默色、Deployment介紹

RS 與 Deployment 的關(guān)聯(lián)

• ①定義Deployment來創(chuàng)建Pod和ReplicaSet
• ②滾動升級和回滾
• ③應(yīng)用擴容和縮容
• ④暫停和繼續(xù)Deployment

2.1、部署一個簡單的 Nginx 應(yīng)用

apiVersion: extensions/v1beta1 
kind: Deployment 
metadata:
  name: nginx-deployment 
spec:
  replicas: 3 
  template:
    metadata:
      labels:
        app: nginx 
    spec:
      containers:   
      - name: nginx 
        image: nginx:1.7.9 
        ports:
        - containerPort: 80

2.2創(chuàng)建

kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record 
## --record參數(shù)可以記錄命令吃度，我們可以很方便的查看每次 revision 的變化 更新的時候可以記錄狀態(tài)甩挫，每一步是使用什么命令進行更新的

2.3、擴容

kubectl scale deployment nginx-deployment --replicas 10

2.4规肴、如果集群支持horizontal pod autoscaling的話捶闸，還可以為Deployment設(shè)置自動擴展

kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80

2.5夜畴、更新容器中的鏡像

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

2.6拖刃、回滾

kubectl rollout undo deployment/nginx-deployment

2.7、使用edit命令編輯Deployment

kubectl edit deployment/nginx-deployment

2.8贪绘、查看rollout的狀態(tài)

kubectl rollout status deployment/nginx-deployment

2.9兑牡、查看歷史RS

kubectl get rs

3衣撬、Deployment 更新策略【如果我們需要更新時將會創(chuàng)建出兩個RS琐簇，其中舊的RS一次減少25%的pod而新的RS一次創(chuàng)建25%的pod 】

Deployment 可以保證在升級時只有一定數(shù)量的Pod是down的崇堰。默認(rèn)的虚青，它會確保至少有比期望的Pod數(shù)量少一個是up狀態(tài)（最多一個不可用）
Deployment同時也可以確保只創(chuàng)建出超過期望數(shù)量的一定數(shù)量的Pod。默認(rèn)的苞也，它會確保最多比期望的Pod數(shù)量多一個的Pod是up的（最多1個surge）
未來的Kuberentes 版本中洛勉，將從1-1變成25%-25%

kubectl describe deployments

4、Rollover（多個rollout并行）

假如您創(chuàng)建了一個有5個niginx:1.7.9 replica的 Deployment如迟，但是當(dāng)還只有3個nginx:1.7.9的 replica 創(chuàng)建出來的時候您就開始更新含有5個nginx:1.9.1 replica 的 Deployment收毫。在這種情況下，Deployment 會立即殺掉已創(chuàng)建的3個nginx:1.7.9的 Pod殷勘，并開始創(chuàng)建nginx:1.9.1的 Pod此再。它不會等到所有的5個nginx:1.7.9的Pod 都創(chuàng)建完成后才開始改變航道

5、回退Deployment

只要Deployment的rollout被觸發(fā)玲销，就會創(chuàng)建一個revision输拇。也就是說當(dāng)且僅當(dāng)Deployment的Pod template(如.spec.template)被更改，例如更新template中的label和容器鏡像時贤斜，就會創(chuàng)建出一個新的revision策吠。其他的更新，比如擴容Deployment不會創(chuàng)建revision-因此我們可以很方便的手動或者自動擴容蠢古。這意味著當(dāng)您回退到歷史revision時奴曙，只有Deployment中的Pod template部分才會回退

#設(shè)置鏡像
kubectl set image deployment/nginx-deployment nginx=nginx:1.91 
#查看當(dāng)前更新狀態(tài)
kubectl rollout status deployments nginx-deployment 
kubectl get pods 
#查看可回滾的歷史版本
kubectl rollout history deployment/nginx-deployment 
kubectl rollout undo deployment/nginx-deployment
##可以使用--revision參數(shù)指定回退到某個歷史版本 
kubectl rollout undo deployment/nginx-deployment --to-revision=2  
##暫停 deployment的更新
kubectl rollout pause deployment/nginx-deployment

您可以用kubectl rollout status 命令查看Deployment是否完成。如果 rollout成功完成草讶，kubect1rollout status 將返回一個0值的Exit Code

kubect1 rollout status deploy/nginx
echo $?

6洽糟、清理 Policy

您可以通過設(shè)置.spec.revisonHistoryLimit項來指定 deployment 最多保留多少 revision 歷史記錄。默認(rèn)的會保留所有的 revision堕战；如果將該項設(shè)置為0坤溃，Deployment 就不允許回退了

資源控制器之DaemonSet、Job和CronJob

1嘱丢、DaemonSet介紹薪介，什么是DaemonSet

DaemonSet 確保全部（或者一些）Node 上運行一個Pod的副本【注意主節(jié)點并不會參加調(diào)度】。當(dāng)有 Node 加入集群時越驻，也會為他們新增一個Pod汁政。當(dāng)有Node從集群移除時，這些Pod 也會被回收缀旁。刪除DaemonSet將會刪除它創(chuàng)建的所有Pod
使用DaemonSet的一些典型用法：

• 運行集群存儲 daemon记劈，例如在每個Node 上運行g(shù)lusterd、ceph
• 在每個Node 上運行日志收集 daemon并巍，例如fluentd目木、logstash
• 在每個Node 上運行監(jiān)控daemon，例如Prometheus Node Exporter懊渡、collectd刽射、Datadog代理军拟、New Relic 代理，或Ganglia gmond

DaemonSet資源文件示例

apiVersion: apps/v1 
kind: DaemonSet 
metadata:
  name: deamonset-example 
  labels: 
    app: daemonset 
spec:
  selector:
    matchLabels:
      name: deamonset-example 
  template:
    metadata:
      1abels: 
        name: deamonset-example 
    spec: 
      containers:
      - name: daemonset-example 
        image: fanqisoft/myapp:v1

Job介紹誓禁，什么是Job

Job負(fù)責(zé)批處理任務(wù)懈息，即僅執(zhí)行一次的任務(wù)，它保證批處理任務(wù)的一個或多個Pod成功結(jié)束
特殊說明

• spec.template格式同Pod
• RestartPolicy僅支持Never或OnFailure
• 單個Pod時摹恰，默認(rèn)Pod成功運行后Job即結(jié)束·
• spec.completions 標(biāo)志Job結(jié)束需要成功運行的Pod個數(shù)漓拾，默認(rèn)為1·
• spec.parallelism 標(biāo)志并行運行的Pod的個數(shù)，默認(rèn)為1
• spec.activeDeadlineseconds標(biāo)志失敗Pod的重試最大時間戒祠，超過這個時間不會繼續(xù)重試

Job資源文件示例

apiVersion: batch/v1 
kind: Job 
metadata:
  name:pi 
spec:
  template:
    metadata:
      name:pi 
    spec:
      containers:
      - name: pi 
        image: perl 
      command: ["per1","-Mbignum=bpi","-wle","print bpi(2000)"]
      restartPolicy: Never

CronJob

CronJob管理基于時間的Job骇两，即：

• 在給定時間點只運行一次
• 周期性地在給定時間點運行
  使用條件：當(dāng)前使用的Kubernetes 集群，版本>=1.8（對CronJob)
  典型的用法如下所示：
• 在給定的時間點調(diào)度Job運行
• 創(chuàng)建周期性運行的Job姜盈，例如：數(shù)據(jù)庫備份低千、發(fā)送郵件

CronJob Spec

• spec.template格式同Pod

• RestartPolicy僅支持Never或OnFailure

• 單個Pod時，默認(rèn)Pod成功運行后Job即結(jié)束·

• spec.completions標(biāo)志Job結(jié)束需要成功運行的Pod個數(shù)馏颂，默認(rèn)為1·

• spec.parallelism 標(biāo)志并行運行的Pod的個數(shù)示血，默認(rèn)為1

• spec.activeDeadlineSeconds 標(biāo)志失敗Pod的重試最大時間，超過這個時間不會繼續(xù)重試

• spec.schedule：調(diào)度救拉，必需字段难审，指定任務(wù)運行周期，格式同 Cron·

• spec.jobTemplate:Job模板亿絮，必需字段告喊，指定需要運行的任務(wù)，格式同Job

• spec.startingDeadlineSeconds:啟動Job的期限（秒級別）派昧，該字段是可選的黔姜。如果因為任何原因而錯過了被調(diào)度的時間，那么錯過執(zhí)行時間的Job將被認(rèn)為是失敗的蒂萎。如果沒有指定秆吵，則沒有期限

• spec.concurrencyPolicy:并發(fā)策略，該字段也是可選的五慈。它指定了如何處理被 Cron Job創(chuàng)建的Job的并發(fā)執(zhí)行纳寂。只允許指定下面策略中的一種：

• Allow（默認(rèn)）：允許并發(fā)運行Job
• Forbid：禁止并發(fā)運行，如果前一個還沒有完成泻拦，則直接跳過下一個
• Replace：取消當(dāng)前正在運行的Job毙芜，用一個新的來替換
  注意，當(dāng)前策略只能應(yīng)用于同一個CronJob創(chuàng)建的Job聪轿。如果存在多個Cron Job爷肝，它們創(chuàng)建的Job之間總是允許并發(fā)運行猾浦。

• spec.suspend：掛起陆错，該字段也是可選的灯抛。如果設(shè)置為true，后續(xù)所有執(zhí)行都會被掛起音瓷。它對已經(jīng)開始執(zhí)行的Job不起作用对嚼。默認(rèn)值為false。
• spec.successfulJobsHistoryLimit和.spec.failed]obsHistoryLimit:歷史限制绳慎，是可選的字段纵竖。它們指定了可以保留多少完成和失敗的Job。默認(rèn)情況下杏愤，它們分別設(shè)置為3和1靡砌。設(shè)置限制的值為e，相關(guān)類型的Job完成后將不會被保留珊楼。

CronJob資源文件示例

apiVersion: batch/v1beta1 
kind: CronJob 
metadata:
  name: he11o 
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox 
            args:
            - /bin/sh 
            - -c 
            - date;echo Hello from the Kubernetes cluster 
          restartPolicy: OnFailure

Cronjob本身的一些限制
創(chuàng)建Job操作應(yīng)該是冪等的
CronJob并不太好去判斷任務(wù)是否成功通殃，CronJob通過創(chuàng)建Job去完成任務(wù)，Job成功與否可以判斷厕宗，但CronJob無法鏈接到Job去獲取成功與否画舌，Cron只會定期的去創(chuàng)建Job，僅此而已已慢。

參考：
https://www.cnblogs.com/LiuQizhong/p/11551381.html

https://www.cnblogs.com/fanqisoft/p/11573458.html

https://www.cnblogs.com/fanqisoft/p/11577889.html