Kubernetes 中的控制器

Kubernetes 中的控制器

標籤（空格分隔）： kubernetes系列

---

• 一：kubernetes 中控制器
• 二：kubernetes 類型

---

一：kubernetes 中控制器

1.1 什麼是控制器

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

1.2 控制器類型

ReplicationController 和 ReplicaSet

Deployment

DaemonSet

StateFulSet

Job/CronJob

Horizontal Pod Autoscaling

---

1.2.1 ReplicationController 和 ReplicaSet

ReplicationController（RC）用來確保容器應用的副本數始終保持在用戶定義的副本數，即若是有容器異常退
出，會自動建立新的 Pod 來替代；而若是異常多出來的容器也會自動回收；
在新版本的 Kubernetes 中建議使用 ReplicaSet 來取代 ReplicationController 。ReplicaSet 跟
ReplicationController 沒有本質的不一樣，只是名字不同，而且 ReplicaSet 支持集合式的 selector  標籤

---

1.2.2 Deployment

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

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

編程：

命令式編程：它側重於如何實現程序，就像咱們剛接觸編程的時候那樣，咱們須要把程序的實現過程按照邏輯結果一步步寫下來

聲明式編程：它側重於定義想要什麼，而後告訴計算機／引擎，讓他幫你去實現
            結構化的查詢語句（T-sql）

申明式編程 （Deployment）  apply（優）    create
命令式 （rs）               create（優）   apply

---

RS 與 RC 與 Deployment 關聯:

RC （ReplicationController ）主要的做用就是用來確保容器應用的副本數始終保持在用戶定義的副本數 。即如
果有容器異常退出，會自動建立新的Pod來替代；而若是異常多出來的容器也會自動回收
Kubernetes 官方建議使用 RS（ReplicaSet ） 替代 RC （ReplicationController ） 進行部署，RS 跟 RC 沒有
本質的不一樣，只是名字不同，而且 RS 支持集合式的 selector

vim rs-deploy.yaml
---
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: myapp
        image: wangyanglinux/myapp:v1
        env:
        - name: GET_HOSTS_FROM
          value: dns
        ports:
        - containerPort: 80
---
kubectl apply -f rs-deploy.yaml

kubectl get pods

總結： 不少的rs 是標籤來控制的 一旦 rs 被刪除 pod 所對應的 定義標籤 pod都會被刪除

RS 與 Deployment 的關聯

部署一個nginx：

vim nginx-deploy.yaml
----
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: wangyanglinux/myapp:v1
        ports:
        - containerPort: 80
---
kubectl apply -f nginx-deploy.yaml --recond 

## --record參數能夠記錄命令，咱們能夠很方便的查看每次 revision 的變化

kubectl get pod 

kubectl get deploy

擴容方案：

kubectl scale deployment nginx-deployment --replicas 5

若是集羣支持 horizontal pod autoscaling 的話，還能夠爲Deployment設置自動擴展

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

---

更新鏡像也比較簡單
kubectl set image deployment/nginx-deployment nginx=wangyanglinux/myapp:v2

回滾：

kubectl rollout undo deployment/nginx-deployment

---

詳細的回滾更新操做：

kubectl set image deployment/nginx-deployment nginx=wangyanglinux:v2
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 的更新

能夠用 kubectl rollout status 命令查看 Deployment 是否完成。若是 rollout 成功完成， kubectl rollout
status 將返回一個0值的 Exit Code

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

上面的 返回碼，這個通常用於寫腳本

清理 Policy
您能夠經過設置 .spec.revisonHistoryLimit 項來指定 deployment 最多保留多少 revision 歷史記錄。默認的會
保留全部的 revision；若是將該項設置爲0，Deployment 就不容許回退了

---

1.2.3 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

守護進程 方案

---

vim daemonset.yaml
----
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
----
kubectl apply -f daemonset.yaml

kubectl get daemonset

kubectl delete daemonset --all

1.2.4 Job

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

特殊說明:

spec.template格式同Pod

RestartPolicy僅支持Never或OnFailure

單個Pod時，默認Pod成功運行後Job即結束

