1何恶、基礎(chǔ)架構(gòu)

1.1 Master

　　Master節(jié)點(diǎn)上面主要由四個(gè)模塊組成：APIServer、scheduler晓猛、controller manager翩伪、etcd。

APIServer眉尸。APIServer負(fù)責(zé)對(duì)外提供RESTful的Kubernetes API服務(wù)域蜗，它是系統(tǒng)管理指令的統(tǒng)一入口，任何對(duì)資源進(jìn)行增刪改查的操作都要交給APIServer處理后再提交給etcd噪猾。如架構(gòu)圖中所示霉祸，kubectl（Kubernetes提供的客戶(hù)端工具，該工具內(nèi)部就是對(duì)Kubernetes API的調(diào)用）是直接和APIServer交互的袱蜡。

schedule丝蹭。scheduler的職責(zé)很明確，就是負(fù)責(zé)調(diào)度pod到合適的Node上坪蚁。如果把scheduler看成一個(gè)黑匣子奔穿，那么它的輸入是pod和由多個(gè)Node組成的列表，輸出是Pod和一個(gè)Node的綁定迅细，即將這個(gè)pod部署到這個(gè)Node上巫橄。Kubernetes目前提供了調(diào)度算法，但是同樣也保留了接口茵典，用戶(hù)可以根據(jù)自己的需求定義自己的調(diào)度算法湘换。

controller manager。如果說(shuō)APIServer做的是“前臺(tái)”的工作的話(huà)，那controller manager就是負(fù)責(zé)“后臺(tái)”的彩倚。每個(gè)資源一般都對(duì)應(yīng)有一個(gè)控制器筹我，而controller manager就是負(fù)責(zé)管理這些控制器的。比如我們通過(guò)APIServer創(chuàng)建一個(gè)pod帆离，當(dāng)這個(gè)pod創(chuàng)建成功后蔬蕊，APIServer的任務(wù)就算完成了。而后面保證Pod的狀態(tài)始終和我們預(yù)期的一樣的重任就由controller manager去保證了哥谷。

etcd岸夯。etcd是一個(gè)高可用的鍵值存儲(chǔ)系統(tǒng)，Kubernetes使用它來(lái)存儲(chǔ)各個(gè)資源的狀態(tài)们妥，從而實(shí)現(xiàn)了Restful的API猜扮。

1.2 Node

　　每個(gè)Node節(jié)點(diǎn)主要由三個(gè)模塊組成：kubelet、kube-proxy监婶、runtime旅赢。

runtime。runtime指的是容器運(yùn)行環(huán)境惑惶，目前Kubernetes支持docker和rkt兩種容器煮盼。

kube-proxy。該模塊實(shí)現(xiàn)了Kubernetes中的服務(wù)發(fā)現(xiàn)和反向代理功能带污。反向代理方面：kube-proxy支持TCP和UDP連接轉(zhuǎn)發(fā)僵控，默認(rèn)基于Round Robin算法將客戶(hù)端流量轉(zhuǎn)發(fā)到與service對(duì)應(yīng)的一組后端pod。服務(wù)發(fā)現(xiàn)方面鱼冀，kube-proxy使用etcd的watch機(jī)制喉祭，監(jiān)控集群中service和endpoint對(duì)象數(shù)據(jù)的動(dòng)態(tài)變化，并且維護(hù)一個(gè)service到endpoint的映射關(guān)系雷绢，從而保證了后端pod的IP變化不會(huì)對(duì)訪問(wèn)者造成影響。另外kube-proxy還支持session affinity理卑。

kubelet翘紊。Kubelet是Master在每個(gè)Node節(jié)點(diǎn)上面的agent，是Node節(jié)點(diǎn)上面最重要的模塊藐唠，它負(fù)責(zé)維護(hù)和管理該Node上面的所有容器帆疟，但是如果容器不是通過(guò)Kubernetes創(chuàng)建的，它并不會(huì)管理宇立。本質(zhì)上踪宠，它負(fù)責(zé)使Pod得運(yùn)行狀態(tài)與期望的狀態(tài)一致。

至此妈嘹，Kubernetes的Master和Node就簡(jiǎn)單介紹完了柳琢。下面我們來(lái)看Kubernetes中的各種資源/對(duì)象。

2、Pod

　　Pod 是Kubernetes的基本操作單元柬脸，也是應(yīng)用運(yùn)行的載體他去。整個(gè)Kubernetes系統(tǒng)都是圍繞著Pod展開(kāi)的，比如如何部署運(yùn)行Pod倒堕、如何保證Pod的數(shù)量灾测、如何訪問(wèn)Pod等。另外垦巴，Pod是一個(gè)或多個(gè)機(jī)關(guān)容器的集合媳搪，這可以說(shuō)是一大創(chuàng)新點(diǎn)，提供了一種容器的組合的模型骤宣。

2.1 基本操作

創(chuàng)建kubectl create -f xxx.yaml

查詢(xún)kubectl get pod yourPodName

kubectl describe pod yourPodName

刪除kubectl delete pod yourPodName

更新kubectl replace /path/to/yourNewYaml.yaml

2.2 Pod與容器

　　在Docker中秦爆，容器是最小的處理單元，增刪改查的對(duì)象是容器涯雅，容器是一種虛擬化技術(shù)鲜结，容器之間是隔離的，隔離是基于Linux Namespace實(shí)現(xiàn)的活逆。而在Kubernetes中精刷，Pod包含一個(gè)或者多個(gè)相關(guān)的容器，Pod可以認(rèn)為是容器的一種延伸擴(kuò)展蔗候，一個(gè)Pod也是一個(gè)隔離體怒允，而Pod內(nèi)部包含的一組容器又是共享的（包括PID、Network锈遥、IPC纫事、UTS）。除此之外所灸，Pod中的容器可以訪問(wèn)共同的數(shù)據(jù)卷來(lái)實(shí)現(xiàn)文件系統(tǒng)的共享丽惶。

2.3 鏡像

　　在kubernetes中，鏡像的下載策略為：

Always：每次都下載最新的鏡像

Never：只使用本地鏡像爬立，從不下載

IfNotPresent：只有當(dāng)本地沒(méi)有的時(shí)候才下載鏡像

　　Pod被分配到Node之后會(huì)根據(jù)鏡像下載策略進(jìn)行鏡像下載钾唬，可以根據(jù)自身集群的特點(diǎn)來(lái)決定采用何種下載策略。無(wú)論何種策略侠驯，都要確保Node上有正確的鏡像可用抡秆。

