深入玩转K8S之利用Label控制Pod位置

Posted weifeng1463

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了深入玩转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>

  

以上是关于深入玩转K8S之利用Label控制Pod位置的主要内容,如果未能解决你的问题,请参考以下文章

用 label 控制 Pod 的位置 - 每天5分钟玩转 Docker 容器技术(128)

k8s通过label来控制pod的位置

深入玩转K8S之存储资源管理

深入玩转K8S之最懂实际应用场景的调度神器DaemonSet

用 Label 控制 Service 的位置 - 每天5分钟玩转 Docker 容器技术(106)

linux12k8s --> 04命令行优化Pod介绍label标签控制器