K8S中五種控制器的介紹以及使用
k8s的控制器類型
Kubernetes中內(nèi)建了很多controller（控制器），這些相當于一個狀態(tài)機，用來控制Pod的具體狀態(tài)和行為
Deployment：適合無狀態(tài)的服務部署
StatefullSet：適合有狀態(tài)的服務部署
DaemonSet：一次部署，所有的node節(jié)點都會部署，例如一些典型的應用場景：
運行集群存儲 daemon，例如在每個Node上運行 glusterd、ceph
在每個Node上運行日志收集 daemon，例如 fluentd、 logstash
在每個Node上運行監(jiān)控 daemon，例如 Prometheus Node Exporter
Job：一次性的執(zhí)行任務
Cronjob：周期性的執(zhí)行任務
總體來說，K8S有五種控制器，分別對應處理無狀態(tài)應用、有狀態(tài)應用、守護型應用和批處理應用
pod與控制器之間的關系
controllers：在集群上管理和運行容器的對象通過label-selector相關聯(lián)
Pod通過控制器實現(xiàn)應用的運維，如伸縮，升級等
Deployment（無狀態(tài)化應用）
應用場景：web服務
Deployment中文意思為部署、調(diào)度，通過Deployment我們能操作RS（ReplicaSet），你可以簡單的理解為它是一種通過yml文件的聲明，在Deployment 文件里可以定義Pod數(shù)量、更新方式、使用的鏡像，資源限制等。無狀態(tài)應用都用Deployment來創(chuàng)建
通過Deployment對象，你可以輕松的做到以下事情：
- 創(chuàng)建ReplicaSet和Pod
- 滾動升級（不停止舊服務的狀態(tài)下升級）和回滾應用（將應用回滾到之前的版本）
- 平滑地擴容和縮容
- 暫停和繼續(xù)Deployment
Deployment創(chuàng)建
[root@master shuai]# vim nginx-delpoy.yaml
apiVersion: apps/v1
kind: Deployment '定義是Deployment'
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3 '副本數(shù)量為3'
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15.4
ports:
- containerPort: 80
'創(chuàng)建資源'
[root@master shuai]# kubectl apply -f nginx-delpoy.yaml
deployment.apps/nginx-deployment created
//Replicaset 是控制版本，副本數(shù)，回滾就是通過此來實現(xiàn)
'//查看所有資源'
[root@master shuai]# kubectl get all
NAME READY STATUS RESTARTS AGE
pod/nginx-deployment-d55b94fd-cndf2 1/1 Running 0 3m31s
pod/nginx-deployment-d55b94fd-ghlwk 1/1 Running 0 3m31s
pod/nginx-deployment-d55b94fd-tm4sw 1/1 Running 0 3m31s
pod/pod-example 1/1 Running 0 10h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 3d6h
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-deployment 3 3 3 3 3m31s
NAME DESIRED CURRENT READY AGE
replicaset.apps/nginx-deployment-d55b94fd 3 3 3 3m31s
查看控制器信息
kubectl deit deployment/nginx-deployment
.....省略信息.....
strategy:
rollingUpdate: '版本更新為滾動更新機制'
maxSurge: 25% '最大更新副本數(shù)是25%，最多擴容125%' '為了保持副本數(shù)量，增加的百分比同時要銷毀多少'
maxUnavailable: 25% '最大刪除副本是25%，最多縮容到75%'
type: RollingUpdate
...省略信息....
'執(zhí)行kubectl describe deploy nginx-deployment 也可以查看'
....省略信息....
RollingUpdateStrategy: 25% max unavailable, 25% max surge
查看歷史版本
[root@master shuai]# kubectl rollout history deploy/nginx-deployment
deployment.extensions/nginx-deployment
REVISION CHANGE-CAUSE
1 <none> '//這邊只有一個，證明還沒有滾動更新'
狀態(tài)與無狀態(tài)化對特點
無狀態(tài)服務的特點：
1）deployment 認為所有的pod都是一樣的
2）不用考慮順序的要求
3）不用考慮在哪個node節(jié)點上運行
4）可以隨意擴容和縮容
有狀態(tài)服務的特點：
1）實例之間有差別，每個實例都有自己的獨特性，元數(shù)據(jù)不同，例如etcd，zookeeper
2）實例之間不對等的關系，以及依靠外部存儲的應用。
Deployment的更新
如果想要讓 nginx pod 使用 nginx:1.9.1 的鏡像來代替原來的 nginx的鏡像，運行以下命令 [root@master ~]# kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 deployment.apps/nginx-deployment image updated 或者我們可以使用 edit 命令來編輯 Deployment，將image從nginx改寫成 nginx:1.9.1 kubectl edit deployment/nginx-deployment 查看更新進度 [root@master ~]# kubectl rollout status deployment/nginx-deployment Waiting for deployment "nginx-deployme
Deployment更新時會創(chuàng)建一個新的ReplicaSet，然后將新的ReplicaSet中的Pod慢慢擴容到指定的副本數(shù)，將舊的ReplicaSet慢慢縮容到0。因此，更新時總能夠確保舊的服務不會停止，這就是滾動更新。
Deployment的回滾
當我們像上文一樣更新了Deployment之后，我們發(fā)現(xiàn)nginx:1.9.1的鏡像不是很穩(wěn)定，因此想要修改回nginx:1.7.9的版本，此時我們不需要手動更改Deployment文件，而是利用Deployment的回滾功能。
使用rollout history命令查看Deployment的版本（revision）：
[root@master ~]# kubectl rollout history deployment/nginx-deployment deployment.apps/nginx-deployment REVISION CHANGE-CAUSE 1 kubectl create --filename=deploy.yml --record=true 2 kubectl create --filename=deploy.yml --record=true
因為我們創(chuàng)建 Deployment 的時候使用了 —recored 參數(shù)可以記錄命令，我們可以很方便的查看每次 revison 的變化。
查看單個 revision 的詳細信息：
[root@master ~]# kubectl rollout history deployment/nginx-deployment --revision=2
deployment.apps/nginx-deployment with revision #2
Pod Template:
Labels: app=nginx
pod-template-hash=658d7f4b4b
Annotations: kubernetes.io/change-cause: kubectl create --filename=deploy.yml --record=true
Containers:
nginx:
Image: nginx:1.9.1
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
可以使用rollout undo命令回滾到前一個revision
[root@master ~]# kubectl rollout undo deployment/nginx-deployment
deployment.apps/nginx-deployment rolled back
[root@master ~]# kubectl describe deployment/nginx-deployment
Name: nginx-deployment
Namespace: default
CreationTimestamp: Fri, 24 Dec 2021 22:24:10 +0800
Labels: <none>
Annotations: deployment.kubernetes.io/revision: 3kubernetes.io/change-cause: kubectl create --filename=deploy.yml --record=true
Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
也可以使用–to-revision參數(shù)指定某個歷史版本：
[root@master ~]# kubectl rollout undo deployment/nginx-deployment --to-revision=2
deployment.apps/nginx-deployment rolled back
[root@master ~]# kubectl describe deployment/nginx-deployment
Name: nginx-deployment
Namespace: default
CreationTimestamp: Fri, 24 Dec 2021 22:24:10 +0800
Labels: <none>
Annotations: deployment.kubernetes.io/revision: 4kubernetes.io/change-cause: kubectl create --filename=deploy.yml --record=true
Selector: app=nginx
Replicas: 3 desired | 3 updated | 4 total | 3 available | 1 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.9.1
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
你可以通過設置 .spec.revisonHistoryLimit 項來指定 deployment 最多保留多少 revison 歷史記錄。默認的會保留所有的 revision；如果將該項設置為 0，Deployment 就不允許回退了。
只有 Deployment 的 rollout 被觸發(fā)才會創(chuàng)建一個 revision！注意！當且僅當 Deployment 的 Pod template被更改，例如更新 template 中的 label 和容器鏡像時，才會觸發(fā)一個rollout，從而為Deployment創(chuàng)建出一個新的 revision。
rollout命令的更多用法：
- history（查看歷史版本）
- pause（暫停Deployment）
- resume（恢復暫停的Deployment）
- status（查看資源狀態(tài)）
- undo（回滾版本）
Job Controller負責根據(jù)Job Spec創(chuàng)建Pod，并持續(xù)監(jiān)控Pod的狀態(tài)，直至其成功結(jié)束。如果失敗，則根據(jù)restartPolicy（只支持OnFailure和Never，不支持Always）決定是否創(chuàng)建新的Pod再次重試任務。
Job負責批量處理短暫的一次性任務 (short lived one-off tasks)，即僅執(zhí)行一次的任務，它保證批處理任務的一個或多個Pod成功結(jié)束。
Kubernetes支持以下幾種Job：
- 非并行Job：通常創(chuàng)建一個Pod直至其成功結(jié)束
- 固定結(jié)束次數(shù)的Job：設置.spec.completions，創(chuàng)建多個Pod，直到.spec.completions個Pod成功結(jié)束
- 帶有工作隊列的并行Job：設置.spec.Parallelism但不設置.spec.completions，當所有Pod結(jié)束并且至少一個成功時，Job就認為是成功
- 根據(jù).spec.completions和.spec.Parallelism的設置，可以將Job劃分為以下幾種pattern
| JOB類型 | 使用實例 | 行為 | completions | parallelism |
|---|---|---|---|---|
| 一次性Job | 數(shù)據(jù)庫遷移 | 創(chuàng)建一個Pod直至其成功結(jié)束 | 1 | 1 |
| 固定結(jié)束次數(shù)的Job | 處理工作隊列的Pod | 依次創(chuàng)建一個Pod運行直至completions個成功結(jié)束 | 2+ | 1 |
| 固定結(jié)束次數(shù)的并行Job | 多個Pod同時處理工作隊列 | 依次創(chuàng)建多個Pod運行直至completions個成功結(jié)束 | 2+ | 2+ |
| 并行Job | 多個Pod同時處理工作隊列 | 創(chuàng)建一個或多個Pod直至有一個成功結(jié)束 | 1 | 2+ |
.job的使用
[root@master ~]# vi job.yml
---
apiVersion: batch/v1
kind: Job
metadata:
name: myjob
spec:
template:
spec:
containers:
- name: myjob
image: busybox
command: ["echo", "hello k8s job"]
restartPolicy: Never
[root@master ~]# kubectl apply -f job.yml
job.batch/myjob created
[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
myjob-gq27p 0/1 Completed 0 37s
#查看這個 pod的任務
[root@master ~]# kubectl get job
NAME COMPLETIONS DURATION AGE
myjob 1/1 19s 5m11s
#查看這個 pod的日志
[root@master ~]# kubectl logs myjob-gq27p
hello k8s job
CronJob控制器
CronJob 可以用來執(zhí)行基于時間計劃的定時任務，類似于Linux/Unix系統(tǒng)中的 crontable (opens new window)。
CronJob 執(zhí)行周期性的重復任務時非常有用，例如備份數(shù)據(jù)、發(fā)送郵件等。CronJob 也可以用來指定將來某個時間點執(zhí)行單個任務，例如將某項任務定時到系統(tǒng)負載比較低的時候執(zhí)行。
一個 CronJob 對象就像 crontab (cron table) 文件中的一行。 它用Cron格式進行編寫， 并周期性地在給定的調(diào)度時間執(zhí)行 Job。
注意：
- 所有 CronJob 的 schedule: 時間都是基于kube-controller-manager. 的時區(qū)。
- 如果你的控制平面在 Pod 或是裸容器中運行了 kube-controller-manager， 那么為該容器所設置的時區(qū)將會決定 Cron Job 的控制器所使用的時區(qū)。
- 為 CronJob 資源創(chuàng)建清單時，請確保所提供的名稱是一個合法的DNS 子域名. 名稱不能超過 52 個字符。 這是因為 CronJob 控制器將自動在提供的 Job 名稱后附加 11 個字符，并且存在一個限制， 即 Job 名稱的最大長度不能超過 63 個字符。
- CronJob 用于執(zhí)行周期性的動作，例如備份、報告生成等。 這些任務中的每一個都應該配置為周期性重復的（例如：每天/每周/每月一次）； 你可以定義任務開始執(zhí)行的時間間隔。
下面的 CronJob 示例清單會在每分鐘打印出當前時間和問候消息：
[root@master kubenetres]# vi cronjob.yml
---
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
imagePullPolicy: IfNotPresent
command:
- /bin/sh
- -c
- date; echo Hello nihao
restartPolicy: OnFailure
創(chuàng)建pod查看
[root@master ~]# kubectl apply -f cronjob.yml
Warning: batch/v1beta1 CronJob is deprecated in v1.21+, unavailable in v1.25+; use batch/v1 CronJob
cronjob.batch/hello created
#等一分鐘查看
[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-27339330-kkfxv 0/1 Completed 0 2s
#查看日志
[root@master ~]# kubectl logs hello-27339330-kkfxv
Fri Dec 24 15:30:00 UTC 2021
Hello nihao
總結(jié)
到此這篇關于K8S中五種控制器及使用的文章就介紹到這了,更多相關K8S控制器使用內(nèi)容請搜索本站以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持本站！
版權聲明：本站文章來源標注為YINGSOO的內(nèi)容版權均為本站所有，歡迎引用、轉(zhuǎn)載，請保持原文完整并注明來源及原文鏈接。禁止復制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務器上建立鏡像，否則將依法追究法律責任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學習參考，不代表本站立場，如有內(nèi)容涉嫌侵權，請聯(lián)系alex-e#qq.com處理。
關注官方微信