2.4 其他設(shè)置

　　通過(guò)yaml文件，可以在Pod中設(shè)置：

啟動(dòng)命令吟策，如：spec-->containers-->command儒士；

環(huán)境變量，如：spec-->containers-->env-->name/value檩坚；

端口橋接着撩，如：spec-->containers-->ports-->containerPort/protocol/hostIP/hostPort（使用hostPort時(shí)需要注意端口沖突的問(wèn)題诅福，不過(guò)Kubernetes在調(diào)度Pod的時(shí)候會(huì)檢查宿主機(jī)端口是否沖突，比如當(dāng)兩個(gè)Pod均要求綁定宿主機(jī)的80端口睹酌，Kubernetes將會(huì)將這兩個(gè)Pod分別調(diào)度到不同的機(jī)器上）;

Host網(wǎng)絡(luò)权谁，一些特殊場(chǎng)景下，容器必須要以host方式進(jìn)行網(wǎng)絡(luò)設(shè)置（如接收物理機(jī)網(wǎng)絡(luò)才能夠接收到的組播流）憋沿，在Pod中也支持host網(wǎng)絡(luò)的設(shè)置旺芽，如：spec-->hostNetwork=true；

數(shù)據(jù)持久化辐啄，如：spec-->containers-->volumeMounts-->mountPath;

重啟策略采章，當(dāng)Pod中的容器終止退出后，重啟容器的策略壶辜。這里的所謂Pod的重啟悯舟，實(shí)際上的做法是容器的重建，之前容器中的數(shù)據(jù)將會(huì)丟失砸民，如果需要持久化數(shù)據(jù)抵怎，那么需要使用數(shù)據(jù)卷進(jìn)行持久化設(shè)置。Pod支持三種重啟策略：Always（默認(rèn)策略岭参，當(dāng)容器終止退出后反惕，總是重啟容器）、OnFailure（當(dāng)容器終止且異常退出時(shí)演侯，重啟）姿染、Never（從不重啟）；

2.5 Pod生命周期

　　Pod被分配到一個(gè)Node上之后秒际，就不會(huì)離開(kāi)這個(gè)Node悬赏，直到被刪除。當(dāng)某個(gè)Pod失敗娄徊，首先會(huì)被Kubernetes清理掉闽颇，之后ReplicationController將會(huì)在其它機(jī)器上（或本機(jī)）重建Pod，重建之后Pod的ID發(fā)生了變化寄锐，那將會(huì)是一個(gè)新的Pod进萄。所以，Kubernetes中Pod的遷移锐峭，實(shí)際指的是在新Node上重建Pod。以下給出Pod的生命周期圖可婶。

　　生命周期回調(diào)函數(shù)：PostStart（容器創(chuàng)建成功后調(diào)研該回調(diào)函數(shù)）沿癞、PreStop（在容器被終止前調(diào)用該回調(diào)函數(shù)）。以下示例中矛渴，定義了一個(gè)Pod椎扬，包含一個(gè)JAVA的web應(yīng)用容器惫搏，其中設(shè)置了PostStart和PreStop回調(diào)函數(shù)。即在容器創(chuàng)建成功后蚕涤，復(fù)制/sample.war到/app文件夾中筐赔。而在容器終止之前，發(fā)送HTTP請(qǐng)求到http://monitor.com:8080/waring揖铜，即向監(jiān)控系統(tǒng)發(fā)送警告茴丰。具體示例如下：

………..

containers:- image: sample:v2?

? ? name: war

? ? lifecycle：

? ? ? posrStart:

? ? ? exec:

? ? ? ? command:

? ? ? ? ? - “cp”

? ? ? ? ? - “/sample.war”

? ? ? ? ? - “/app”

? ? ? prestop:

? ? ? httpGet:

? ? ? ? host: monitor.com

? ? ? ? psth: /waring

? ? ? ? port: 8080? ? ? ? scheme: HTTP

3、Replication Controller

　　Replication Controller（RC）是Kubernetes中的另一個(gè)核心概念天吓，應(yīng)用托管在Kubernetes之后贿肩，Kubernetes需要保證應(yīng)用能夠持續(xù)運(yùn)行，這是RC的工作內(nèi)容龄寞，它會(huì)確保任何時(shí)間Kubernetes中都有指定數(shù)量的Pod在運(yùn)行汰规。在此基礎(chǔ)上，RC還提供了一些更高級(jí)的特性物邑，比如滾動(dòng)升級(jí)溜哮、升級(jí)回滾等。

3.1 RC與Pod的關(guān)聯(lián)——Label

　　RC與Pod的關(guān)聯(lián)是通過(guò)Label來(lái)實(shí)現(xiàn)的色解。Label機(jī)制是Kubernetes中的一個(gè)重要設(shè)計(jì)茂嗓，通過(guò)Label進(jìn)行對(duì)象的弱關(guān)聯(lián)，可以靈活地進(jìn)行分類(lèi)和選擇冒签。對(duì)于Pod在抛，需要設(shè)置其自身的Label來(lái)進(jìn)行標(biāo)識(shí)，Label是一系列的Key/value對(duì)萧恕，在Pod-->metadata-->labeks中進(jìn)行設(shè)置刚梭。

　　Label的定義是任一的，但是Label必須具有可標(biāo)識(shí)性票唆，比如設(shè)置Pod的應(yīng)用名稱(chēng)和版本號(hào)等朴读。另外Lable是不具有唯一性的，為了更準(zhǔn)確的標(biāo)識(shí)一個(gè)Pod走趋，應(yīng)該為Pod設(shè)置多個(gè)維度的label衅金。如下：

　　　　"release" : "stable", "release" : "canary"

　　　　"environment" : "dev", "environment" : "qa", "environment" : "production"

　　　　"tier" : "frontend", "tier" : "backend", "tier" : "cache"

　　　　"partition" : "customerA", "partition" : "customerB"

　　　　"track" : "daily", "track" : "weekly"

　　舉例，當(dāng)你在RC的yaml文件中定義了該RC的selector中的label為app:my-web簿煌，那么這個(gè)RC就會(huì)去關(guān)注Pod-->metadata-->labeks中l(wèi)abel為app:my-web的Pod氮唯。修改了對(duì)應(yīng)Pod的Label，就會(huì)使Pod脫離RC的控制姨伟。同樣惩琉，在RC運(yùn)行正常的時(shí)候，若試圖繼續(xù)創(chuàng)建同樣Label的Pod夺荒，是創(chuàng)建不出來(lái)的瞒渠。因?yàn)镽C認(rèn)為副本數(shù)已經(jīng)正常了良蒸，再多起的話(huà)會(huì)被RC刪掉的。