.spec.completions 標誌Job結束須要成功運行的Pod個數，默認爲1

.spec.parallelism 標誌並行運行的Pod的個數，默認爲1

spec.activeDeadlineSeconds 

標誌失敗Pod的重試最大時間，超過這個時間不會繼續重試

---

上傳 鏡像 Perl.tar.gz 到所有節點 

tar -zxvf Perl.tar.gz
docker load -i perl.tar 

docker tag perl:latest perl:v1

--------------------

vim job.yaml
----
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl:v1
        command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
---
查看日誌 表示 運行計算pi 的2000

kubectl apply -f job.yaml

1.2.5 CronJob

Cron Job 管理基於時間的 Job，即：
在給定時間點只運行一次
週期性地在給定時間點運行

使用前提條件：

**當前使用的 Kubernetes 集羣，版本 >= 1.8（對 CronJob）。對於先前版本的集羣，版本 <1.8，啓動 API Server時，經過傳遞選項  --runtime-config=batch/v2alpha1=true  能夠開啓 batch/v2alpha1
API**

典型的用法以下所示：
在給定的時間點調度 Job 運行
建立週期性運行的 Job，例如：數據庫備份、發送郵件

---

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

---

.spec.schedule ：調度，必需字段，指定任務運行週期，格式同 Cron

.spec.jobTemplate ：Job 模板，必需字段，指定須要運行的任務，格式同 Job

.spec.startingDeadlineSeconds ：啓動 Job 的期限（秒級別），該字段是可選的。若是由於任何緣由而錯
過了被調度的時間，那麼錯過執行時間的 Job 將被認爲是失敗的。若是沒有指定，則沒有期限

.spec.concurrencyPolicy ：併發策略，該字段也是可選的。它指定了如何處理被 Cron Job 建立的 Job 的
併發執行。只容許指定下面策略中的一種：
   Allow （默認）：容許併發運行 Job
   Forbid ：禁止併發運行，若是前一個尚未完成，則直接跳過下一個
   Replace ：取消當前正在運行的 Job，用一個新的來替換
注意，當前策略只能應用於同一個 Cron Job 建立的 Job。若是存在多個 Cron Job，它們建立的 Job 之間總
是容許併發運行。

.spec.suspend ：掛起，該字段也是可選的。若是設置爲  true ，後續全部執行都會被掛起。它對已經開始
執行的 Job 不起做用。默認值爲  false 。

.spec.successfulJobsHistoryLimit 和  .spec.failedJobsHistoryLimit ：歷史限制，是可選的字段。它
們指定了能夠保留多少完成和失敗的 Job。默認狀況下，它們分別設置爲  3 和  1 。設置限制的值爲  0 ，相
關類型的 Job 完成後將不會被保留。

---

vim cronjob.yaml

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

----
kubectl apply -f cronjob.yaml

kubectl get cronjob

kubectl get job

1.2.6 StatefulSet

StatefulSet 做爲 Controller 爲 Pod 提供惟一的標識。它能夠保證部署和 scale 的順序

StatefulSet是爲了解決有狀態服務的問題（對應Deployments和ReplicaSets是爲無狀態服務而設計），其應用場景包括：

 1.穩定的持久化存儲，即Pod從新調度後仍是能訪問到相同的持久化數據，基於PVC來實現

2. 穩定的網絡標誌，即Pod從新調度後其PodName和HostName不變，基於Headless 
Service（即沒有Cluster IP的Service）來實現

3. 有序部署，有序擴展，即Pod是有順序的，在部署或者擴展的時候要依據定義的順序依次依次進行（即從0到N-1，在下一個Pod運行以前全部以前的Pod必須都是Running和Ready狀態），基於init containers來實現

4. 有序收縮，有序刪除（即從N-1到0）

---

1.2.7 Horizontal Pod Autoscaling

應用的資源使用率一般都有高峯和低谷的時候，如何削峯填谷，提升集羣的總體資源利用率，讓service中的Pod
個數自動調整呢？這就有賴於Horizontal Pod Autoscaling了，顧名思義，使Pod水平自動縮放