kubernetes中pod資源的調度
kubernetes簡介
創新互聯建站是一家集網站建設,奎文企業網站建設,奎文品牌網站建設,網站定制,奎文網站建設報價,網絡營銷,網絡優化,奎文網站推廣為一體的創新建站企業，幫助傳統企業提升企業形象加強企業競爭力。可充分滿足這一群體相比中小企業更為豐富、高端、多元的互聯網需求。同時我們時刻保持專業、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學習、思考、沉淀、凈化自己，讓我們為更多的企業打造出實用型網站。
kubernetes，簡稱K8s，是用8代替8個字符“ubernete”而成的縮寫。是一個開源的，用于管理云平臺中多個主機上的容器化的應用，Kubernetes的目標是讓部署容器化的應用簡單并且高效（powerful）,Kubernetes提供了應用部署，規劃，更新，維護的一種機制。
Pod簡介
Pod是Kubernetes創建或部署的最小/最簡單的基本單位，一個Pod代表集群上正在運行的一個進程。
一個Pod封裝一個應用容器（也可以有多個容器），存儲資源、一個獨立的網絡IP以及管理控制容器運行方式的策略選項。Pod代表部署的一個單位：Kubernetes中單個應用的實例，它可能由單個容器或多個容器共享組成的資源。
通常情況下，使用的都是k8s默認的調度調度方式，但是在有些情況下，我們需要將pod運行在具有特點的標簽的node上才能都運行，這個時候，pod的調度策略就不能使用k8s默認的調度策略了，這個時候，就需要指定調度策略，告訴k8s需要將pod調度到那些node（節點）上。
nodeSelector
常規情況下，會直接使用nodeSelector這種調度策略。labels（標簽） 是k8s里面用來編標記資源的一種常用的方式，我們可以給node標記特殊的標簽，然后nodeSelector會將pod調度到帶有指定labels的node上的。
下面看個示例：
首先，查看node的label信息，通過下面的命令查看的 node 的 label：
$ kubectl get nodes --show-labels
NAME STATUS ROLES AGE VERSION LABELS
master Ready master 147d v1.10.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=master,node-role.kubernetes.io/master=
node02 Ready <none> 67d v1.10.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,course=k8s,kubernetes.io/hostname=node02
node03 Ready <none> 127d v1.10.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,jnlp=haimaxy,kubernetes.io/hostname=node03然后，可以給node02節點新增一個label：
$ kubectl label nodes node02 com=yijiadashuju
node "node02" labeled然后通過上面的--show-labels參數可以查看上述標簽是否生效。當 node 被打上了相關標簽后，在調度的時候就可以使用這些標簽了，只需要在 Pod 的spec字段中添加nodeSelector字段，里面是我們需要被調度的節點的 label 即可。比如，要將 Pod 我們要強制調度到 node02 這個節點上去，可以使用 nodeSelector 來表示了：(pod-selector-demo.yaml)
apiVersion: v1
kind: Pod
metadata:
labels:
app: busybox-pod
name: test-busybox
spec:
containers:
- command:
- sleep
- "3600"
image: busybox
imagePullPolicy: Always
name: test-busybox
nodeSelector:
com: yijiadashuju然后，執行pod-selector-demo.yaml文件后，可以通過下面的命令查看pod運行的節點信息
kubectl get pod -o wide -n default也可以使用description命令查看pod被調度到哪個節點上：
$ kubectl create -f pod-selector-demo.yaml
pod "test-busybox" created
$ kubectl describe pod test-busybox
Name: test-busybox
Namespace: default
Node: node02/10.151.30.63
......
QoS Class: BestEffort
Node-Selectors: com=youdianzhishi
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulMountVolume 55s kubelet, node02 MountVolume.SetUp succeeded for volume "default-token-n9w2d"
Normal Scheduled 54s default-scheduler Successfully assigned test-busybox to node02
Normal Pulling 54s kubelet, node02 pulling image "busybox"
Normal Pulled 40s kubelet, node02 Successfully pulled image "busybox"
Normal Created 40s kubelet, node02 Created container
Normal Started 40s kubelet, node02 Started container從上面的執行結果可以看出，pod 通過默認的 default-scheduler 調度器到了node02節點上。不過，這種調度方式屬于強制性的。如果node02上的資源不足，那么pod的狀態將會一直是pending狀態。這就是nodeselector的用法了。
通過上面的介紹，可以看出nodeselector使用起來非常方便，但是還有很多的不足，那就是不夠靈活，控制粒度偏大，在實際使用中還是有許多的不便。接下來一起看先親和性和反親和性調度。
親和性和反親和性調度
k8s的默認調度流程實際上是經過了兩個階段：predicates 和 priorities 。使用默認的調度流程的話，k8s會將pod調度到資源充裕的節點上，使用nodeselector的調度方法，又會將pod調度具有指定標簽的pod上。然后在實際生產環ongoing境中，我們需要將pod調度到具有默些label的一組node才能滿足實際需求，這個時候就需要nodeAffinity(節點親和性)、podAffinity(pod 親和性) 以及 podAntiAffinity(pod 反親和性)。
親和性可以分為具體可以細分為硬和軟兩種親和性，
軟親和性：如果調度的時候，沒有滿足要求，也可以繼續調度，即能滿足最好，不能也無所謂
硬親和性：是指調度的時候必須滿足特定的要求，如果不滿足，那么pod將不會被調度到當前node
規則可以設置：
軟策略: preferredDuringSchedulingIgnoredDuringExecution
硬策略: requiredDuringSchedulingIgnoredDuringExecution
nodeAffinity 節點親和性
節點親和性主要是用來控制 pod 能部署在哪些節點上，以及不能部署在哪些節點上的。它可以進行一些簡單的邏輯組合了，不只是簡單的相等匹配。
接下來看一個示例，使用 Deployment 來管理3個 pod 副本，使用nodeAffinity控制 pod 的調度，如下例子：（node-affinity-demo.yaml）
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: affinity
labels:
app: affinity
spec:
replicas: 3
revisionHistoryLimit: 15
template:
metadata:
labels:
app: affinity
role: test
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
name: nginxweb
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution: # 硬策略
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: NotIn
values:
- node03
preferredDuringSchedulingIgnoredDuringExecution: # 軟策略
- weight: 1
preference:
matchExpressions:
- key: com
operator: In
values:
- yijiadashuju這個pod調度的時候，首先要求不能運行在node03節點上，但是如果有節點滿足labels為com：yijiadashuju 的話，就會優先調度到這個節點上。
接下來看下節點信息：
$ kubectl get nodes --show-labels
NAME STATUS ROLES AGE VERSION LABELS
master Ready master 154d v1.10.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=master,node-role.kubernetes.io/master=
node02 Ready <none> 74d v1.10.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,com=yijiadashuju,course=k8s,kubernetes.io/hostname=node02
node03 Ready <none> 134d v1.10.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,jnlp=haimaxy,kubernetes.io/hostname=node03可以看到 node02 節點有com=yijiadashuju的 label，按要求會優先調度到這個節點，接下來創建 pod，然后使用descirbe命令查看調度情況。
$ kubectl create -f node-affinity-demo.yaml
deployment.apps "affinity" created
$ kubectl get pods -l app=affinity -o wide
NAME READY STATUS RESTARTS AGE IP NODE
affinity-7b4c946854-5gfln 1/1 Running 0 47s 10.244.4.214 node02
affinity-7b4c946854-l8b47 1/1 Running 0 47s 10.244.4.215 node02
affinity-7b4c946854-r86p5 1/1 Running 0 47s 10.244.4.213 node02從結果可以看到 pod 均被部署到了 node02節點。
現在Kubernetes提供的操作符有下面的幾種
In：label 的值在某個標簽中
NotIn：label 的值不在某個標簽中
Gt：label 的值大于某個值
Lt：label 的值小于某個值
Exists：某個 label 存在
DoesNotExist：某個 label 不存在如果nodeSelectorTerms下面有多個選項的話，滿足任何一個條件就可以了；如果matchExpressions有多個選項的話，則必須同時滿足這些條件才能正常調度 POD。
podAffinity pod親和性
pod的親和性主要用來解決pod可以和哪些pod部署在同一個集群里面，即拓撲域（由node組成的集群）里面；而pod的反親和性是為了解決pod不能和哪些pod部署在一起的問題，二者都是為了解決pod之間部署問題。需要注意的是，Pod 間親和與反親和需要大量的處理，這可能會顯著減慢大規模集群中的調度，不建議在具有幾百個節點的集群中使用，而且Pod 反親和需要對節點進行一致的標記，即集群中的每個節點必須具有適當的標簽能夠匹配 topologyKey。如果某些或所有節點缺少指定的 topologyKey 標簽，可能會導致意外行為。
下面是pod間親和的示例：
pods/pod-with-pod-affinity.yaml：
apiVersion: v1
kind: Pod
metadata:
name: with-pod-affinity
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S1
topologyKey: failure-domain.beta.kubernetes.io/zone
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S2
topologyKey: failure-domain.beta.kubernetes.io/zone
containers:
- name: with-pod-affinity
image: k8s.gcr.io/pause:2.0podAntiAffinity pod反親和性
下面是一個pod反親和yaml文件示例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis-cache
spec:
selector:
matchLabels:
app: store
replicas: 3
template:
metadata:
labels:
app: store
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- store
topologyKey: "kubernetes.io/hostname"
containers:
- name: redis-server
image: redis:3.2-alpine
網站題目：kubernetes中pod資源的調度
本文URL：http://vcdvsql.cn/article6/gghgog.html
成都網站建設公司_創新互聯，為您提供全網營銷推廣、網站改版、靜態網站、網站制作、品牌網站設計、App開發
聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯
- 百度停止更新網站快照時 我們應該引起那些注意和如何改正 2016-11-06
- 網站設計公司多如牛毛應如何篩選 2022-10-01
- 上海網站設計公司、上海網站建設公司，建的網站很捧 2020-11-07
- 網站設計公司設計師如何確定設計理念 2014-10-14
- 深圳網站設計公司哪家好|創新互聯網站設計公司 2021-12-13
- 如何選擇營銷型網站設計公司 2022-08-14
- 上海網站建設公司、上海網站設計公司更流行的設計風格 2020-11-05
- 小說網站的一些程序在上海網站建設公司、上海網站設計公司網站建設中的主要優勢 2020-11-08
- 上海網站建設公司、上海網站設計公司網站建設的指導性意義 2020-11-07
- 專業網站設計公司需要做什么工作？ 2014-11-08
- 做網站成功的基礎是找一個好的網站設計公司 2021-02-02
- 小說網站連載的方法在上海網站設計公司和上海網站建設公司上有什么作用 2020-11-09