Kubernetes的Pod Deployment|DaemonSet|JobCronJob Controller

RS 與 RC 與 Deployment 關聯

RC （ReplicationController ）主要的作用就是用來確保容器應用的副本數始終保持在用戶定義的副本數 。即如果有容器異常退出，會自動創建新的Pod來替代；而如果異常多出來的容器也會自動回收

Kubernetes 官方建議使用 RS（ReplicaSet ） 替代 RC （ReplicationController ） 進行部署，RS 跟 RC 沒有本質的不同，只是名字不一樣，並且 RS 支持集合式的 selector

<code>
apiVersion:
 
extensions/v1beta1
kind:
 
ReplicaSet
metadata:
  
name:
 
frontend
spec:
  
replicas:
 
3
  
selector:
    
matchLabels:
      
tier:
 
frontend
  
template:
    
metadata:
      
labels:
        
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
/<code>

RS 與 Deployment 的關聯

Deployment

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

• 定義Deployment來創建Pod和ReplicaSet
• 滾動升級和回滾應用
• 擴容和縮容
• 暫停和繼續Deployment

Ⅰ、部署一個簡單的 Nginx 應用

<code>
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
/<code>

<code>kubectl 
create
 -f https://kubernetes.
io
/docs/user-guide/nginx-deployment.yaml  
##  
/<code>

Ⅱ、擴容

<code>kubectl scale deployment nginx-deployment  
/<code>

Ⅲ、如果集群支持 horizontal pod autoscaling 的話，還可以為Deployment設置自動擴展

<code>kubectl autoscale deployment nginx-deployment --
min
=
10
 --
max
= 
15
 --cpu-percent=
80
/<code>

Ⅳ、更新鏡像也比較簡單

<code>kubectl 
set
 image deployment/nginx-deployment nginx=nginx:1.9.1
/<code>

Ⅴ、回滾

<code>
kubectl
 rollout undo deployment/nginx-deployment
/<code>

更新 Deployment

假如我們現在想要讓 nginx pod 使用nginx:1.9.1的鏡像來代替原來的nginx:1.7.9的鏡像

<code>$ kubectl 
set
 image deployment/nginx-deployment nginx=nginx:
1.9
.1
deployment 
"nginx-deployment"
 image 
updated
/<code>

可以使用edit命令來編輯 Deployment

<code>$ kubectl edit deployment/nginx-deployment
deployment 
"nginx-deployment"
 edited
/<code>

查看 rollout 的狀態

<code>$ kubectl rollout status deployment/nginx-deployment
Waiting 
for
 rollout to finish: 
2 
 
out
 of 
3
 
new
 replicas have been updated...
deployment 
"nginx-deployment"
 successfully rolled 
out
/<code>

查看歷史 RS

<code>
$
 
kubectl
 
get
 
rs
NAME
                          
DESIRED
   
CURRENT
   
READY
   
AGE
nginx-deployment-1564180365
   
3
         
3
         
0
       
6s
nginx-deployment-2035384211
   
0
         
0
         
0 
       
36s
/<code>

Deployment 更新策略

Deployment 可以保證在升級時只有一定數量的 Pod 是 down 的。默認的，它會確保至少有比期望的Pod數量少一個是up狀態（最多一個不可用）

Deployment 同時也可以確保只創建出超過期望數量的一定數量的 Pod。默認的，它會確保最多比期望的Pod數量多一個的 Pod 是 up 的（最多1個 surge ）

未來的 Kuberentes 版本中，將從1-1變成25%-25%

<code>$ kubectl describe deployments
/<code>

Rollover（多個rollout並行）

假如您創建了一個有5個niginx:1.7.9 replica的 Deployment，但是當還只有3個nginx:1.7.9的 replica 創建出來的時候您就開始更新含有5個nginx:1.9.1 replica 的 Deployment。在這種情況下，Deployment 會立即殺掉已創建的3個nginx:1.7.9的 Pod，並開始創建nginx:1.9.1的 Pod。它不會等到所有的5個nginx:1.7.9的 Pod 都創建完成後才開始改變航道

回退 Deployment

<code>
kubectl
 
set image deployment/nginx-deployment nginx=nginx:1.91
kubectl
 
rollout status deployments nginx-deployment
 
kubectl
 
get pods
kubectl
 
rollout history deployment/nginx-deployment
kubectl
 
rollout undo deployment/nginx-deployment
kubectl
 
rollout undo deployment/nginx-deployment --to-revision=2   ## 可以使用 --revision參數指定某個歷史版本
kubectl
 
rollout pause deployment/nginx-deployment    ## 暫停 deployment 的更新
/<code>

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

<code>$ kubectl rollout status deploy/nginx
Waiting 
for
 rollout to 
finish:
 
2
 of 
3
 updated replicas are available...
deployment 
"nginx"
 successfully rolled out
$ echo $?
0
/<code>

清理 Policy

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

DaemonSet

