《Kubernetes》- 認識下Pod的管理者？

時間 2021-05-10

標籤 java node nginx git github shell vim api 微信併發欄目 Java 简体版

原文原文鏈接

你們好，我是小菜，前面幾篇文章咱們已經從 k8s 集羣的搭建而後到 k8s 中NameSpace 再說到了 k8s 中 Pod 的使用，若是還幹到意猶未盡，那麼接下來的 Pod 控制器 一樣是一道硬菜！
死鬼~看完記得給我來個三連哦！java

本文主要介紹 k8s中pod控制器的使用node

若有須要，能夠參考nginx

若有幫助，不忘點贊 ❥git

微信公衆號已開啓，小菜良記，沒關注的同窗們記得關注哦！github

前文回顧：shell

既然有 pod 的存在，那便須要對pod 進行管理，控制器又怎麼了少的了，那麼接下來的時間交給小菜，帶你一探到底！vim

Pod控制器

1、前頭預熱

咱們已經清楚了Pod是 k8s 中最小的管理單元。想一想咱們以前是怎麼建立 pod，動動小腦殼，隱約想起好像有3種方式！1. 命令式對象管理 2. 命令式對象配置 3. 聲明式對象配置 。若是能想到這三種，說明上篇沒白學！可是這三種的建立方式，咱們都是圍繞 pod 展開的，無論是經過命令直接建立，仍是經過 yaml文件配置完再生成，咱們生成的 Kind 都是直接指明 Pod，彷彿咱們對 pod 的認知也侷限於此了。可是今天，小菜就帶你認識點不同的東西，咱們能夠經過 Pod管理器 來建立 pod！api

1）概念

什麼是 pod 控制器呢？上面只是簡單說了能夠用來建立 pod，難道做用也僅此而已，那我何須又畫蛇添足呢~微信

Pod 控制器，意如其名。就是用來控制 pod的，它是做爲管理 pod 的中間層，使用 pod 控制器以後，只須要告訴 pod 控制器，我想要幾個pod，想要什麼樣的pod，它便會爲咱們建立出知足條件的 pod，並確保每個 pod 資源都是處於用戶指望的目標狀態，若是 pod 資源在運行中出現故障，它便會基於指定的策略從新編排 pod

至關於控制器也就是一個管家，能夠更好的爲咱們管理 pod。併發

經過 pod 控制器建立的 pod還有個最大的不一樣點，那即是：若是經過直接建立出來的 pod，這種 pod 刪除後也就真的刪除了，不會重建。而經過 pod 控制器建立的pod，刪除後還會基於指定的策略從新建立！

pod控制器 也分爲不少種類型，k8s 中支持的控制器類型以下：

ReplicaSet：保證副本數量一致維持在指望值，支持 pod 數量擴縮容和鏡像版本升級
Deployment： 經過控制 ReplicaSet 來控制 Pod，支持滾動升級和回退版本
Horizontal Pod Autoscaler：能夠根據集羣負載自動水平調整 pod 的數量
DaemonSet： 在集羣中的指定 Node 上運行且僅運行一個副本，通常用於守護進程類的任務
Job：它建立出來的pod只要完成任務就會當即退出，不須要重啓或重建，用於執行一次性任務
Cronjob： 它建立的pod負責週期性任務控制，不須要持續後臺運行
StatefulSet： 管理有狀態的應用

這麼多控制器，看了也別慌，接下來咱們一個個認識過去~

2、實際操做

1）ReplicaSet

ReplicaSet 簡稱 rs，它的主要做用即是保證必定數量的 pod 正常運行，它會持續監聽這些pod的運行狀態，一旦 pod 發生故障，就會重啓或重建，同時它還支持對 pod 數量的擴縮容和鏡像版本的升降級。

咱們來看下 RS 的資源清單：

apiVersion: apps/v1   # 版本號
kind: ReplicaSet       # 類型
metadata:             # 元數據信息
  name:               # 名稱
  namespace:          # 命名空間
  labels:             # 標籤
    key: value
