本篇內(nèi)容介紹了“Kubernetes 1.8中的Pod怎么創(chuàng)建和應(yīng)用”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

創(chuàng)新互聯(lián)自2013年創(chuàng)立以來(lái)，先為繁昌等服務(wù)建站，繁昌等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為繁昌企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。

Kubernetes 1.8中對(duì)scheduler的更新

• 【Alpha】支持定義PriorityClass，并指定給Pod來(lái)定義Pod Priority；

• 【Alpha】支持基于Pod Priority的搶占式調(diào)度;

• 【Alpha】Node Controller支持自動(dòng)根據(jù)Node Condition給Node打上對(duì)應(yīng)的Taints；

什么是搶占式調(diào)度？
在Kubernetes 1.8版本之前，當(dāng)集群資源不足時(shí)，用戶提交新的Pod創(chuàng)建請(qǐng)求后，該P(yáng)od會(huì)處于Pending狀態(tài)，直到集群中有某個(gè)Node有足夠Available Resources時(shí)才會(huì)調(diào)度成功。 從Kubernetes 1.8版本開始，這種情況下scheduler會(huì)根據(jù)Pod's Priority進(jìn)行調(diào)度，調(diào)度時(shí)會(huì)選擇最合適的Node并把該Node上lower Priority的Pods進(jìn)行Premmption(Eviction)以釋放資源供該higher Priority Pod使用。這種調(diào)度時(shí)考慮Pod Priority的方式就是Kubernetes中的搶占式調(diào)度，簡(jiǎn)稱為Preemption。

如何開啟或關(guān)閉該Feature

在Kubernetes 1.8中，Pod Priority和Preemption作為Alpha特性，默認(rèn)是disable的，如果你要使用該特性，需要給apiserver和scheduler添加如下參數(shù)并重啟：

• kube-apiserver xxx --feature-gates=PodPriority=true --runtime-config=scheduling.k8s.io/v1alpha1=true

• kube-scheduler xxx --feature-gates=PodPriority=true

反過(guò)來(lái)，把上面的參數(shù)刪除并重啟，即可disable。

有個(gè)問(wèn)題：如果我開啟了這個(gè)特性，并且創(chuàng)建了一些PriorityClass，然后還給某些Pod使用了，這個(gè)時(shí)候我再disable掉這個(gè)特性，會(huì)不會(huì)有問(wèn)題？

答案是否定的！disable后，那些之前設(shè)置的Pod Priority field還會(huì)繼續(xù)存在，但是并沒什么用處了，Preemption是關(guān)閉的。當(dāng)然，你也不能給新的Pods引用PriorityClass了。

創(chuàng)建PriorityClass

Enable后，接下來(lái)就是創(chuàng)建PriorityClass了：

apiVersion: scheduling.k8s.io/v1alpha1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for XYZ service pods only."

注意：PriorityClass是非namespace隔離的，是global的。因此metadata下面是不能設(shè)置namespace field的。

• apiVersion: scheduling.k8s.io/v1alpha1 # enable的時(shí)候需要配置的runtime-config參數(shù)；

• metadata.name: 設(shè)置PriorityClass的名字；

• value: 32-bit 整型值，值越大代表優(yōu)先級(jí)越高，但是必須小于等于 1 billion，大于 1 billion的值是給集群內(nèi)的critical system Pods保留的，表示該P(yáng)riority的Pod是不能被搶占的。

• globalDefault: true or false，注意只能有一個(gè)PriorityClass的這個(gè)字段為true，如果沒有一個(gè)PriorityClass的該字段為true，則那些沒有明確引用PriorityClass的Pod的Priority value就為最低值0.

• description: String，寫給人看的備注，Kubernetes不做處理；

注意：

• PriorityClass只會(huì)影響那些還沒創(chuàng)建的Pod，一旦Pod創(chuàng)建完成，那么admission Controller就已經(jīng)將Pod Spec中應(yīng)用的PriorityClassName對(duì)應(yīng)的PriorityClass的value設(shè)置到Pod的Priority field了。意味著你再修改PriorityClass的任何field，包括globalDefault，也不會(huì)影響已經(jīng)創(chuàng)建完成的Pod。

