Kubernetes 1.8中的Pod怎么創(chuàng)建和應用

本篇內容介紹了“Kubernetes 1.8中的Pod怎么創(chuàng)建和應用”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

Kubernetes 1.8中對scheduler的更新

• 【Alpha】支持定義PriorityClass，并指定給Pod來定義Pod Priority；

• 【Alpha】支持基于Pod Priority的搶占式調度;

• 【Alpha】Node Controller支持自動根據Node Condition給Node打上對應的Taints；

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

如何開啟或關閉該Feature

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

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

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

反過來，把上面的參數刪除并重啟，即可disable。

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

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

創(chuàng)建PriorityClass

Enable后，接下來就是創(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下面是不能設置namespace field的。

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

• metadata.name: 設置PriorityClass的名字；

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

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

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

注意：

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

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

創(chuàng)建Pod并引用該PriorityClass

接下來，就是創(chuà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會創(chuàng)建失??；
前面也提到，創(chuàng)建Pod的時候Priority Admission Controller會根據PriorityClassName找到對應的PriorityClass，并將其value設置給Pod.spec.priority。

Preemption當前還存在的問題

• 因為搶占式調度evict低優(yōu)先級Pod時，有一個優(yōu)雅終止時間(默認30s),如果該Node上需要evict多個低優(yōu)先級的Pod，那么可能會需要很長的時間后，最終Pod才能調度到該Node上并啟動運行，那么問題來了，這么長時間的過去了，這個Node是否此時此刻還是最適合這個Pod的呢？不一定！而且在大規(guī)模且創(chuàng)建Pod頻繁的集群中，這種結果是經常的。意味著，當初合正確的調度決定，在真正落實的時候卻一定時正確的了。

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

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

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

Taint Nodes by Condition

在Kubernetes 1.8之前，Node Condition是會直接干預調度的，邏輯是是這樣的，并且是無法改變的：

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

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

- 當Node Condition包含Memory Pressure時，不再允許BestEffort QoS Pods調度到該節(jié)點；
- 當Node Condition包含DiskPressure時，不允許任何pods調度到該節(jié)點。

從Kubernetes 1.6開始，kubelet和Node Controller支持自動根據Node Condition給Node打上相應的內置Taints，當時這些Taints只是會影響kubelet eviction，而不會影響調度。這有啥不同呢？區(qū)別就是，給Node打上Taints對調度來說是軟限制，可以通過給pods加上對應的Tolerations就可能強制調度到那個節(jié)點。而在1.8之前，Node Condition影響調度是硬限制。

Node Condition和Taints的Map關系如下：

“Kubernetes 1.8中的Pod怎么創(chuàng)建和應用”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！