spec:                  # 詳細描述
  replicas:           # 副本數
  selector:           # 選擇器，經過它指定該控制器管理那些Pod
    matchLabels:      # labels 匹配規則
      app: 
    matchExpressions:
    - key: xxx
      operator: xxx
      values: ['xxx', 'xxx']
  template:       # 模板，當副本數量不足時，會根據如下模板建立Pod副本
    metadata:
      labels:
        key: value
    spec:
      containers:
      - name: 
        image:
        ports:
        - containerPort:

咱們這裏須要新瞭解的屬性以下：

spec.replicas： 副本數量。當前 rs 會建立出來的 pod 數量，默認爲 1
spec.selector： 選擇器。創建 pod 控制器和 pod 之間的關聯關係，在 pod 模板上定義 label，在控制器上定義選擇器，就可讓pod歸屬於哪一個控制器底下
spec.template： 模板。當前控制器建立 pod 所使用的的模板，裏面定義內容與上節說到的 pod 定義是同樣的

建立RS

咱們編寫一個 yaml 試着建立一個 RS 控制器：

經過 kubectl create -f rs.yaml 後能夠發現已經存在了兩個pod，說明副本數量生效，當咱們刪除一個 pod，過一會便會自動啓動一個 pod！

擴縮容

既然 RS 建立的時候能控制 pod 的副本數量，固然在運行的時候也可以動態擴縮容。

直接修改

咱們經過如下命令，可以直接編輯 rs 的yaml文件

kubectl edit rs rs-ctrl -n cbuc-test

將 replicas 數量改成 3，保存退出後，能夠發現正在運行的pod 數量已經變成了 3 個。

命令修改

除了以上經過修改yaml的方式，咱們也能夠直接經過命令的方式修改

kubectl scale rs rs-ctrl --replicas=2 -n cbcu-test

以上命令咱們是藉助 scale 指令的幫助修改 pod 的副本數量。

鏡像更新

除了能夠控制副本數量，還能夠進行鏡像的升級。咱們上面運行Pod使用的鏡像是 nginx:1.14.1 若是咱們想要升級鏡像版本號一樣有兩種方法：

直接修改

咱們經過如下命令，可以直接編輯 rs 的yaml文件

kubectl edit rs rs-ctrl -n cbuc-test

編輯鏡像版本號後保存退出，能夠發現正在運行的pod使用的鏡像已經變了

命令修改

處理以上經過修改yaml的方式，咱們也能夠直接經過命令的方式修改

kubectl set image rs rs-ctrl nginx=nginx:1.17.1 -n cbuc-test

格式以下：

kubectl set image rs 控制器名稱 容器名稱=鏡像名稱:鏡像版本 -n 命名空間

刪除鏡像

若是咱們不想要使用該控制器了，最好的方式即是將其刪除。咱們能夠根據資源清單刪除

kubectl delete -f rs.yaml

也能夠直接刪除

kubectl delete deploy rs-ctrl -ncbuc-test

可是咱們須要清楚的是，默認狀況下，控制器刪除後，底下所控制的pod也會對應刪除，可是有時候咱們只是想單純的刪除控制器，而不想刪除pod，就得藉助命令選項--cascade=false

kubectl delete rs rs-ctrl -n cbuc-test --cascade=false

2）Deployment

Deployment 控制器簡稱 Deploy，這個控制器是在kubernetes v1.2版本以後開始引入的。這種控制器並非直接管理 pod，而是經過管理 ReplicaSet 控制器 來間接管理 pod

由圖可知，Deployment的功能只會更增強大：

支持 ReplicaSet 全部功能
支持發佈的中止、繼續
支持滾動升級和回滾版本

三大利器，將開發拿捏死死地~咱們來看下資源清單是如何配置的：

從資源清單中咱們能夠看出，ReplicaSet 中有的，Deployment 都有，並且還增長了許多屬性

建立Deploy

準備一份 deploy 資源清單：

而後經過 kubectl create -f deploy-ctrl.yaml 建立pod控制器，查看結果：

擴縮容

擴縮容的方式和 ReplicaSet 同樣，有兩種方式，這裏簡單帶過