3.2 彈性伸縮

　　彈性伸縮是指適應(yīng)負(fù)載變化伍玖，以彈性可伸縮的方式提供資源嫩痰。反映到Kubernetes中，指的是可根據(jù)負(fù)載的高低動(dòng)態(tài)調(diào)整Pod的副本數(shù)量窍箍。調(diào)整Pod的副本數(shù)是通過(guò)修改RC中Pod的副本是來(lái)實(shí)現(xiàn)的串纺，示例命令如下：

　　擴(kuò)容Pod的副本數(shù)目到10

$ kubectl scale relicationcontroller yourRcName --replicas=10

　　縮容Pod的副本數(shù)目到1

$ kubectl scale relicationcontroller yourRcName --replicas=1

3.3 滾動(dòng)升級(jí)

　　滾動(dòng)升級(jí)是一種平滑過(guò)渡的升級(jí)方式，通過(guò)逐步替換的策略仔燕，保證整體系統(tǒng)的穩(wěn)定造垛，在初始升級(jí)的時(shí)候就可以及時(shí)發(fā)現(xiàn)、調(diào)整問(wèn)題晰搀，以保證問(wèn)題影響度不會(huì)擴(kuò)大五辽。Kubernetes中滾動(dòng)升級(jí)的命令如下：

$ kubectl rolling-update my-rcName-v1 -f my-rcName-v2-rc.yaml --update-period=10s

　　升級(jí)開(kāi)始后，首先依據(jù)提供的定義文件創(chuàng)建V2版本的RC外恕，然后每隔10s（--update-period=10s）逐步的增加V2版本的Pod副本數(shù)杆逗，逐步減少V1版本Pod的副本數(shù)。升級(jí)完成之后鳞疲，刪除V1版本的RC罪郊，保留V2版本的RC，及實(shí)現(xiàn)滾動(dòng)升級(jí)尚洽。

　　升級(jí)過(guò)程中悔橄，發(fā)生了錯(cuò)誤中途退出時(shí)，可以選擇繼續(xù)升級(jí)腺毫。Kubernetes能夠智能的判斷升級(jí)中斷之前的狀態(tài)癣疟，然后緊接著繼續(xù)執(zhí)行升級(jí)。當(dāng)然潮酒，也可以進(jìn)行回退睛挚，命令如下：

$ kubectl rolling-update my-rcName-v1 -f my-rcName-v2-rc.yaml --update-period=10s --rollback

回退的方式實(shí)際就是升級(jí)的逆操作，逐步增加V1.0版本Pod的副本數(shù)急黎，逐步減少V2版本Pod的副本數(shù)扎狱。

3.4 新一代副本控制器replica set

　　這里所說(shuō)的replica set，可以被認(rèn)為 是“升級(jí)版”的Replication Controller勃教。也就是說(shuō)淤击。replica set也是用于保證與label selector匹配的pod數(shù)量維持在期望狀態(tài)。區(qū)別在于故源，replica set引入了對(duì)基于子集的selector查詢(xún)條件遭贸，而Replication Controller僅支持基于值相等的selecto條件查詢(xún)。這是目前從用戶(hù)角度肴心软，兩者唯一的顯著差異壕吹。 社區(qū)引入這一API的初衷是用于取代vl中的Replication Controller，也就是說(shuō)．當(dāng)v1版本被廢棄時(shí)删铃，Replication Controller就完成了它的歷史使命耳贬，而由replica set來(lái)接管其工作。雖然replica set可以被單獨(dú)使用猎唁，但是目前它多被Deployment用于進(jìn)行pod的創(chuàng)建咒劲、更新與刪除。Deployment在滾動(dòng)更新等方面提供了很多非常有用的功能诫隅，關(guān)于DeplOymCn的更多信息腐魂，讀者們可以在后續(xù)小節(jié)中獲得。

4逐纬、Job

　　從程序的運(yùn)行形態(tài)上來(lái)區(qū)分蛔屹，我們可以將Pod分為兩類(lèi)：長(zhǎng)時(shí)運(yùn)行服務(wù)（jboss、mysql等）和一次性任務(wù)（數(shù)據(jù)計(jì)算豁生、測(cè)試）兔毒。RC創(chuàng)建的Pod都是長(zhǎng)時(shí)運(yùn)行的服務(wù)，而Job創(chuàng)建的Pod都是一次性任務(wù)甸箱。

　　在Job的定義中育叁，restartPolicy（重啟策略）只能是Never和OnFailure。Job可以控制一次性任務(wù)的Pod的完成次數(shù)（Job-->spec-->completions）和并發(fā)執(zhí)行數(shù)（Job-->spec-->parallelism）芍殖，當(dāng)Pod成功執(zhí)行指定次數(shù)后豪嗽，即認(rèn)為Job執(zhí)行完畢。

5豌骏、Service

　　為了適應(yīng)快速的業(yè)務(wù)需求龟梦，微服務(wù)架構(gòu)已經(jīng)逐漸成為主流，微服務(wù)架構(gòu)的應(yīng)用需要有非常好的服務(wù)編排支持肯适。Kubernetes中的核心要素Service便提供了一套簡(jiǎn)化的服務(wù)代理和發(fā)現(xiàn)機(jī)制变秦，天然適應(yīng)微服務(wù)架構(gòu)。

5.1 原理

　　在Kubernetes中框舔，在受到RC調(diào)控的時(shí)候蹦玫，Pod副本是變化的，對(duì)于的虛擬IP也是變化的刘绣，比如發(fā)生遷移或者伸縮的時(shí)候樱溉。這對(duì)于Pod的訪問(wèn)者來(lái)說(shuō)是不可接受的。Kubernetes中的Service是一種抽象概念纬凤，它定義了一個(gè)Pod邏輯集合以及訪問(wèn)它們的策略福贞，Service同Pod的關(guān)聯(lián)同樣是居于Label來(lái)完成的。Service的目標(biāo)是提供一種橋梁停士， 它會(huì)為訪問(wèn)者提供一個(gè)固定訪問(wèn)地址挖帘，用于在訪問(wèn)時(shí)重定向到相應(yīng)的后端完丽，這使得非 Kubernetes原生應(yīng)用程序，在無(wú)須為Kubemces編寫(xiě)特定代碼的前提下拇舀，輕松訪問(wèn)后端逻族。

