《Kubernetes》- 認識下Pod的管理者？
大家好，我是小菜，前面幾篇文章我們已經從 k8s 集群的搭建然后到 k8s 中NameSpace 再說到了 k8s 中 Pod 的使用，如果還干到意猶未盡，那么接下來的 Pod 控制器 同樣是一道硬菜！死鬼~看完記得給我來個三連哦！
本文主要介紹
k8s中pod控制器的使用如有需要，可以參考
如有幫助，不忘 點贊 ?
微信公眾號已開啟，小菜良記，沒關注的同學們記得關注哦！
前文回顧：
既然有 pod 的存在，那便需要對pod 進行管理，控制器又怎么了少的了，那么接下來的時間交給小菜，帶你一探到底！
Pod控制器
一、前頭預熱
我們已經清楚了Pod是 k8s 中最小的管理單元。想想我們之前是怎么創(chuàng)建 pod，動動小腦袋，隱約想起好像有3種方式！1. 命令式對象管理 2. 命令式對象配置 3. 聲明式對象配置 。如果能想到這三種，說明上篇沒白學！但是這三種的創(chuàng)建方式，我們都是圍繞 pod 展開的，不管是通過命令直接創(chuàng)建，還是通過 yaml文件配置完再生成，我們生成的 Kind 都是直接指明 Pod，仿佛我們對 pod 的認知也局限于此了。但是今天，小菜就帶你認識點不一樣的東西，我們可以通過 Pod管理器 來創(chuàng)建 pod！
1）概念
什么是 pod 控制器呢？上面只是簡單說了可以用來創(chuàng)建 pod，難道作用也僅此而已，那我何必又多此一舉呢~
Pod 控制器，意如其名。就是用來控制 pod的，它是作為管理 pod 的中間層，使用 pod 控制器之后，只需要告訴 pod 控制器，我想要幾個pod，想要什么樣的pod，它便會為我們創(chuàng)建出滿足條件的 pod，并確保每一個 pod 資源都是處于用戶期望的目標狀態(tài)，如果 pod 資源在運行中出現(xiàn)故障，它便會基于指定的策略重新編排 pod
相當于控制器也就是一個管家，可以更好的為我們管理 pod。
通過 pod 控制器創(chuàng)建的 pod還有個最大的不同點，那便是：如果通過直接創(chuàng)建出來的 pod，這種 pod 刪除后也就真的刪除了，不會重建。而通過 pod 控制器創(chuàng)建的pod，刪除后還會基于指定的策略重新創(chuàng)建！
pod控制器 也分為很多種類型，k8s 中支持的控制器類型如下：
ReplicaSet：保證副本數(shù)量一致維持在期望值，支持 pod 數(shù)量擴縮容 和 鏡像版本升級 Deployment： 通過控制 ReplicaSet 來控制 Pod，支持滾動升級和回退版本 Horizontal Pod Autoscaler：可以根據(jù)集群負載自動水平調整 pod 的數(shù)量 DaemonSet： 在集群中的指定 Node 上運行且僅運行一個副本，一般用于守護進程類的任務 Job：它創(chuàng)建出來的pod只要完成任務就會立即退出，不需要重啟或重建，用于執(zhí)行一次性任務 Cronjob： 它創(chuàng)建的pod負責周期性任務控制，不需要持續(xù)后臺運行 StatefulSet： 管理有狀態(tài)的應用
這么多控制器，看了也別慌，接下來我們一個個認識過去~
二、實際操作
1）ReplicaSet
ReplicaSet 簡稱 rs，它的主要作用便是保證一定數(shù)量的 pod 正常運行，它會持續(xù)監(jiān)聽這些pod的運行狀態(tài)，一旦 pod 發(fā)生故障，就會重啟或重建，同時它還支持對 pod 數(shù)量的擴縮容和鏡像版本的升降級。
我們來看下 RS 的資源清單：
apiVersion: apps/v1 # 版本號
kind: ReplicaSet # 類型
metadata: # 元數(shù)據(jù)信息
name: # 名稱
namespace: # 命名空間
labels: # 標簽
key: value
spec: # 詳細描述
replicas: # 副本數(shù)
selector: # 選擇器，通過它指定該控制器管理那些Pod
matchLabels: # labels 匹配規(guī)則
app:
matchExpressions:
- key: xxx
operator: xxx
values: ['xxx', 'xxx']
template: # 模板，當副本數(shù)量不足時，會根據(jù)以下模板創(chuàng)建Pod副本
metadata:
labels:
key: value
spec:
containers:
- name:
image:
ports:
- containerPort:
我們這里需要新了解的屬性如下：
spec.replicas： 副本數(shù)量。當前 rs 會創(chuàng)建出來的 pod 數(shù)量，默認為 1 spec.selector： 選擇器。建立 pod 控制器和 pod 之間的關聯(lián)關系，在 pod 模板上定義 label，在控制器上定義選擇器，就可以讓pod歸屬于哪個控制器底下 spec.template： 模板。當前控制器創(chuàng)建 pod 所使用的的模板，里面定義內容與上節(jié)說到的 pod 定義是一樣的
創(chuàng)建RS
我們編寫一個 yaml 試著創(chuàng)建一個 RS 控制器：
通過 kubectl create -f rs.yaml 后可以發(fā)現(xiàn)已經存在了兩個pod，說明副本數(shù)量生效，當我們刪除一個 pod，過一會便會自動啟動一個 pod！
擴縮容
既然 RS 創(chuàng)建的時候能控制 pod 的副本數(shù)量，當然在運行的時候也能夠動態(tài)擴縮容。
直接修改
我們通過以下命令，能夠直接編輯 rs 的yaml文件
kubectl edit rs rs-ctrl -n cbuc-test
將 replicas 數(shù)量改為 3，保存退出后，可以發(fā)現(xiàn)正在運行的pod 數(shù)量已經變成了 3 個。
命令修改
除了以上通過修改yaml的方式，我們也可以直接通過命令的方式修改
kubectl scale rs rs-ctrl --replicas=2 -n cbcu-test
以上命令我們是借助 scale 指令的幫助修改 pod 的副本數(shù)量。
鏡像更新
除了可以控制副本數(shù)量，還可以進行鏡像的升級。我們上面運行Pod使用的鏡像是 nginx:1.14.1 如果我們想要升級鏡像版本號同樣有兩種方法：
直接修改
我們通過以下命令，能夠直接編輯 rs 的yaml文件
kubectl edit rs rs-ctrl -n cbuc-test
編輯鏡像版本號后保存退出，可以發(fā)現(xiàn)正在運行的pod使用的鏡像已經變了
命令修改
處理以上通過修改yaml的方式，我們也可以直接通過命令的方式修改
kubectl set image rs rs-ctrl nginx=nginx:1.17.1 -n cbuc-test
格式如下：
kubectl set image rs 控制器名稱 容器名稱=鏡像名稱:鏡像版本 -n 命名空間
刪除鏡像
如果我們不想要使用該控制器了，最好的方式便是將其刪除。我們可以根據(jù)資源清單刪除
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 所有功能 支持發(fā)布的停止、繼續(xù) 支持滾動升級和回滾版本
三大利器，將開發(fā)拿捏死死地~我們來看下資源清單是如何配置的：
從資源清單中我們可以看出，ReplicaSet 中有的，Deployment 都有，而且還增加了許多屬性
創(chuàng)建Deploy
準備一份 deploy 資源清單：
然后通過 kubectl create -f deploy-ctrl.yaml 創(chuàng)建pod控制器，查看結果：
擴縮容
擴縮容的方式和 ReplicaSet 一樣，有兩種方式，這里簡單帶過
直接修改
kubectl edit deploy deploy-ctrl -n cbuc-test
將 replicas 數(shù)量改為 3，保存退出后，可以發(fā)現(xiàn)正在運行的pod 數(shù)量已經變成了 3 個。
命令修改
kubectl scale deploy deploy-ctrll --replicas=2 -n cbcu-test
鏡像更新
Deployment支持兩種更新策略: 重建更新和滾動更新 ，可以通過 strategy 指定策略類型,支持兩個屬性:
strategy： # 指定新的Pod替換舊的Pod的策略， 支持兩個屬性：
type： # 指定策略類型，支持兩種策略
Recreate： # 在創(chuàng)建出新的Pod之前會先殺掉所有已存在的Pod
RollingUpdate： # 滾動更新，就是殺死一部分，就啟動一部分，在更新過程中，存在兩個版本Pod
rollingUpdate： # 當type為RollingUpdate時生效，用于為RollingUpdate設置參數(shù)，支持兩個屬性
maxUnavailable： # 用來指定在升級過程中不可用Pod的最大數(shù)量，默認為25%。
maxSurge： # 用來指定在升級過程中可以超過期望的Pod的最大數(shù)量，默認為25%。
正常來說 滾動更新 會比較友好，在更新過程中更加趨向于**“無感”**更新
版本回退
Deployment 還支持版本升級過程中的暫停、繼續(xù)以及版本回退等諸多功能，這些都與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
繼續(xù)已經暫停的版本升級過程
kubectl rollout resume deploy deploy-ctrl -ncbuc-test
status
顯示當前升級狀態(tài)
kubectl rollout status deploy deploy-ctrl -ncbuc-test
undo
回滾到上一級版本
kubectl rollout undo deploy deploy-ctrl -ncbuc-test
3）Horizontal Pod Autoscaler
看名字就感覺這個不簡單，該控制器簡稱 HPA ，我們之前是手動控制 pod 的擴容或縮容，但是這種方式并不智能，我們需要隨時隨地觀察資源狀態(tài)，然后控制副本數(shù)量，這是一個相當費時費力的工作~ 因此我們想要能夠存在一種能夠自動控制 Pod 數(shù)量的控制器來幫助我們監(jiān)測 pod 的使用情況，實現(xiàn) pod 數(shù)量的自動調整。而 K8s 也為我們提供了 Horizontal Pod Autoscaler - HPA
HPA 可以獲取每個 pod 的利用率， 然后和 HPS 中定義的指標進行對比，同時計算出需要伸縮的具體數(shù)量，然后對 pod 進行調整。
如果需要監(jiān)測 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
然后直接創(chuàng)建即可：
kubectl apply -f /root/metrics-server/deploy/1.8+/
安裝結束后我們便可以使用以下命令查看每個node的資源使用情況了
kubectl top node
查看pod資源使用情況
kubectl top pod -n cbuc-test
然后我們便可以創(chuàng)建 HPA，準備好資源清單：
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: hpa-ctrl
namespace: cbuc-test
spec:
minReplicas: 1 # 最小Pod數(shù)量
maxReplicas: 5 # 最大Pod數(shù)量
targetCPUUtilzationPercentage: 3 # CPU使用率指標
scaleTargetRef: # 指定要控制 deploy 的信息
apiVersion: apps/v1
kind: Deployment
name: deploy-ctrl
# 創(chuàng)建hpa
[root@master /]# kubectl create -f hpa-deploy.yaml
# 查看hpa
[root@master /]# kubectl get hpa -n dev
到這里我們就創(chuàng)建好了一個 HPA，它可以動態(tài)對 pod 進行擴縮容，這里就不做測試了，有興趣的同學可以進行壓測，看看結果是否如自己所期望的~
4）DaemonSet
DaemonSet 控制器簡稱 DS ，它的作用便是可以保證在集群中的每一臺（或指定）節(jié)點上都運行一個副本。這個作用場景一般是用來做日志采集或節(jié)點監(jiān)控。
如果一個Pod提供的功能是節(jié)點級別的（每個節(jié)點都需要且只需要一個），那么這類Pod就適合使用 DaemonSet 類型的控制器創(chuàng)建
特點：
每向集群添加一個節(jié)點時，指定的 Pod 副本也將會被添加到該節(jié)點上 當節(jié)點從集群中移除時，Pod 也將被回收
資源清單模板：
其實不難發(fā)現(xiàn)，該清單跟 Deployment 幾乎一致，因此我們不妨大膽猜測，這個控制器就是針對 Deployment 改良的懶人工具，可以自動幫我們創(chuàng)建Pod~
實戰(zhàn)清單：
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
通過該清單創(chuàng)建后，我們可以發(fā)現(xiàn)在每個 Node 節(jié)點上都創(chuàng)建了 nginx pod~
5）Job
Job，意如其名，該控制器的任務便是 負責批量處理（一次要處理指定數(shù)量任務）短暫的一次性（每個任務僅運行一次就結束）的任務。
特點：
當Job創(chuàng)建的Pod執(zhí)行成功結束時，Job會記錄成功結束的pod數(shù)量 當成功結束的pod達到指定的數(shù)量時，Job將完成執(zhí)行
資源清單模板：
這里重啟策略是必須指明的，且只能為 Never 或 OnFailure，原因如下：
如果指定為OnFailure，則job會在pod出現(xiàn)故障時重啟容器，而不是創(chuàng)建pod，failed次數(shù)不變 如果指定為Never，則job會在pod出現(xiàn)故障時創(chuàng)建新的pod，并且故障pod不會消失，也不會重啟，failed次數(shù)加1 如果指定為Always的話，就意味著一直重啟，意味著job任務會重復去執(zhí)行了，當然不對，所以不能設置為 Always
實戰(zhàn)清單：
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狀態(tài)可以看到，pod在運行完畢任務后，就會變成Completed狀態(tài)
6）CronJob
CronJob控制器簡稱 CJ，它的作用是以 Job 控制器為管理單位，借助它管理 pod 資源對象。Job 控制器定義的任務在創(chuàng)建時便會立刻執(zhí)行，但 cronJob 控制器可以控制其運行的 時間點及 重復運行 的方式。
資源清單模板：
其中 并發(fā)執(zhí)行策略 有以下幾種：
Allow： 允許 Jobs 并發(fā)運行 Forbid： 禁止并發(fā)運行，如果上一次運行尚未完成，則跳過下一次運行 Replace： 替換，取消當前正在運行的作業(yè)并用新作業(yè)替換它
實戰(zhàn)清單：
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"]
從結果上看我們也已經成功實現(xiàn)了定時任務，每秒執(zhí)行了一次~
這篇我們介紹了 Pod 控制器的使用，一共有 6種控制器，不知道看完后，你還記住幾種呢~老樣子，實踐出真知，凡事還是要上手練習才能記得更牢哦~ K8s 仍未結束，我們還有 Service、Ingress和 Volumn 還沒介紹！路漫漫，小菜與你一同求索~
今天的你多努力一點，明天的你就能少說一句求人的話！
我是小菜，一個和你一起學習的男人。
??微信公眾號已開啟，小菜良記，沒關注的同學們記得關注哦！