直接修改

kubectl edit deploy deploy-ctrl -n cbuc-test

將 replicas 數量改成 3，保存退出後，能夠發現正在運行的pod 數量已經變成了 3 個。

命令修改

kubectl scale deploy deploy-ctrll --replicas=2 -n cbcu-test

鏡像更新

Deployment支持兩種更新策略: 重建更新和滾動更新 ，能夠經過 strategy 指定策略類型,支持兩個屬性:

strategy：            # 指定新的Pod替換舊的Pod的策略， 支持兩個屬性：
  type：                # 指定策略類型，支持兩種策略
    Recreate：         # 在建立出新的Pod以前會先殺掉全部已存在的Pod
    RollingUpdate：  # 滾動更新，就是殺死一部分，就啓動一部分，在更新過程當中，存在兩個版本Pod
  rollingUpdate：    # 當type爲RollingUpdate時生效，用於爲RollingUpdate設置參數，支持兩個屬性
    maxUnavailable： # 用來指定在升級過程當中不可用Pod的最大數量，默認爲25%。
    maxSurge：         # 用來指定在升級過程當中能夠超過時望的Pod的最大數量，默認爲25%。

正常來講 滾動更新 會比較友好，在更新過程當中更加趨向於「無感」更新

版本回退

Deployment 還支持版本升級過程當中的暫停、繼續以及版本回退等諸多功能，這些都與rollout有關：

使用方式：

history

顯示升級歷史記錄

kubectl rollout history deploy deploy-ctrl -ncbuc-test

pause

暫停版本升級過程

kubectl rollout pause deploy deploy-ctrl -ncbuc-test

restart

重啓版本升級過程

kubectl rollout restart deploy deploy-ctrl -ncbuc-test

resume

繼續已經暫停的版本升級過程

kubectl rollout resume deploy deploy-ctrl -ncbuc-test

status

顯示當前升級狀態

kubectl rollout status deploy deploy-ctrl -ncbuc-test

undo

回滾到上一級版本

kubectl rollout undo deploy deploy-ctrl -ncbuc-test

3）Horizontal Pod Autoscaler

看名字就感受這個不簡單，該控制器簡稱 HPA ，咱們以前是手動控制 pod 的擴容或縮容，可是這中方式並不智能，咱們須要隨時隨地觀察資源狀態，而後控制副本數量，這是一個至關費時費力的工做~ 所以咱們想要可以存在一種可以自動控制 Pod 數量的控制器來幫助咱們監測 pod 的使用狀況，實現 pod 數量的自動調整。而 K8s 也爲咱們提供了 Horizontal Pod Autoscaler - HPA

HPA 能夠獲取每一個 pod 的利用率，而後和 HPS 中定義的指標進行對比，同時計算出須要伸縮的具體數量，而後對 pod 進行調整。

若是須要監測 pod 的負載狀況，咱們須要 metrics-server 的幫助，所以咱們首先須要先安裝 metrics-server

# 安裝git
yum install -y git
# 獲取mertrics-server
git clone -b v0.3.6 https://github.com/kubernetes-incubator/metrics-server
# 修改metrics-server deploy
vim /root/metrics-server/deploy/1.8+/metrics-server-deployment.yaml
# 添加下面選項
hostNetwork: true
image: registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server-amd64:v0.3.6
args:
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP

而後直接建立便可：

kubectl apply -f /root/metrics-server/deploy/1.8+/

安裝結束後咱們即可以使用如下命令查看每一個node的資源使用狀況了

kubectl top node

查看pod資源使用狀況

kubectl top pod -n cbuc-test

而後咱們即可以建立 HPA，準備好資源清單：

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-ctrl
  namespace: cbuc-test
spec:
  minReplicas: 1        # 最小Pod數量
  maxReplicas: 5           # 最大Pod數量
  targetCPUUtilzationPercentage: 3   # CPU使用率指標
  scaleTargetRef:         # 指定要控制 deploy 的信息
    apiVersion: apps/v1
    kind: Deployment
    name: deploy-ctrl