　　Service同RC一樣，都是通過(guò)Label來(lái)關(guān)聯(lián)Pod的骄崩。當(dāng)你在Service的yaml文件中定義了該Service的selector中的label為app:my-web聘鳞，那么這個(gè)Service會(huì)將Pod-->metadata-->labeks中l(wèi)abel為app:my-web的Pod作為分發(fā)請(qǐng)求的后端。當(dāng)Pod發(fā)生變化時(shí)（增加要拂、減少抠璃、重建等），Service會(huì)及時(shí)更新脱惰。這樣一來(lái)搏嗡，Service就可以作為Pod的訪問(wèn)入口，起到代理服務(wù)器的作用枪芒，而對(duì)于訪問(wèn)者來(lái)說(shuō)彻况，通過(guò)Service進(jìn)行訪問(wèn)，無(wú)需直接感知Pod舅踪。

　　需要注意的是纽甘，Kubernetes分配給Service的固定IP是一個(gè)虛擬IP，并不是一個(gè)真實(shí)的IP抽碌，在外部是無(wú)法尋址的悍赢。真實(shí)的系統(tǒng)實(shí)現(xiàn)上，Kubernetes是通過(guò)Kube-proxy組件來(lái)實(shí)現(xiàn)的虛擬IP路由及轉(zhuǎn)發(fā)货徙。所以在之前集群部署的環(huán)節(jié)上左权，我們?cè)诿總€(gè)Node上均部署了Proxy這個(gè)組件，從而實(shí)現(xiàn)了Kubernetes層級(jí)的虛擬轉(zhuǎn)發(fā)網(wǎng)絡(luò)痴颊。

5.2 Service代理外部服務(wù)

　　Service不僅可以代理Pod赏迟，還可以代理任意其他后端，比如運(yùn)行在Kubernetes外部Mysql蠢棱、Oracle等锌杀。這是通過(guò)定義兩個(gè)同名的service和endPoints來(lái)實(shí)現(xiàn)的。示例如下：

redis-service.yaml

apiVersion: v1

kind: Service

metadata:

? name: redis-service

spec:

? ports:

? - port:6379? ? targetPort: 6379? ? protocol: TCP

redis-endpoints.yaml

apiVersion: v1

kind: Endpoints

metadata:

? name: redis-service

subsets:

? - addresses:

? ? - ip:10.0.251.145? ? ports:

? ? - port:6379? ? ? protocol: TCP

基于文件創(chuàng)建完Service和Endpoints之后泻仙，在Kubernetes的Service中即可查詢(xún)到自定義的Endpoints糕再。

[root@k8s-master demon]# kubectl describe service redis-service

Name:? ? ? ? ? ? redis-service

Namespace:? ? ? ? default

Labels:? ? ? ? ? ? Selector:? ? ? ? Type:? ? ? ? ? ? ClusterIP

IP:? ? ? ? ? ? 10.254.52.88Port:? ? ? ? ? ? 6379/TCP

Endpoints:? ? ? ? 10.0.251.145:6379Session Affinity:? ? None

No events.

[root@k8s-master demon]# etcdctl get /skydns/sky/default/redis-service

{"host":"10.254.52.88","priority":10,"weight":10,"ttl":30,"targetstrip":0}

5.3 Service內(nèi)部負(fù)載均衡

　　當(dāng)Service的Endpoints包含多個(gè)IP的時(shí)候，及服務(wù)代理存在多個(gè)后端玉转，將進(jìn)行請(qǐng)求的負(fù)載均衡突想。默認(rèn)的負(fù)載均衡策略是輪訓(xùn)或者隨機(jī)（有kube-proxy的模式?jīng)Q定）。同時(shí)，Service上通過(guò)設(shè)置Service-->spec-->sessionAffinity=ClientIP猾担，來(lái)實(shí)現(xiàn)基于源IP地址的會(huì)話(huà)保持袭灯。

5.4 發(fā)布Service

　　Service的虛擬IP是由Kubernetes虛擬出來(lái)的內(nèi)部網(wǎng)絡(luò)，外部是無(wú)法尋址到的绑嘹。但是有些服務(wù)又需要被外部訪問(wèn)到妓蛮，例如web前段。這時(shí)候就需要加一層網(wǎng)絡(luò)轉(zhuǎn)發(fā)圾叼，即外網(wǎng)到內(nèi)網(wǎng)的轉(zhuǎn)發(fā)。Kubernetes提供了NodePort捺癞、LoadBalancer夷蚊、Ingress三種方式。

NodePort髓介，在之前的Guestbook示例中惕鼓，已經(jīng)延時(shí)了NodePort的用法。NodePort的原理是唐础，Kubernetes會(huì)在每一個(gè)Node上暴露出一個(gè)端口：nodePort箱歧，外部網(wǎng)絡(luò)可以通過(guò)（任一Node）[NodeIP]:[NodePort]訪問(wèn)到后端的Service。

LoadBalancer一膨，在NodePort基礎(chǔ)上呀邢，Kubernetes可以請(qǐng)求底層云平臺(tái)創(chuàng)建一個(gè)負(fù)載均衡器，將每個(gè)Node作為后端豹绪，進(jìn)行服務(wù)分發(fā)价淌。該模式需要底層云平臺(tái)（例如GCE）支持。

Ingress瞒津，是一種HTTP方式的路由轉(zhuǎn)發(fā)機(jī)制蝉衣，由Ingress Controller和HTTP代理服務(wù)器組合而成。Ingress Controller實(shí)時(shí)監(jiān)控Kubernetes API巷蚪，實(shí)時(shí)更新HTTP代理服務(wù)器的轉(zhuǎn)發(fā)規(guī)則病毡。HTTP代理服務(wù)器有GCE Load-Balancer、HaProxy屁柏、Nginx等開(kāi)源方案啦膜。

5.5 servicede 自發(fā)性機(jī)制

　　Kubernetes中有一個(gè)很重要的服務(wù)自發(fā)現(xiàn)特性。一旦一個(gè)service被創(chuàng)建前联，該service的service IP和service port等信息都可以被注入到pod中供它們使用功戚。Kubernetes主要支持兩種service發(fā)現(xiàn) 機(jī)制：環(huán)境變量和DNS。

環(huán)境變量方式

