k8s控制器——Replicaset和Deployment
我們在定義pod資源時，可以直接創(chuàng)建一個kind：Pod類型的自主式pod，但是這存在一個問題，假如pod被刪除了，那這個pod就不能自我恢復(fù)，就會徹底被刪除，線上這種情況非常危險，所以今天就給大家講解下pod的控制器，所謂控制器就是能夠管理pod，監(jiān)測pod運(yùn)行狀況，當(dāng)pod發(fā)生故障，可以自動恢復(fù)pod。也就是說能夠代我們?nèi)ス芾韕od中間層，并幫助我們確保每一個pod資源始終處于我們所定義或者我們所期望的目標(biāo)狀態(tài)，一旦pod資源出現(xiàn)故障，那么控制器會嘗試重啟pod或者里面的容器，如果一直重啟有問題的話那么它可能會基于某種策略來進(jìn)行重新布派或者重新編排；如果pod副本數(shù)量低于用戶所定義的目標(biāo)數(shù)量，它也會自動補(bǔ)全；如果多余，也會自動終止pod資源。
Replicaset控制器：概念、原理解讀
Replicaset概述
ReplicaSet是kubernetes中的一種副本控制器，簡稱rs，主要作用是控制由其管理的pod，使pod副本的數(shù)量始終維持在預(yù)設(shè)的個數(shù)。它的主要作用就是保證一定數(shù)量的Pod能夠在集群中正常運(yùn)行，它會持續(xù)監(jiān)聽這些Pod的運(yùn)行狀態(tài)，在Pod發(fā)生故障時重啟pod，pod數(shù)量減少時重新運(yùn)行新的 Pod副本。官方推薦不要直接使用ReplicaSet，用Deployments取而代之，Deployments是比ReplicaSet更高級的概念，它會管理ReplicaSet并提供很多其它有用的特性，最重要的是Deployments支持聲明式更新，聲明式更新的好處是不會丟失歷史變更。所以Deployment控制器不直接管理Pod對象，而是由 Deployment 管理ReplicaSet，再由ReplicaSet負(fù)責(zé)管理Pod對象。
Replicaset工作原理：如何管理Pod？
Replicaset核心作用在于代用戶創(chuàng)建指定數(shù)量的pod副本，并確保pod副本一直處于滿足用戶期望的數(shù)量， 起到多退少補(bǔ)的作用，并且還具有自動擴(kuò)容縮容等機(jī)制。
Replicaset控制器主要由三個部分組成：
1、用戶期望的pod副本數(shù)：用來定義由這個控制器管控的pod副本有幾個
2、標(biāo)簽選擇器：選定哪些pod是自己管理的，如果通過標(biāo)簽選擇器選到的pod副本數(shù)量少于我們指定的數(shù)量，需要用到下面的組件
3、pod資源模板：如果集群中現(xiàn)存的pod數(shù)量不夠我們定義的副本中期望的數(shù)量怎么辦，需要新建pod，這就需要pod模板，新建的pod是基于模板來創(chuàng)建的。
Replicaset資源清單文件編寫技巧
#查看定義Replicaset資源需要的字段有哪些？
[root@kaivimaster1 ~]# kubectl explain rs KIND: ReplicaSet VERSION: apps/v1 DESCRIPTION:ReplicaSet ensures that a specified number of pod replicas are running atany given time. FIELDS:apiVersion <string> #當(dāng)前資源使用的api版本，跟VERSION: apps/v1保持一致kind <string> #資源類型，跟KIND: ReplicaSet保持一致metadata <Object> #元數(shù)據(jù)，定義Replicaset名字的spec <Object> ##定義副本數(shù)、定義標(biāo)簽選擇器、定義Pod模板status <Object> #狀態(tài)信息，不能改#查看replicaset的spec字段如何定義？
[root@kaivimaster1 ~]# kubectl explain rs.spec KIND: ReplicaSet VERSION: apps/v1 RESOURCE: spec <Object> DESCRIPTION:Spec defines the specification of the desired behavior of the ReplicaSet.More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-statusReplicaSetSpec is the specification of a ReplicaSet. FIELDS:minReadySeconds <integer>replicas <integer> #定義的pod副本數(shù)，根據(jù)我們指定的值創(chuàng)建對應(yīng)數(shù)量的podselector <Object> -required- #用于匹配pod的標(biāo)簽選擇器template <Object> #定義Pod的模板，基于這個模板定義的所有pod是一樣的#查看replicaset的spec.template字段如何定義？
#對于template而言，其內(nèi)部定義的就是pod，pod模板是一個獨(dú)立的對象
通過上面可以看到，ReplicaSet資源中有兩個spec字段。第一個spec聲明的是ReplicaSet定義多少個Pod副本（默認(rèn)將僅部署1個Pod）、匹配Pod標(biāo)簽的選擇器、創(chuàng)建pod的模板。第二個spec是spec.template.spec：主要用于Pod里的容器屬性等配置。
.spec.template里的內(nèi)容是聲明Pod對象時要定義的各種屬性，所以這部分也叫做PodTemplate（Pod模板）。還有一個值得注意的地方是：在.spec.selector中定義的標(biāo)簽選擇器必須能夠匹配到spec.template.metadata.labels里定義的Pod標(biāo)簽，否則Kubernetes將不允許創(chuàng)建ReplicaSet。
Replicaset使用案例：部署Guestbook留言板
#把frontend.tar.gz上傳到kaivinode2和kaivinode1上，解壓
#編寫一個ReplicaSet資源清單
[root@kaivimaster1 ~]# cat replicaset.yaml apiVersion: apps/v1 kind: ReplicaSet metadata:name: frontendlabels:app: guestbooktier: frontend spec:replicas: 3selector:matchLabels:tier: frontendtemplate:metadata:labels:tier: frontendspec:containers:- name: php-redisimage: yecc/gcr.io-google_samples-gb-frontend:v3imagePullPolicy: IfNotPresent [root@kaivimaster1 ~]# kubectl apply -f replicaset.yaml replicaset.apps/frontend created [root@kaivimaster1 ~]# kubectl get rs NAME DESIRED CURRENT READY AGE frontend 3 3 3 53m [root@kaivimaster1 ~]# kubectl get pods NAME READY STATUS RESTARTS AGE frontend-82p9b 1/1 Running 0 36m frontend-j6twz 1/1 Running 0 36m frontend-lcnq6 1/1 Running 0 36m#pod的名字是由控制器的名字-隨機(jī)數(shù)組成的
#資源清單詳細(xì)說明
apiVersion: apps/v1 #ReplicaSet 這個控制器屬于的核心群組 kind: ReplicaSet #創(chuàng)建的資源類型 metadata:name: frontend #控制器的名字labels:app: guestbooktier: frontend spec:replicas: 3 #管理的pod副本數(shù)量selector:matchLabels:tier: frontend #管理帶有tier=frontend標(biāo)簽的podtemplate: #定義pod的模板metadata:labels:tier: frontend #pod標(biāo)簽，一定要有，這樣上面控制器就能找到它要管理的pod是哪些了spec:containers: #定義pod里運(yùn)行的容器- name: php-redis #定義容器的名字image: yecc/gcr.io-google_samples-gb-frontend:v3ports: #定義端口 - name: http #定義容器的名字 containerPort: 80 #定義容器暴露的端口Replicaset管理pod：擴(kuò)容、縮容、更新
#Replicaset實(shí)現(xiàn)pod的動態(tài)擴(kuò)容
ReplicaSet最核心的功能是可以動態(tài)擴(kuò)容和回縮，如果我們覺得兩個副本太少了，想要增加，只需要修改配置文件replicaset.yaml里的replicas的值即可，原來replicas: 3，現(xiàn)在變成replicaset: 4，修改之后，執(zhí)行如下命令更新：
[root@kaivimaster1 ~]# kubectl apply -f replicaset.yaml replicaset.apps/frontend configured[root@kaivimaster1 ~]# kubectl get rs NAME DESIRED CURRENT READY AGE frontend 4 4 4 62m[root@kaivimaster1 ~]# kubectl get pods NAME READY STATUS RESTARTS AGE frontend-82p9b 1/1 Running 0 62m frontend-j6twz 1/1 Running 0 62m frontend-kzjm7 1/1 Running 0 33s frontend-lcnq6 1/1 Running 0 62m也可以直接編輯控制器實(shí)現(xiàn)擴(kuò)容
kubectl edit rs frontend #這個是我們把請求提交給了apiserver，實(shí)時修改 [root@kaivimaster1 ~]# kubectl edit rs frontend
把上面的spec下的replicas 后面的值改成5，保存退出
#Replicaset實(shí)現(xiàn)pod的動態(tài)縮容
如果我們覺得5個Pod副本太多了，想要減少，只需要修改配置文件replicaset.yaml里的replicas的值即可，把replicaset：4變成replicas: 2，修改之后，執(zhí)行如下命令更新：
#Replicaset實(shí)現(xiàn)pod的更新
#把myapp-v2.tar.gz上傳到kaivinode1和kaivinode2上，手動解壓
#上面可以看到鏡像變成了ikubernetes/myapp:v2，說明滾動升級成功了
[root@kaivimaster1 ~]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES frontend-glb2c 1/1 Running 0 34s 10.244.209.133 kaivinode1 frontend-lck9t 1/1 Running 0 34s 10.244.187.74 kaivinode2 [root@kaivimaster1 ~]# curl 10.244.209.133 div style="width: 50%; margin-left: 20px"><h2>Guestbook</h2>[root@kaivimaster1 ~]# curl 10.244.209.74 div style="width: 50%; margin-left: 20px"><h2>Guestbook</h2>#上面可以看到雖然鏡像已經(jīng)更新了，但是原來的pod使用的還是之前的鏡像，新創(chuàng)建的pod才會使用最新的鏡像#10.244.209.133這個ip對應(yīng)的pod刪除
[root@kaivimaster1 ~]# kubectl delete pods frontend-glb2c pod "frontend-glb2c" deleted[root@kaivimaster1 ~]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE frontend-hkhdw 1/1 Running 0 15s 10.244.187.75 kaivinode2 frontend-lck9t 1/1 Running 0 2m37s 10.244.187.74 kaivinode2 #重新生成了一個新的pod：frontend-hkhdw [root@kaivimaster1 ~]# curl 10.244.187.75 Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a> #新生成的pod的鏡像已經(jīng)變成了myapp的，說明更新完成了#如果我們直接修改replicaset.yaml文件，把image: yecc/gcr.io-google_samples-gb-frontend:v3變成- image:
ikubernetes/myapp:v2 kubectl apply -f replicaset.yaml#發(fā)現(xiàn)原來的pod還是用的frontend:v3這個鏡像，沒有實(shí)現(xiàn)自動更新
生產(chǎn)環(huán)境如果升級，可以刪除一個pod，觀察一段時間之后沒問題再刪除另一個pod，但是這樣需要人工干預(yù)多次；實(shí)際生產(chǎn)環(huán)境一般采用藍(lán)綠發(fā)布，原來有一個rs1，再創(chuàng)建一個rs2（控制器），通過修改service標(biāo)簽，修改service可以匹配到rs2的控制器，這樣才是藍(lán)綠發(fā)布，這個也需要我們精心的部署規(guī)劃，我們有一個控制器就是建立在rs之上完成的，叫做Deployment
Deployment控制器：概念、原理解讀
Deployment官方文檔：
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
Deployment概述
Deployment是kubernetes中最常用的資源對象，為ReplicaSet和Pod的創(chuàng)建提供了一種聲明式的定義方法，在Deployment對象中描述一個期望的狀態(tài)，Deployment控制器就會按照一定的控制速率把實(shí)際狀態(tài)改成期望狀態(tài)，通過定義一個Deployment控制器會創(chuàng)建一個新的ReplicaSet控制器，通過ReplicaSet創(chuàng)建pod，刪除Deployment控制器，也會刪除Deployment控制器下對應(yīng)的ReplicaSet控制器和pod資源.
使用Deployment而不直接創(chuàng)建ReplicaSet是因?yàn)镈eployment對象擁有許多ReplicaSet沒有的特性，例如滾動升級和回滾。
擴(kuò)展：聲明式定義是指直接修改資源清單yaml文件，然后通過kubectl apply -f 資源清單yaml文件，就可以更改資源
Deployment控制器是建立在rs之上的一個控制器，可以管理多個rs，每次更新鏡像版本，都會生成一個新的rs，把舊的rs替換掉，多個rs同時存在，但是只有一個rs運(yùn)行。
rs v1控制三個pod，刪除一個pod，在rs v2上重新建立一個，依次類推，直到全部都是由rs v2控制，如果rs v2有問題，還可以回滾，Deployment是建構(gòu)在rs之上的，多個rs組成一個Deployment，但是只有一個rs處于活躍狀態(tài).
Deployment工作原理：如何管理rs和Pod？
Deployment可以使用聲明式定義，直接在命令行通過純命令的方式完成對應(yīng)資源版本的內(nèi)容的修改，也就是通過打補(bǔ)丁的方式進(jìn)行修改；Deployment能提供滾動式自定義自控制的更新；對Deployment來講，我們在實(shí)現(xiàn)更新時還可以實(shí)現(xiàn)控制更新節(jié)奏和更新邏輯。
互動：什么叫做更新節(jié)奏和更新邏輯呢？
比如說Deployment控制5個pod副本，pod的期望值是5個，但是升級的時候需要額外多幾個pod，那我們控制器可以控制在5個pod副本之外還能再增加幾個pod副本；比方說能多一個，但是不能少，那么升級的時候就是先增加一個，再刪除一個，增加一個刪除一個，始終保持pod副本數(shù)是5個；還有一種情況，最多允許多一個，最少允許少一個，也就是最多6個，最少4個，第一次加一個，刪除兩個，第二次加兩個，刪除兩個，依次類推，可以自己控制更新方式，這種滾動更新需要加readinessProbe和livenessProbe探測，確保pod中容器里的應(yīng)用都正常啟動了才刪除之前的pod。
啟動第一步，剛更新第一批就暫停了也可以；假如目標(biāo)是5個，允許一個也不能少，允許最多可以10個，那一次加5個即可；這就是我們可以自己控制節(jié)奏來控制更新的方法。
通過Deployment對象，你可以輕松的做到以下事情：
1、創(chuàng)建ReplicaSet和Pod
2、滾動升級（不停止舊服務(wù)的狀態(tài)下升級）和回滾應(yīng)用（將應(yīng)用回滾到之前的版本）
3、平滑地?cái)U(kuò)容和縮容
4、暫停和繼續(xù)Deployment
Deployment資源清單文件編寫技巧
#查看Deployment資源對象由哪幾部分組成
[root@kaivimaster1 ~]# kubectl explain deployment KIND: Deployment VERSION: apps/v1 DESCRIPTION:Deployment enables declarative updates for Pods and ReplicaSets. FIELDS:apiVersion <string> #該資源使用的api版本kind <string> #創(chuàng)建的資源是什么？metadata <Object> #元數(shù)據(jù)，包括資源的名字和名稱空間spec <Object> #定義容器的status <Object> #狀態(tài)，不可以修改#查看Deployment下的spec字段
[root@kaivimaster1 ~]# kubectl explain deployment.spec KIND: Deployment VERSION: apps/v1 RESOURCE: spec <Object> DESCRIPTION:Specification of the desired behavior of the Deployment.DeploymentSpec is the specification of the desired behavior of theDeployment. FIELDS:minReadySeconds <integer>#Kubernetes在等待設(shè)置的時間后才進(jìn)行升級
#如果沒有設(shè)置該值，Kubernetes會假設(shè)該容器啟動起來后就提供服務(wù)了
paused #暫停，當(dāng)我們更新的時候創(chuàng)建pod先暫停，不是立即更新
#k8s 在升級過程中有可能由于各種原因升級卡住（這個時候還沒有明確的升級失敗），比如在拉取被墻的鏡像，權(quán)限不夠等錯誤。那么這個時候就需要有個 deadline ，在 deadline 之內(nèi)如果還卡著，那么就上報這個情況，這個時候這個 Deployment 狀態(tài)就被標(biāo)記為 False，并且注明原因。但是它并不會阻止 Deployment 繼續(xù)進(jìn)行卡住后面的操作。完全由用戶進(jìn)行控制。
replicas <integer> #副本數(shù) revisionHistoryLimit <integer> #保留的歷史版本，默認(rèn)是10 selector <Object> -required- #標(biāo)簽選擇器，選擇它關(guān)聯(lián)的pod strategy <Object> #更新策略 template <Object> -required #定義的pod模板#查看Deployment下的spec.strategy字段
[root@kaivimaster1 ~]# kubectl explain deploy.spec.strategy KIND: Deployment VERSION: apps/v1 RESOURCE: strategy <Object> DESCRIPTION:The deployment strategy to use to replace existing pods with new ones.DeploymentStrategy describes how to replace existing pods with new ones. FIELDS:rollingUpdate <Object>type <string>Type of deployment. Can be "Recreate" or "RollingUpdate". Default isRollingUpdate.#支持兩種更新，Recreate和RollingUpdate
#Recreate是重建式更新，刪除一個更新一個
#RollingUpdate滾動更新，定義滾動更新方式，也就是pod能多幾個，少幾個
#查看Deployment下的spec.strategy.rollingUpdate字段
#我們更新的過程當(dāng)中最多允許超出的指定的目標(biāo)副本數(shù)有幾個；
它有兩種取值方式，第一種直接給定數(shù)量，第二種根據(jù)百分比，百分比表示原本是5個，最多可以超出20%，那就允許多一個，最多可以超過40%，那就允許多兩個
#最多允許幾個不可用
假設(shè)有5個副本，最多一個不可用，就表示最少有4個可用
#查看Deployment下的spec.template字段
#template為定義Pod的模板，Deployment通過模板創(chuàng)建Pod
deployment.spec.template為Pod定義的模板，和Pod定義不太一樣，template中不包含apiVersion和Kind屬性，要求必須有metadata。deployment.spec.template.spec為容器的屬性信息，其他定義內(nèi)容和Pod一致。
#查看Deployment下的spec.template.spec字段
[root@kaivimaster1 ~]# kubectl explain deploy.spec.template.spec KIND: Deployment VERSION: apps/v1 RESOURCE: spec <Object> DESCRIPTION:Specification of the desired behavior of the pod. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-statusPodSpec is a description of a pod. FIELDS:activeDeadlineSeconds <integer> #activeDeadlineSeconds表示Pod 可以運(yùn)行的最長時間，達(dá)到設(shè)置的該值后，Pod 會自動停止。affinity <Object> #定義親和性，跟直接創(chuàng)建pod時候定義親和性類似automountServiceAccountToken <boolean> #身份認(rèn)證相關(guān)的containers <[]Object> -required- #定義容器屬性dnsConfig <Object> #設(shè)置Pod的DNS dnsConfig:nameservers:- 192.xxx.xxx.6searches:- kaivi.svc.cluster.local- my.dns.search.kaividnsPolicy <string> # dnsPolicy決定Pod 內(nèi)預(yù)設(shè)的DNS 配置策略None 無任何策略：使用自定義的策略
Default 默認(rèn)：使用宿主機(jī)的dns配置，/etc/resolv.conf
ClusterFirst 集群DNS優(yōu)先，與 Default 相反，會預(yù)先使用 kube-dns (或 CoreDNS ) 的信息當(dāng)預(yù)設(shè)置參數(shù)寫入到該 Pod 內(nèi)的DNS配置。
ClusterFirstWithHostNet 集群 DNS 優(yōu)先，并伴隨著使用宿主機(jī)網(wǎng)絡(luò)：同時使用 hostNetwork 與 kube-dns 作為 Pod 預(yù)設(shè) DNS 配置。
臨時容器與其他容器的不同之處在于，它們?nèi)鄙賹Y源或執(zhí)行的保證，并且永遠(yuǎn)不會自動重啟，因此不適用于構(gòu)建應(yīng)用程序。臨時容器使用與常規(guī)容器相同的 ContainerSpec 段進(jìn)行描述，但許多字段是不相容且不允許的。
臨時容器沒有端口配置，因此像 ports，livenessProbe，readinessProbe 這樣的字段是不允許的。
Pod 資源分配是不可變的，因此 resources 配置是不允許的。
臨時容器用途：
當(dāng)由于容器崩潰或容器鏡像不包含調(diào)試應(yīng)用程序而導(dǎo)致 kubectl exec 無用時，臨時容器對于交互式故障排查很有用。
#在真正刪除容器之前，K8S會先發(fā)終止信號（kill -15 {pid}）給容器，默認(rèn)30s
tolerations <[]Object> #定義容忍度topologySpreadConstraints <[]Objectvolumes <[]Object> #掛載存儲卷Deployment使用案例：創(chuàng)建一個web站點(diǎn)
deployment是一個三級結(jié)構(gòu)，deployment管理replicaset，replicaset管理pod，
例子：用deployment創(chuàng)建一個pod
#把myapp-blue-v1.tar.gz和myapp-blue-v2.tar.gz上傳到kaivinode1和kaivinode2上，手動解壓：
#kubectl apply：表示聲明式的定義，既可以創(chuàng)建資源，也可以動態(tài)更新資源
查看deploy狀態(tài)：
#創(chuàng)建的控制器名字是myapp-v1
1.NAME ：列出名稱空間中deployment的名稱。
2.READY：顯示deployment有多少副本數(shù)。它遵循ready/desired的模式。
3.UP-TO-DATE： 顯示已更新到所需狀態(tài)的副本數(shù)。
4.AVAILABLE： 顯示你的可以使用多少個應(yīng)用程序副本。
5.AGE ：顯示應(yīng)用程序已運(yùn)行的時間。
#創(chuàng)建deploy的時候也會創(chuàng)建一個rs（replicaset），67fd9fc9c8 這個隨機(jī)數(shù)字是我們引用pod的模板template的名字的hash值
1.NAME： 列出名稱空間中ReplicaSet資源
2.DESIRED：顯示應(yīng)用程序的所需副本數(shù)，這些副本數(shù)是在創(chuàng)建時定義的。這是所需的狀態(tài)。
3.CURRENT： 顯示當(dāng)前正在運(yùn)行多少個副本。
4.READY： 顯示你的用戶可以使用多少個應(yīng)用程序副本。
5.AGE ：顯示應(yīng)用程序已運(yùn)行的時間。
請注意，ReplicaSet的名稱始終設(shè)置為[DEPLOYMENT-NAME]-[RANDOM-STRING]。RANDOM-STRING是隨機(jī)生成的
kubectl get pods 顯示如下： myapp-v1-67fd9fc9c8-fcprr 1/1 Running 0 3s myapp-v1-67fd9fc9c8-hw4f9 1/1 Running 0 2m21s [root@kaivimaster1 ~]# kubectl get pods -o wide | grep myapp myapp-v1-67fd9fc9c8-fcprr 1/1 Running 0 10.244.187.78 kaivinode2 myapp-v1-67fd9fc9c8-hw4f9 1/1 Running 0 10.244.209.136 kaivinode1#請求剛才創(chuàng)建的pod資源
[root@kaivimaster1 ~]# curl 10.244.187.78background-color: blue;[root@kaivimaster1 ~]# curl 10.244.209.136background-color: blue;#資源清單文件詳細(xì)解讀
apiVersion: apps/v1 #deployment對應(yīng)的api版本 kind: Deployment #創(chuàng)建的資源是deployment metadata:name: myapp-v1 #deployment的名字 spec:replicas: 2 #deployment管理的pod副本數(shù)selector: #標(biāo)簽選擇器matchLabels: # matchLabels下定義的標(biāo)簽需要跟template.metadata.labels定義的標(biāo)簽一致app: myappversion: v1template:metadata:labels:app: myappversion: v1spec: #定義容器的屬性containers: - name: myappimage: janakiramm/myapp:v1 #容器使用的鏡像imagePullPolicy: IfNotPresent #鏡像拉取策略ports:- containerPort: 80 #容器里的應(yīng)用的端口Deployment管理pod：擴(kuò)容、縮容、滾動更新、回滾
#通過deployment管理應(yīng)用，實(shí)現(xiàn)擴(kuò)容，把副本數(shù)變成3
[root@kaivimaster1 ~]# cat deploy-demo.yaml 直接修改replicas數(shù)量，如下，變成3 spec:replicas: 3修改之后保存退出，執(zhí)行
[root@kaivimaster1 ~]# kubectl apply -f deploy-demo.yaml 注意：apply不同于create，apply可以執(zhí)行多次；create執(zhí)行一次，再執(zhí)行就會報錯復(fù)。 kubectl get pods 顯示如下： NAME READY STATUS RESTARTS AGE myapp-v1-67fd9fc9c8-fcprr 1/1 Running 0 15m myapp-v1-67fd9fc9c8-h9js5 1/1 Running 0 11s myapp-v1-67fd9fc9c8-hw4f9 1/1 Running 0 17m#上面可以看到pod副本數(shù)變成了3個
#查看myapp-v1這個控制器的詳細(xì)信息
#通過deployment管理應(yīng)用，實(shí)現(xiàn)縮容，把副本數(shù)變成2
[root@kaivimaster1 ~]# cat deploy-demo.yaml 直接修改replicas數(shù)量，如下，變成2 spec:replicas: 2修改之后保存退出，執(zhí)行
[root@kaivimaster1 ~]# kubectl apply -f deploy-demo.yaml [root@kaivimaster1 ~]# kubectl get pods NAME READY STATUS RESTARTS AGE myapp-v1-67fd9fc9c8-fcprr 1/1 Running 0 18m myapp-v1-67fd9fc9c8-hw4f9 1/1 Running 0 20m#通過deployment管理應(yīng)用，實(shí)現(xiàn)滾動更新
在一個終端窗口執(zhí)行如下： [root@kaivimaster1 ~]# kubectl get pods -l app=myapp -w #-w 持續(xù)追蹤監(jiān)控 NAME READY STATUS RESTARTS AGE myapp-v1-67fd9fc9c8-fcprr 1/1 Running 0 19m myapp-v1-67fd9fc9c8-hw4f9 1/1 Running 0 22m打開一個新的終端窗口更改鏡像版本，按如下操作：
[root@kaivimaster1 ~]# vim deploy-demo.yaml 把image: janakiramm/myapp:v1 變成image: janakiramm/myapp:v2 保存退出，執(zhí)行 [root@kaivimaster1 ~]# kubectl apply -f deploy-demo.yaml再回到剛才執(zhí)行監(jiān)測kubectl get pods -l app=myapp -w的那個窗口，可以看到信息如下：
NAME READY STATUS RESTARTS AGE myapp-v1-67fd9fc9c8-fcprr 1/1 Running 0 23m myapp-v1-67fd9fc9c8-hw4f9 1/1 Running 0 26m myapp-v1-75fb478d6c-fskpq 0/1 Pending 0 0s myapp-v1-75fb478d6c-fskpq 0/1 Pending 0 0s myapp-v1-75fb478d6c-fskpq 0/1 ContainerCreating 0 0s myapp-v1-75fb478d6c-fskpq 0/1 ContainerCreating 0 1s myapp-v1-75fb478d6c-fskpq 1/1 Running 0 4s myapp-v1-67fd9fc9c8-fcprr 1/1 Terminating 0 24m myapp-v1-75fb478d6c-x8stq 0/1 Pending 0 0s myapp-v1-75fb478d6c-x8stq 0/1 Pending 0 0s myapp-v1-75fb478d6c-x8stq 0/1 ContainerCreating 0 0s myapp-v1-67fd9fc9c8-fcprr 1/1 Terminating 0 24m myapp-v1-75fb478d6c-x8stq 0/1 ContainerCreating 0 1s myapp-v1-67fd9fc9c8-fcprr 0/1 Terminating 0 24m myapp-v1-75fb478d6c-x8stq 1/1 Running 0 1s myapp-v1-67fd9fc9c8-hw4f9 1/1 Terminating 0 26m myapp-v1-67fd9fc9c8-hw4f9 1/1 Terminating 0 26m myapp-v1-67fd9fc9c8-hw4f9 0/1 Terminating 0 26m myapp-v1-67fd9fc9c8-hw4f9 0/1 Terminating 0 26m myapp-v1-67fd9fc9c8-hw4f9 0/1 Terminating 0 26m myapp-v1-67fd9fc9c8-fcprr 0/1 Terminating 0 24m myapp-v1-67fd9fc9c8-fcprr 0/1 Terminating 0 24mpending表示正在進(jìn)行調(diào)度，ContainerCreating表示正在創(chuàng)建一個pod，running表示運(yùn)行一個pod，running起來一個pod之后再Terminating（停掉）一個pod，以此類推，直到所有pod完成滾動升級
在另外一個窗口執(zhí)行
[root@kaivimaster1 ~]# kubectl get rs 顯示如下： myapp-v1-67fd9fc9c8 0 0 0 27m myapp-v1-75fb478d6c 2 2 2 79s#上面可以看到rs有兩個，上面那個是升級之前的，已經(jīng)被停掉，但是可以隨時回滾
#查看myapp-v1這個控制器的歷史版本
#回滾
[root@kaivimaster1 ~]# kubectl rollout undo deployment myapp-v1 --to-revision=1 deployment.apps/myapp-v1 rolled back [root@kaivimaster1 ~]# kubectl rollout history deployment myapp-v1 deployment.apps/myapp-v1 REVISION CHANGE-CAUSE 2 <none> 3 <none>自定義滾動更新策略
maxSurge和maxUnavailable用來控制滾動更新的更新策略
取值范圍
數(shù)值
注意：兩者不能同時為0。
比例
注意：兩者不能同時為0。
建議配置
這是我們生產(chǎn)環(huán)境提供給用戶的默認(rèn)配置。即“一上一下，先上后下”最平滑原則：
1個新版本pod ready（結(jié)合readiness）后，才銷毀舊版本pod。此配置適用場景是平滑更新、保證服務(wù)平穩(wěn)，但也有缺點(diǎn)，就是“太慢”了。
總結(jié)：
maxUnavailable：和期望的副本數(shù)比，不可用副本數(shù)最大比例（或最大值），這個值越小，越能保證服務(wù)穩(wěn)定，更新越平滑；
maxSurge：和期望的副本數(shù)比，超過期望副本數(shù)最大比例（或最大值），這個值調(diào)的越大，副本更新速度越快。
自定義策略：
修改更新策略：maxUnavailable=1，maxSurge=1 [root@kaivimaster1 ~]# kubectl patch deployment myapp-v1 -p '{"spec":{"strategy":{"rollingUpdate": {"maxSurge":1,"maxUnavailable":1}}}}' -n blue-green查看myapp-v1這個控制器的詳細(xì)信息
[root@kaivimaster1 ~]# kubectl describe deployment myapp-v1 -n blue-green顯示如下： RollingUpdateStrategy: 1 max unavailable, 1 max surge上面可以看到RollingUpdateStrategy: 1 max unavailable, 1 max surge
這個rollingUpdate更新策略變成了剛才設(shè)定的，因?yàn)槲覀冊O(shè)定的pod副本數(shù)是3，1和1表示最少不能少于2個pod，最多不能超過4個pod
這個就是通過控制RollingUpdateStrategy這個字段來設(shè)置滾動更新策略的
Deployment資源清單詳解
apiVersion: apps/v1 kind: Deployment metadata:name: portalnamespace: ms spec:replicas: 1selector:matchLabels:project: msapp: portaltemplate:metadata:labels:project: ms app: portalspec:containers:- name: portalimage: kaivi/portal:v1imagePullPolicy: Alwaysports:- protocol: TCPcontainerPort: 8080 resources: #資源配額limits: #資源限制，最多可用的cpu和內(nèi)存cpu: 1memory: 1Girequests： #最少需要多少資源才可以運(yùn)行Podcpu: 0.5memory: 1GireadinessProbe:tcpSocket:port: 8080initialDelaySeconds: 60periodSeconds: 10livenessProbe:tcpSocket:port: 8080initialDelaySeconds: 60periodSeconds: 10livenessProbe:
#存活性探測
#用于判斷容器是否存活，即Pod是否為running狀態(tài)，如果LivenessProbe探針探測到容器不健康，則kubelet將kill掉容器，并根據(jù)容器的重啟策略是否重啟。如果一個容器不包含LivenessProbe探針，則Kubelet認(rèn)為容器的LivenessProbe探針的返回值永遠(yuǎn)成功。
tcpSocket:
port: 8080 #檢測8080端口是否存在
initialDelaySeconds: 60 #Pod啟動60s執(zhí)行第一次檢查
periodSeconds: 10 #第一次檢查后每隔10s檢查一次
readinessProbe:
#就緒性探測
有時候應(yīng)用程序可能暫時無法接受請求，比如Pod已經(jīng)Running了，但是容器內(nèi)應(yīng)用程序尚未啟動成功，在這種情況下，如果沒有ReadinessProbe，則Kubernetes認(rèn)為它可以處理請求了，然而此時，我們知道程序還沒啟動成功是不能接收用戶請求的，所以不希望kubernetes把請求調(diào)度給它，則使用ReadinessProbe探針。
ReadinessProbe和livenessProbe可以使用相同探測方式，只是對Pod的處置方式不同，ReadinessProbe是將Pod IP:Port從對應(yīng)的EndPoint列表中刪除，而livenessProbe則Kill容器并根據(jù)Pod的重啟策略來決定作出對應(yīng)的措施。
ReadinessProbe探針探測容器是否已準(zhǔn)備就緒，如果未準(zhǔn)備就緒則kubernetes不會將流量轉(zhuǎn)發(fā)給此Pod。
tcpSocket:port: 8080initialDelaySeconds: 60periodSeconds: 10#在Pod運(yùn)行過程中，K8S仍然會每隔10s檢測8080端口
總結(jié)
以上是生活随笔為你收集整理的k8s控制器——Replicaset和Deployment的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 111cccc
- 下一篇： esp32 cam 配网 实现视频传输