# 建立hpa
[root@master /]# kubectl create -f hpa-deploy.yaml
# 查看hpa
[root@master /]# kubectl get hpa -n dev

到這裏咱們就建立好了一個 HPA，它能夠動態對 pod 進行擴縮容，這裏就不作測試了，有興趣的同窗能夠進行壓測，看看結果是否如本身所指望的~

4）DaemonSet

DaemonSet 控制器簡稱 DS ，它的做用即是能夠保證在集羣中的每一臺（或指定）節點上都運行一個副本。這個做用場景通常是用來作日誌採集或節點監控。

若是一個Pod提供的功能是節點級別的（每一個節點都須要且只須要一個），那麼這類Pod就適合使用 DaemonSet 類型的控制器建立

特色：

每向集羣添加一個節點時，指定的 Pod 副本也將會被添加到該節點上
當節點從集羣中移除時，Pod 也將被回收

資源清單模板：

其實不難發現，該清單跟 Deployment 幾乎一致，所以咱們不妨大膽猜想，這個控制器就是針對 Deployment 改良的懶人工具，能夠自動幫咱們建立Pod~

實戰清單：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: pc-daemonset
  namespace: dev
spec:
  selector:
    matchLabels:
      app: nginx-pod
  template:
    metadata:
      labels:
        app: nginx-pod
      spec:
      containers:
      - name: nginx
        image: nginx:1.14-alpine

經過該清單建立後，咱們能夠發如今每一個 Node 節點上都建立了 nginx pod~

5）Job

Job，意如其名，該控制器的任務即是負責批量處理（一次要處理指定數量任務）短暫的一次性（每一個任務僅運行一次就結束）的任務。

特色：

當Job建立的Pod執行成功結束時，Job會記錄成功結束的pod數量
當成功結束的pod達到指定的數量時，Job將完成執行

資源清單模板：

這裏重啓策略是必須指明的，且只能爲 Never 或 OnFailure，緣由以下：

若是指定爲OnFailure，則job會在pod出現故障時重啓容器，而不是建立pod，failed次數不變

若是指定爲Never，則job會在pod出現故障時建立新的pod，而且故障pod不會消失，也不會重啓，failed次數加1

若是指定爲Always的話，就意味着一直重啓，意味着job任務會重複去執行了，固然不對，因此不能設置爲
Always

實戰清單：

apiVersion: batch/v1
kind: Job
metadata:
  name: job-ctrl
  namespace: cbuc-test
  labels:
    app: job-ctrl
spec:
  manualSelector: true
  selector:
    matchLabels:
      app: job-pod
  template:
    metadata:
      labels:
        app: job-pod
    spec:
      restartPolicy: Never
      containers:
      - name: test-pod
        image: cbuc/test/java:v1.0
        command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 2;done"]

經過觀察pod狀態能夠看到，pod在運行完畢任務後，就會變成Completed狀態

6）CronJob

CronJob控制器簡稱 CJ，它的做用是以 Job 控制器爲管理單位，藉助它管理 pod 資源對象。Job 控制器定義的任務在建立時便會馬上執行，但 cronJob 控制器能夠控制其運行的 時間點及 重複運行 的方式。

資源清單模板：

其中 併發執行策略 有如下幾種：

Allow： 容許 Jobs 併發運行
Forbid： 禁止併發運行，若是上一次運行還沒有完成，則跳過下一次運行
Replace： 替換，取消當前正在運行的做業並用新做業替換它

實戰清單：

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: cj-ctrl
  namespace: cbuc-test
  labels:
    controller: cronjob
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    metadata:
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
           - name: test
            image: cbuc/test/java:v1.0
            command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep3;done"]

從結果上看咱們也已經成功實現了定時任務，每秒執行了一次~

END

這篇咱們介紹了 Pod 控制器的使用，一共有 6種控制器，不知道看完後，你還記住幾種呢~老樣子，實踐出真知，凡事仍是要上手練習才能記得更牢哦~ K8s 仍未結束，咱們還有 Service、Ingress和 Volumn 還沒介紹！路漫漫，小菜與你一同求索~