　　Kubernetes創(chuàng)建Pod時(shí)會(huì)自動(dòng)添加所有可用的service環(huán)境變量到該P(yáng)od中似嗤，如有需要．這些環(huán)境變量就被注入Pod內(nèi)的容器里啸臀。需要注意的是，環(huán)境變量的注入只發(fā)送在Pod創(chuàng)建時(shí)，且不會(huì)被自動(dòng)更新乘粒。這個(gè)特點(diǎn)暗含了service和訪問(wèn)該service的Pod的創(chuàng)建時(shí)間的先后順序豌注，即任何想要訪問(wèn)service的pod都需要在service已經(jīng)存在后創(chuàng)建，否則與service相關(guān)的環(huán)境變量就無(wú)法注入該P(yáng)od的容器中灯萍，這樣先創(chuàng)建的容器就無(wú)法發(fā)現(xiàn)后創(chuàng)建的service轧铁。

DNS方式

Kubernetes集群現(xiàn)在支持增加一個(gè)可選的組件——DNS服務(wù)器。這個(gè)DNS服務(wù)器使用Kubernetes的watchAPI旦棉，不間斷的監(jiān)測(cè)新的service的創(chuàng)建并為每個(gè)service新建一個(gè)DNS記錄齿风。如果DNS在整個(gè)集群范圍內(nèi)都可用，那么所有的Pod都能夠自動(dòng)解析service的域名绑洛。Kube-DNS搭建及更詳細(xì)的介紹請(qǐng)見(jiàn)：基于Kubernetes集群部署skyDNS服務(wù)

5.6 多個(gè)service如何避免地址和端口沖突

　　此處設(shè)計(jì)思想是救斑，Kubernetes通過(guò)為每個(gè)service分配一個(gè)唯一的ClusterIP，所以當(dāng)使用ClusterIP：port的組合訪問(wèn)一個(gè)service的時(shí)候真屯，不管port是什么脸候，這個(gè)組合是一定不會(huì)發(fā)生重復(fù)的。另一方面绑蔫，kube-proxy為每個(gè)service真正打開(kāi)的是一個(gè)絕對(duì)不會(huì)重復(fù)的隨機(jī)端口运沦，用戶(hù)在service描述文件中指定的訪問(wèn)端口會(huì)被映射到這個(gè)隨機(jī)端口上。這就是為什么用戶(hù)可以在創(chuàng)建service時(shí)隨意指定訪問(wèn)端口配深。

5.7 service目前存在的不足

　　Kubernetes使用iptables和kube-proxy解析service的人口地址携添，在中小規(guī)模的集群中運(yùn)行良好，但是當(dāng)service的數(shù)量超過(guò)一定規(guī)模時(shí)凉馆，仍然有一些小問(wèn)題薪寓。首當(dāng)其沖的便是service環(huán)境變量泛濫，以及service與使用service的pod兩者創(chuàng)建時(shí)間先后的制約關(guān)系澜共。目前來(lái)看向叉，很多使用者在使用Kubernetes時(shí)往往會(huì)開(kāi)發(fā)一套自己的Router組件來(lái)替代service，以便更好地掌控和定制這部分功能嗦董。

6母谎、Deployment

　　Kubernetes提供了一種更加簡(jiǎn)單的更新RC和Pod的機(jī)制，叫做Deployment京革。通過(guò)在Deployment中描述你所期望的集群狀態(tài)奇唤，Deployment Controller會(huì)將現(xiàn)在的集群狀態(tài)在一個(gè)可控的速度下逐步更新成你所期望的集群狀態(tài)。Deployment主要職責(zé)同樣是為了保證pod的數(shù)量和健康匹摇，90%的功能與Replication Controller完全一樣咬扇，可以看做新一代的Replication Controller。但是廊勃，它又具備了Replication Controller之外的新特性：

Replication Controller全部功能：Deployment繼承了上面描述的Replication Controller全部功能懈贺。

事件和狀態(tài)查看：可以查看Deployment的升級(jí)詳細(xì)進(jìn)度和狀態(tài)经窖。

回滾：當(dāng)升級(jí)pod鏡像或者相關(guān)參數(shù)的時(shí)候發(fā)現(xiàn)問(wèn)題，可以使用回滾操作回滾到上一個(gè)穩(wěn)定的版本或者指定的版本梭灿。

版本記錄: 每一次對(duì)Deployment的操作画侣，都能保存下來(lái)，給予后續(xù)可能的回滾使用堡妒。

暫停和啟動(dòng)：對(duì)于每一次升級(jí)配乱，都能夠隨時(shí)暫停和啟動(dòng)。

多種升級(jí)方案：Recreate----刪除所有已存在的pod,重新創(chuàng)建新的; RollingUpdate----滾動(dòng)升級(jí)皮迟，逐步替換的策略搬泥，同時(shí)滾動(dòng)升級(jí)時(shí)，支持更多的附加參數(shù)伏尼，例如設(shè)置最大不可用pod數(shù)量佑钾，最小升級(jí)間隔時(shí)間等等。

6.1 滾動(dòng)升級(jí)

　　相比于RC烦粒，Deployment直接使用kubectl edit deployment/deploymentName 或者kubectl set方法就可以直接升級(jí)（原理是Pod的template發(fā)生變化，例如更新label代赁、更新鏡像版本等操作會(huì)觸發(fā)Deployment的滾動(dòng)升級(jí)）扰她。操作示例——首先 我們同樣定義一個(gè)nginx-deploy-v1.yaml的文件，副本數(shù)量為2：

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

? name: nginx-deployment

spec:

? replicas: 3? template:

? ? metadata:

? ? ? labels:

? ? ? ? app: nginx

? ? spec:

? ? ? containers:

? ? ? - name: nginx

? ? ? ? image: nginx:1.7.9? ? ? ? ports:

? ? ? ? - containerPort:80

　　創(chuàng)建deployment：

$ kubectl create -f nginx-deploy-v1.yaml --record

deployment "nginx-deployment" created

$ kubectl get deployments

NAME? ? ? DESIRED? CURRENT? UP-TO-DATE? AVAILABLE? AGE

nginx-deployment3000? ? ? ? ? 1s

$ kubectl get deployments

NAME? ? ? DESIRED? CURRENT? UP-TO-DATE? AVAILABLE? AGE

nginx-deployment333318s

　　正常之后芭碍，將nginx的版本進(jìn)行升級(jí)徒役，從1.7升級(jí)到1.9。第一種方法窖壕，直接set鏡像：

