深刻玩轉K8S之利用Label控制Pod位置

首先介紹下什麼是Label？

Label是Kubernetes系列中一個核心概念。是一組綁定到K8s資源對象上的key/value對。同一個對象的labels屬性的key必須惟一。label能夠附加到各類資源對象上，如Node,Pod,Service,RC等。

經過給指定的資源對象捆綁一個或多個不用的label來實現多維度的資源分組管理功能，以便於靈活，方便地進行資源分配，調度，配置，部署等管理工做。

默認配置下，Scheduler 會將 Pod 調度到全部可用的 Node。不過有些實際狀況咱們但願將 Pod 部署到指定的 Node，好比將有大量磁盤 I/O 的 Pod 部署到配置了 SSD 的 Node；或者 Pod 須要 GPU，須要運行在配置了 GPU 的節點上。

下面咱們來實際的操做下，好比執行以下命令標註 k8s-node1 是配置了 SSD的節點。

 

kubectl label node k8s-node1 disktype=ssd

 

而後經過 kubectl get node --show-labels 查看節點的 label。

能夠看到disktype=ssd 已經成功添加到 k8snode1，除了 disktype，Node 還有幾個 Kubernetes 本身維護的 label。有了 disktype 這個自定義 label，接下來就能夠指定將 Pod 部署到 k8snod1。好比我編輯nginx.yml，增長nodeSelector標籤，指定將此Pod部署到具備ssd屬性的Node上去。

最後經過kubectl get pod -o wide。

 

若是要刪除 label disktype，就執行以下命令刪除便可：

     

kubectl label node k8s-node1 disktype-

 

可是要注意已經部署的 Pod 並不會從新部署，依然在 k8snode1 上運行。可能會有人說了，那怎麼讓Pod變回原樣呢也就是分配到多個node上，那就須要一個笨方法了（至少在目前我學習的方法裏面只會這樣操做），就是在剛纔編輯的那個nginx.yml文件裏面刪除nodeSelector標籤，而後在利用kubectl apply從新部署，Kubernetes 會刪除以前的 Pod 並調度和運行新的 Pod。

 

好了本次的Label標籤的實踐討論到此結束，本文參考了Kubernetes 官網和Cloud Man博文。

 

實例操做：

給其中一個節點添加label

[root@test-master03 ~]# kubectl label node cn-hangzhou.192.168.7.201 disktype=ssd
node/cn-hangzhou.192.168.7.201 labeled

顯示 其中一個pod 運行的節點 

[root@test-master03 ~]# kubectl get pod -n xitu-qa02 -o wide|grep nginx-test02
h5-xitu-nginx-test02-8489f56656-z82tq                    1/1     Running   0          103s   172.20.3.81    cn-hangzhou.192.168.7.222   <none>



顯示label狀況

[root@test-master03 ~]# kubectl get node --show-labels
NAME                        STATUS   ROLES    AGE    VERSION            LABELS
cn-hangzhou.192.168.7.179   Ready    master   124d   v1.12.6-aliyun.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=ecs.c5.xlarge,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=cn-hangzhou,failure-domain.beta.kubernetes.io/zone=cn-hangzhou-h,kubernetes.io/hostname=cn-hangzhou.192.168.7.179,node-role.kubernetes.io/master=
cn-hangzhou.192.168.7.180   Ready    master   124d   v1.12.6-aliyun.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=ecs.c5.xlarge,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=cn-hangzhou,failure-domain.beta.kubernetes.io/zone=cn-hangzhou-h,kubernetes.io/hostname=cn-hangzhou.192.168.7.180,node-role.kubernetes.io/master=
cn-hangzhou.192.168.7.181   Ready    master   124d   v1.12.6-aliyun.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=ecs.c5.xlarge,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=cn-hangzhou,failure-domain.beta.kubernetes.io/zone=cn-hangzhou-h,kubernetes.io/hostname=cn-hangzhou.192.168.7.181,node-role.kubernetes.io/master=
cn-hangzhou.192.168.7.182   Ready    <none>   124d   v1.12.6-aliyun.1   app=nginx-dev,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=ecs.g5.xlarge,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=cn-hangzhou,failure-domain.beta.kubernetes.io/zone=cn-hangzhou-h,kubernetes.io/hostname=cn-hangzhou.192.168.7.182
cn-hangzhou.192.168.7.190   Ready    <none>   108d   v1.12.6-aliyun.1   app=nginx-test,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=ecs.g5.2xlarge,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=cn-hangzhou,failure-domain.beta.kubernetes.io/zone=cn-hangzhou-h,kubernetes.io/hostname=cn-hangzhou.192.168.7.190
cn-hangzhou.192.168.7.201   Ready    <none>   73d    v1.12.6-aliyun.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=ecs.g5.3xlarge,beta.kubernetes.io/os=linux,disktype=ssd,failure-domain.beta.kubernetes.io/region=cn-hangzhou,failure-domain.beta.kubernetes.io/zone=cn-hangzhou-h,kubernetes.io/hostname=cn-hangzhou.192.168.7.201
cn-hangzhou.192.168.7.222   Ready    <none>   19d    v1.12.6-aliyun.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=ecs.c6.4xlarge,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=cn-hangzhou,failure-domain.beta.kubernetes.io/zone=cn-hangzhou-h,kubernetes.io/hostname=cn-hangzhou.192.168.7.222


修改應用的yaml文件增長 nodeselector 配置

    spec:
      containers:
        - image: 'nginx:1.15.10-alpine'
          imagePullPolicy: Always
          name: h5-xitu-nginx-test02

      dnsPolicy: ClusterFirst
      imagePullSecrets:
        - name: regsecret
      nodeSelector:
        disktype: ssd
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}

從新啓動應用後查看pod 運行的節點狀況 

kubectl get pod -n xitu-qa02 -o wide|grep nginx-test02
h5-xitu-nginx-test02-687f7c4768-txhfr                    1/1     Running   0          26s   172.20.2.160   cn-hangzhou.192.168.7.201   <none>