• 如果你刪除某個(gè)PriorityClass，那么不會(huì)影響已經(jīng)引用它的Pod Priority，但你不能用它來(lái)創(chuàng)建新的Pod了。這其實(shí)是顯而易見的。

創(chuàng)建Pod并引用該P(yáng)riorityClass

接下來(lái)，就是創(chuàng)建對(duì)應(yīng)Priority的Pod了：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  priorityClassName: high-priority

如果Pod.spec. priorityClassName中指定的PriorityClass不存在，則Pod會(huì)創(chuàng)建失??；
前面也提到，創(chuàng)建Pod的時(shí)候Priority Admission Controller會(huì)根據(jù)PriorityClassName找到對(duì)應(yīng)的PriorityClass，并將其value設(shè)置給Pod.spec.priority。

Preemption當(dāng)前還存在的問(wèn)題

• 因?yàn)閾屨际秸{(diào)度evict低優(yōu)先級(jí)Pod時(shí)，有一個(gè)優(yōu)雅終止時(shí)間(默認(rèn)30s),如果該Node上需要evict多個(gè)低優(yōu)先級(jí)的Pod，那么可能會(huì)需要很長(zhǎng)的時(shí)間后，最終Pod才能調(diào)度到該Node上并啟動(dòng)運(yùn)行，那么問(wèn)題來(lái)了，這么長(zhǎng)時(shí)間的過(guò)去了，這個(gè)Node是否此時(shí)此刻還是最適合這個(gè)Pod的呢？不一定！而且在大規(guī)模且創(chuàng)建Pod頻繁的集群中，這種結(jié)果是經(jīng)常的。意味著，當(dāng)初合正確的調(diào)度決定，在真正落實(shí)的時(shí)候卻一定時(shí)正確的了。

• 還不支持preempted pod時(shí)考慮PDB，計(jì)劃會(huì)在beta版中實(shí)現(xiàn)；

• 目前premmpted pod時(shí)沒考慮Pending pod和victims pod的親和性：如果該pending pod要調(diào)度到的node上需要evict的lower Priority pods和該pending pod是親和的，目前直接evict lower Priority pods就可能會(huì)破壞這種pod親和性。

• 不支持跨節(jié)點(diǎn)搶占。比如pending Pod M要調(diào)度到Node A，而該P(yáng)ending Pod M又與“同Node A一個(gè)zone的Node B上的Pod N”是基于zone topology反親和性的，目前的Alpha版本就會(huì)導(dǎo)致Pod M繼續(xù)Pending不能成功調(diào)度。如果后續(xù)支持跨界點(diǎn)搶占，就能將lower Priority的Pod N從Node B上evict掉，從而保證了反親和性。

Taint Nodes by Condition

在Kubernetes 1.8之前，Node Condition是會(huì)直接干預(yù)調(diào)度的，邏輯是是這樣的，并且是無(wú)法改變的：

• kubelet會(huì)定期的將Node Condition傳給kube-apiserver并存于etcd。

• kube-scheduler watch到Node Condition Pressure之后，會(huì)根據(jù)以下策略，阻止更多Pods Bind到該Node。

- 當(dāng)Node Condition包含Memory Pressure時(shí)，不再允許BestEffort QoS Pods調(diào)度到該節(jié)點(diǎn)；
- 當(dāng)Node Condition包含DiskPressure時(shí)，不允許任何pods調(diào)度到該節(jié)點(diǎn)。

從Kubernetes 1.6開始，kubelet和Node Controller支持自動(dòng)根據(jù)Node Condition給Node打上相應(yīng)的內(nèi)置Taints，當(dāng)時(shí)這些Taints只是會(huì)影響kubelet eviction，而不會(huì)影響調(diào)度。這有啥不同呢？區(qū)別就是，給Node打上Taints對(duì)調(diào)度來(lái)說(shuō)是軟限制，可以通過(guò)給pods加上對(duì)應(yīng)的Tolerations就可能強(qiáng)制調(diào)度到那個(gè)節(jié)點(diǎn)。而在1.8之前，Node Condition影響調(diào)度是硬限制。

Node Condition和Taints的Map關(guān)系如下：

“Kubernetes 1.8中的Pod怎么創(chuàng)建和應(yīng)用”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！