$ kubectl set image deployment/nginx-deployment2 nginx=nginx:1.9deployment "nginx-deployment2"image updated

　　第二種方法忧勿，直接edit：

$ kubectl edit deployment/nginx-deployment

deployment "nginx-deployment2"edited

　　查看Deployment的變更信息（以下信息得以保存，是創(chuàng)建時(shí)候加的“--record”這個(gè)選項(xiàng)起的作用）：

$ kubectl rollout history deployment/nginx-deployment

deployments "nginx-deployment":

REVISION? ? CHANGE-CAUSE1kubectl create -f docs/user-guide/nginx-deployment.yaml --record2kubectl set image deployment/nginx-deployment nginx=nginx:1.9.13kubectl set image deployment/nginx-deployment nginx=nginx:1.91$ kubectl rollout history deployment/nginx-deployment --revision=2deployments "nginx-deployment"revision2? Labels:? ? ? app=nginx

? ? ? ? ? pod-template-hash=1159050644? Annotations:? kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1? Containers:

? nginx:

? ? Image:? ? ? nginx:1.9.1? ? Port:? ? ? 80/TCP

? ? QoS Tier:

? ? ? ? cpu:? ? ? BestEffort

? ? ? ? memory:? BestEffort

? ? Environment Variables:? ? ? ? No volumes.

　　最后介紹下Deployment的一些基礎(chǔ)命令瞻讽。

$ kubectl describe deployments? #查詢(xún)?cè)敿?xì)信息鸳吸，獲取升級(jí)進(jìn)度

$ kubectl rollout pause deployment/nginx-deployment2? #暫停升級(jí)

$ kubectl rollout resume deployment/nginx-deployment2? #繼續(xù)升級(jí)

$ kubectl rollout undo deployment/nginx-deployment2? #升級(jí)回滾

$ kubectl scale deployment nginx-deployment --replicas10#彈性伸縮Pod數(shù)量

　　關(guān)于多重升級(jí)，舉例速勇，當(dāng)你創(chuàng)建了一個(gè)nginx1.7的Deployment晌砾，要求副本數(shù)量為5之后，Deployment Controller會(huì)逐步的將5個(gè)1.7的Pod啟動(dòng)起來(lái)烦磁；當(dāng)啟動(dòng)到3個(gè)的時(shí)候养匈，你又發(fā)出更新Deployment中Nginx到1.9的命令；這時(shí)Deployment Controller會(huì)立即將已啟動(dòng)的3個(gè)1.7Pod殺掉都伪，然后逐步啟動(dòng)1.9的Pod呕乎。Deployment Controller不會(huì)等到1.7的Pod都啟動(dòng)完成之后，再依次殺掉1.7陨晶，啟動(dòng)1.9猬仁。

7、Volume

　　在Docker的設(shè)計(jì)實(shí)現(xiàn)中，容器中的數(shù)據(jù)是臨時(shí)的逐虚，即當(dāng)容器被銷(xiāo)毀時(shí)聋溜，其中的數(shù)據(jù)將會(huì)丟失。如果需要持久化數(shù)據(jù)叭爱，需要使用Docker數(shù)據(jù)卷掛載宿主機(jī)上的文件或者目錄到容器中撮躁。在Kubernetes中，當(dāng)Pod重建的時(shí)候买雾，數(shù)據(jù)是會(huì)丟失的把曼，Kubernetes也是通過(guò)數(shù)據(jù)卷掛載來(lái)提供Pod數(shù)據(jù)的持久化的。Kubernetes數(shù)據(jù)卷是對(duì)Docker數(shù)據(jù)卷的擴(kuò)展漓穿，Kubernetes數(shù)據(jù)卷是Pod級(jí)別的嗤军，可以用來(lái)實(shí)現(xiàn)Pod中容器的文件共享。目前晃危，Kubernetes支持的數(shù)據(jù)卷類(lèi)型如下：

　　　　1)??????? EmptyDir

　　　　2)??????? HostPath

　　　　3)??????? GCE Persistent Disk

　　　　4)??????? AWS Elastic Block Store

　　　　5)??????? NFS

　　　　6)??????? iSCSI

　　　　7)??????? Flocker

　　　　8)??????? GlusterFS

　　　　9)??????? RBD

　　　　10)??? Git Repo

　　　　11)??? Secret

　　　　12)??? Persistent Volume Claim

　　　　13)??? Downward API

7.1本地?cái)?shù)據(jù)卷

　　EmptyDir叙赚、HostPath這兩種類(lèi)型的數(shù)據(jù)卷，只能最用于本地文件系統(tǒng)僚饭。本地?cái)?shù)據(jù)卷中的數(shù)據(jù)只會(huì)存在于一臺(tái)機(jī)器上震叮，所以當(dāng)Pod發(fā)生遷移的時(shí)候，數(shù)據(jù)便會(huì)丟失鳍鸵。該類(lèi)型Volume的用途是：Pod中容器間的文件共享苇瓣、共享宿主機(jī)的文件系統(tǒng)。

7.1.1 EmptyDir

　　如果Pod配置了EmpyDir數(shù)據(jù)卷偿乖，在Pod的生命周期內(nèi)都會(huì)存在击罪，當(dāng)Pod被分配到 Node上的時(shí)候，會(huì)在Node上創(chuàng)建EmptyDir數(shù)據(jù)卷贪薪，并掛載到Pod的容器中媳禁。只要Pod 存在，EmpyDir數(shù)據(jù)卷都會(huì)存在（容器刪除不會(huì)導(dǎo)致EmpyDir數(shù)據(jù)卷丟失數(shù)據(jù)）画切，但是如果Pod的生命周期終結(jié)（Pod被刪除）损话，EmpyDir數(shù)據(jù)卷也會(huì)被刪除，并且永久丟失槽唾。

　　EmpyDir數(shù)據(jù)卷非常適合實(shí)現(xiàn)Pod中容器的文件共享丧枪。Pod的設(shè)計(jì)提供了一個(gè)很好的容器組合的模型，容器之間各司其職庞萍，通過(guò)共享文件目錄來(lái)完成交互拧烦，比如可以通過(guò)一個(gè)專(zhuān)職日志收集容器，在每個(gè)Pod中和業(yè)務(wù)容器中進(jìn)行組合钝计，來(lái)完成日志的收集和匯總恋博。

7.1.2 HostPath