DaemonSet 確保全部（或者一些）Node 上運行一個 Pod 的副本。當有 Node 加入集群時，也會為他們新增一個 Pod 。當有 Node 從集群移除時，這些 Pod 也會被回收。刪除 DaemonSet 將會刪除它創建的所有 Pod

使用 DaemonSet 的一些典型用法：

• 運行集群存儲 daemon，例如在每個 Node 上運行 glusterd、ceph
• 在每個 Node 上運行日誌收集 daemon，例如fluentd、logstash
• 在每個 Node 上運行監控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond

<code>
apiVersion
: apps/v1
kind
: DaemonSet
metadata
:
  
name
: deamonset-example
  
labels
:
    
app
: daemonset
spec
:
  
selector
:
    
matchLabels
:
      
name
: deamonset-example
  
template
:
    
metadata 
:
      
labels
:
        
name
: deamonset-example
    
spec
:
      
containers
:
      - 
name
: daemonset-example
        
image
: wangyanglinux/
myapp
:v1
/<code>

Job

Job 負責批處理任務，即僅執行一次的任務，它保證批處理任務的一個或多個 Pod 成功結束

特殊說明

• spec.template格式同Pod
• RestartPolicy僅支持Never或OnFailure
• 單個Pod時，默認Pod成功運行後Job即結束
• .spec.completions標誌Job結束需要成功運行的Pod個數，默認為1
• .spec.parallelism標誌並行運行的Pod的個數，默認為1
• spec.activeDeadlineSeconds標誌失敗Pod的重試最大時間，超過這個時間不會繼續重試

Example

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

CronJob Spec

• spec.template格式同Pod
• RestartPolicy僅支持Never或OnFailure
• 單個Pod時，默認Pod成功運行後Job即結束
• .spec.completions標誌Job結束需要成功運行的Pod個數，默認為1
• .spec.parallelism標誌並行運行的Pod的個數，默認為1
• spec.activeDeadlineSeconds標誌失敗Pod的重試最大時間，超過這個時間不會繼續重試

CronJob

Cron Job 管理基於時間的 Job，即：

• 在給定時間點只運行一次
• 週期性地在給定時間點運行

使用條件：當前使用的 Kubernetes 集群，版本 >= 1.8（對 CronJob）

典型的用法如下所示：

• 在給定的時間點調度 Job 運行
• 創建週期性運行的 Job，例如：數據庫備份、發送郵件

CronJob Spec

• .spec.schedule：調度，必需字段，指定任務運行週期，格式同 Cron
• .spec.jobTemplate：Job 模板，必需字段，指定需要運行的任務，格式同 Job
• .spec.startingDeadlineSeconds ：啟動 Job 的期限（秒級別），該字段是可選的。如果因為任何原因而錯過了被調度的時間，那麼錯過執行時間的 Job 將被認為是失敗的。如果沒有指定，則沒有期限
• .spec.concurrencyPolicy：併發策略，該字段也是可選的。它指定了如何處理被 Cron Job 創建的 Job 的併發執行。只允許指定下面策略中的一種：Allow（默認）：允許併發運行 JobForbid：禁止併發運行，如果前一個還沒有完成，則直接跳過下一個Replace：取消當前正在運行的 Job，用一個新的來替換注意，當前策略只能應用於同一個 Cron Job 創建的 Job。如果存在多個 Cron Job，它們創建的 Job 之間總是允許併發運行。
• .spec.suspend ：掛起，該字段也是可選的。如果設置為 true，後續所有執行都會被掛起。它對已經開始執行的 Job 不起作用。默認值為 false。
• .spec.successfulJobsHistoryLimit 和 .spec.failedJobsHistoryLimit ：歷史限制，是可選的字段。它們指定了可以保留多少完成和失敗的 Job。默認情況下，它們分別設置為 3 和 1。設置限制的值為 0，相關類型的 Job 完成後將不會被保留。

Example

<code>
apiVersion
: batch/v1beta1
kind
: CronJob
metadata 
:
  
name
: hello
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
/<code>

<code>
$
 
kubectl
 
get
 
cronjob 

NAME
      
SCHEDULE
      
SUSPEND
   
ACTIVE
    
LAST-SCHEDULE
hello
     
*/1
 
*
 
*
 
*
 
*
   
False
     
0
         

$
 
kubectl
 
get
 
jobs
NAME
               
DESIRED
   
SUCCESSFUL
   
AGE
hello-1202039034
   
1
         
1 
            
49s
$
 
pods=$(kubectl
 
get
 
pods
 
--selector=job-name=hello-1202039034
 
--output=jsonpath={.items..metadata.name})
$
 
kubectl
 
logs
 
$pods
Mon
 
Aug
 
29
 
21
:34:09
 
UTC
 
2016
Hello
 
from
 
the
 
Kubernetes
 
cluster

 
$
 
kubectl 
 
delete
 
cronjob
 
hello
cronjob
 
"hello"
 
deleted
/<code>

CrondJob 本身的一些限制

創建 Job 操作應該是 冪等的