深刻玩转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>