　　HostPath數(shù)據(jù)卷允許將容器宿主機(jī)上的文件系統(tǒng)掛載到Pod中齐佳。如果Pod需要使用宿主機(jī)上的某些文件，可以使用HostPath债沮。

7.2網(wǎng)絡(luò)數(shù)據(jù)卷

　　Kubernetes提供了很多類(lèi)型的數(shù)據(jù)卷以集成第三方的存儲(chǔ)系統(tǒng)炼吴，包括一些非常流行的分布式文件系統(tǒng)，也有在IaaS平臺(tái)上提供的存儲(chǔ)支持疫衩，這些存儲(chǔ)系統(tǒng)都是分布式的硅蹦，通過(guò)網(wǎng)絡(luò)共享文件系統(tǒng)，因此我們稱(chēng)這一類(lèi)數(shù)據(jù)卷為網(wǎng)絡(luò)數(shù)據(jù)卷闷煤。

　　網(wǎng)絡(luò)數(shù)據(jù)卷能夠滿(mǎn)足數(shù)據(jù)的持久化需求童芹，Pod通過(guò)配置使用網(wǎng)絡(luò)數(shù)據(jù)卷，每次Pod創(chuàng)建的時(shí)候都會(huì)將存儲(chǔ)系統(tǒng)的遠(yuǎn)端文件目錄掛載到容器中鲤拿，數(shù)據(jù)卷中的數(shù)據(jù)將被水久保存假褪，即使Pod被刪除，只是除去掛載數(shù)據(jù)卷近顷，數(shù)據(jù)卷中的數(shù)據(jù)仍然保存在存儲(chǔ)系統(tǒng)中生音，且當(dāng)新的Pod被創(chuàng)建的時(shí)候，仍是掛載同樣的數(shù)據(jù)卷窒升。網(wǎng)絡(luò)數(shù)據(jù)卷包含以下幾種：NFS久锥、iSCISI、GlusterFS异剥、RBD（Ceph Block Device）、Flocker絮重、AWS Elastic Block Store冤寿、GCE Persistent Disk

7.3 Persistent Volume和Persistent Volume Claim

　　理解每個(gè)存儲(chǔ)系統(tǒng)是一件復(fù)雜的事情，特別是對(duì)于普通用戶(hù)來(lái)說(shuō)青伤，有時(shí)候并不需要關(guān)心各種存儲(chǔ)實(shí)現(xiàn)督怜，只希望能夠安全可靠地存儲(chǔ)數(shù)據(jù)。Kubernetes中提供了Persistent Volume和Persistent Volume Claim機(jī)制狠角，這是存儲(chǔ)消費(fèi)模式号杠。Persistent Volume是由系統(tǒng)管理員配置創(chuàng)建的一個(gè)數(shù)據(jù)卷（目前支持HostPath、GCE Persistent Disk丰歌、AWS Elastic Block Store姨蟋、NFS、iSCSI立帖、GlusterFS眼溶、RBD），它代表了某一類(lèi)存儲(chǔ)插件實(shí)現(xiàn)晓勇；而對(duì)于普通用戶(hù)來(lái)說(shuō)堂飞，通過(guò)Persistent Volume Claim可請(qǐng)求并獲得合適的Persistent Volume灌旧，而無(wú)須感知后端的存儲(chǔ)實(shí)現(xiàn)。Persistent Volume和Persistent Volume Claim的關(guān)系其實(shí)類(lèi)似于Pod和Node绰筛，Pod消費(fèi)Node資源枢泰，Persistent Volume Claim則消費(fèi)Persistent Volume資源。Persistent Volume和Persistent Volume Claim相互關(guān)聯(lián)铝噩，有著完整的生命周期管理：

　　　　1)??????? 準(zhǔn)備：系統(tǒng)管理員規(guī)劃或創(chuàng)建一批Persistent Volume衡蚂；

　　　　2)??????? 綁定：用戶(hù)通過(guò)創(chuàng)建Persistent Volume Claim來(lái)聲明存儲(chǔ)請(qǐng)求，Kubernetes發(fā)現(xiàn)有存儲(chǔ)請(qǐng)求的時(shí)候薄榛，就去查找符合條件的Persistent Volume（最小滿(mǎn)足策略）讳窟。找到合適的就綁定上，找不到就一直處于等待狀態(tài)敞恋；

　　　　3)??????? 使用：創(chuàng)建Pod的時(shí)候使用Persistent Volume Claim丽啡；

　　　　4)??????? 釋放：當(dāng)用戶(hù)刪除綁定在Persistent Volume上的Persistent Volume Claim時(shí)，Persistent Volume進(jìn)入釋放狀態(tài)硬猫，此時(shí)Persistent Volume中還殘留著上一個(gè)Persistent Volume Claim的數(shù)據(jù)补箍，狀態(tài)還不可用；

　　　　5)??????? 回收：是否的Persistent Volume需要回收才能再次使用啸蜜】友牛回收策略可以是人工的也可以是Kubernetes自動(dòng)進(jìn)行清理（僅支持NFS和HostPath）

7.4信息數(shù)據(jù)卷

　　Kubernetes中有一些數(shù)據(jù)卷，主要用來(lái)給容器傳遞配置信息衬横，我們稱(chēng)之為信息數(shù)據(jù)卷裹粤，比如Secret（處理敏感配置信息，密碼蜂林、Token等）遥诉、Downward API（通過(guò)環(huán)境變量的方式告訴容器Pod的信息）、Git Repo（將Git倉(cāng)庫(kù)下載到Pod中）噪叙，都是將Pod的信息以文件形式保存矮锈，然后以數(shù)據(jù)卷方式掛載到容器中，容器通過(guò)讀取文件獲取相應(yīng)的信息睁蕾。

8苞笨、Pet Sets/StatefulSet

　　K8s在1.3版本里發(fā)布了Alpha版的PetSet功能。在云原生應(yīng)用的體系里子眶，有下面兩組近義詞瀑凝；第一組是無(wú)狀態(tài)（stateless）、牲畜（cattle）臭杰、無(wú)名（nameless）漾稀、可丟棄（disposable）嫉柴；第二組是有狀態(tài)（stateful）涩惑、寵物（pet）、有名（having name）藏杖、不可丟棄（non-disposable）。RC和RS主要是控制提供無(wú)狀態(tài)服務(wù)的脉顿，其所控制的Pod的名字是隨機(jī)設(shè)置的蝌麸，一個(gè)Pod出故障了就被丟棄掉，在另一個(gè)地方重啟一個(gè)新的Pod艾疟，名字變了来吩、名字和啟動(dòng)在哪兒都不重要，重要的只是Pod總數(shù)蔽莱；而PetSet是用來(lái)控制有狀態(tài)服務(wù)弟疆，PetSet中的每個(gè)Pod的名字都是事先確定的，不能更改盗冷。PetSet中Pod的名字的作用怠苔，是用來(lái)關(guān)聯(lián)與該P(yáng)od對(duì)應(yīng)的狀態(tài)。

　　對(duì)于RC和RS中的Pod仪糖，一般不掛載存儲(chǔ)或者掛載共享存儲(chǔ)柑司，保存的是所有Pod共享的狀態(tài)，Pod像牲畜一樣沒(méi)有分別锅劝；對(duì)于PetSet中的Pod攒驰，每個(gè)Pod掛載自己獨(dú)立的存儲(chǔ)，如果一個(gè)Pod出現(xiàn)故障故爵，從其他節(jié)點(diǎn)啟動(dòng)一個(gè)同樣名字的Pod玻粪，要掛在上原來(lái)Pod的存儲(chǔ)繼續(xù)以它的狀態(tài)提供服務(wù)。

　　適合于PetSet的業(yè)務(wù)包括數(shù)據(jù)庫(kù)服務(wù)MySQL和PostgreSQL诬垂，集群化管理服務(wù)Zookeeper劲室、etcd等有狀態(tài)服務(wù)。PetSet的另一種典型應(yīng)用場(chǎng)景是作為一種比普通容器更穩(wěn)定可靠的模擬虛擬機(jī)的機(jī)制剥纷。傳統(tǒng)的虛擬機(jī)正是一種有狀態(tài)的寵物，運(yùn)維人員需要不斷地維護(hù)它呢铆，容器剛開(kāi)始流行時(shí)晦鞋，我們用容器來(lái)模擬虛擬機(jī)使用，所有狀態(tài)都保存在容器里棺克，而這已被證明是非常不安全悠垛、不可靠的。使用PetSet娜谊，Pod仍然可以通過(guò)漂移到不同節(jié)點(diǎn)提供高可用确买，而存儲(chǔ)也可以通過(guò)外掛的存儲(chǔ)來(lái)提供高可靠性，PetSet做的只是將確定的Pod與確定的存儲(chǔ)關(guān)聯(lián)起來(lái)保證狀態(tài)的連續(xù)性纱皆。

?9湾趾、ConfigMap

很多生產(chǎn)環(huán)境中的應(yīng)用程序配置較為復(fù)雜芭商，可能需要多個(gè)config文件、命令行參數(shù)和環(huán)境變量的組合搀缠。并且铛楣，這些配置信息應(yīng)該從應(yīng)用程序鏡像中解耦出來(lái)，以保證鏡像的可移植性以及配置信息不被泄露艺普。社區(qū)引入ConfigMap這個(gè)API資源來(lái)滿(mǎn)足這一需求簸州。

ConfigMap包含了一系列的鍵值對(duì)，用于存儲(chǔ)被Pod或者系統(tǒng)組件（如controller）訪問(wèn)的信息歧譬。這與secret的設(shè)計(jì)理念有異曲同工之妙岸浑，它們的主要區(qū)別在于ConfigMap通常不用于存儲(chǔ)敏感信息，而只存儲(chǔ)簡(jiǎn)單的文本信息瑰步。

10矢洲、Horizontal Pod Autoscaler

　　自動(dòng)擴(kuò)展作為一個(gè)長(zhǎng)久的議題，一直為人們津津樂(lè)道面氓。系統(tǒng)能夠根據(jù)負(fù)載的變化對(duì)計(jì)算資源的分配進(jìn)行自動(dòng)的擴(kuò)增或者收縮兵钮，無(wú)疑是一個(gè)非常吸引人的特征，它能夠最大可能地減少費(fèi)用或者其他代價(jià)（如電力損耗）舌界。自動(dòng)擴(kuò)展主要分為兩種掘譬，其一為水平擴(kuò)展，針對(duì)于實(shí)例數(shù)目的增減呻拌；其二為垂直擴(kuò)展葱轩，即單個(gè)實(shí)例可以使用的資源的增減。Horizontal Pod Autoscaler（HPA）屬于前者藐握。

10.1 Horizontal Pod Autoscaler如何工作

　　Horizontal Pod Autoscaler的操作對(duì)象是Replication Controller靴拱、ReplicaSet或Deployment對(duì)應(yīng)的Pod，根據(jù)觀察到的CPU實(shí)際使用量與用戶(hù)的期望值進(jìn)行比對(duì)猾普，做出是否需要增減實(shí)例數(shù)量的決策袜炕。controller目前使用heapSter來(lái)檢測(cè)CPU使用量，檢測(cè)周期默認(rèn)是30秒初家。

10.2 Horizontal Pod Autoscaler的決策策略

　　在HPA Controller檢測(cè)到CPU的實(shí)際使用量之后偎窘，會(huì)求出當(dāng)前的CPU使用率（實(shí)際使用量與pod 請(qǐng)求量的比率)。然后溜在，HPA Controller會(huì)通過(guò)調(diào)整副本數(shù)量使得CPU使用率盡量向期望值靠近．另外陌知，考慮到自動(dòng)擴(kuò)展的決策可能需要一段時(shí)間才會(huì)生效，甚至在短時(shí)間內(nèi)會(huì)引入一些噪聲． 例如當(dāng)pod所需要的CPU負(fù)荷過(guò)大掖肋，從而運(yùn)行一個(gè)新的pod進(jìn)行分流仆葡，在創(chuàng)建的過(guò)程中，系統(tǒng)的CPU使用量可能會(huì)有一個(gè)攀升的過(guò)程志笼。所以沿盅，在每一次作出決策后的一段時(shí)間內(nèi)把篓，將不再進(jìn)行擴(kuò)展決策。對(duì)于ScaleUp而言嗡呼，這個(gè)時(shí)間段為3分鐘纸俭，Scaledown為5分鐘。再者HPA Controller允許一定范圍內(nèi)的CPU使用量的不穩(wěn)定南窗，也就是說(shuō)揍很，只有當(dāng)aVg（CurrentPodConsumption／Target低于0.9或者高于1.1時(shí)才進(jìn)行實(shí)例調(diào)整，這也是出于維護(hù)系統(tǒng)穩(wěn)定性的考慮万伤。