kubernetes集群实战——Pod调度、亲和性与反亲和性、Node属性Taints、Pod属性Tolerations

最新推荐文章于 2024-08-15 16:53:17 发布

Li_barroco

最新推荐文章于 2024-08-15 16:53:17 发布

阅读量785

点赞数

文章标签： kubernetes scheduler

本文链接：https://blog.csdn.net/weixin_45792518/article/details/107193753

版权

本文详细介绍了Kubernetes集群中的Pod调度，包括nodeName、nodeSelector、亲和性和反亲和性。重点讨论了Node的Taints和Pod的Tolerations机制，阐述了如何通过设置污点和容忍来控制Pod的调度策略，以及影响Pod调度的其他指令。

摘要由CSDN通过智能技术生成

1.调度器作用

调度器通过 kubernetes 的 watch 机制来发现集群中新创建且尚未被调度到 Node 上的 Pod。调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行。
kube-scheduler 是 Kubernetes 集群的默认调度器，并且是集群控制面的一部分。如果你真的希望或者有这方面的需求，kube-scheduler 在设计上是允许你自己写一个调度组件并替换原有的 kube-scheduler。
在做调度决定时需要考虑的因素包括：单独和整体的资源请求、硬件/软件/策略限制、亲和以及反亲和要求、数据局域性、负载间的干扰等等。

默认策略可以参考：https://kubernetes.io/zh/docs/concepts/scheduling/kube-scheduler/
调度框架：https://kubernetes.io/zh/docs/concepts/configuration/scheduling-framework/

2. nodeName

nodeName 是节点选择约束的最简单方法，但一般不推荐。
如果 nodeName 在 PodSpec 中指定了，则它优先于其他的节点选择方法。
使用 nodeName 来选择节点的一些限制：
如果指定的节点不存在。
如果指定的节点没有资源来容纳 pod，则pod 调度失败。
云环境中的节点名称并非总是可预测或稳定的。
示例

[root@server2 ~]# cd sduler/
[root@server2 sduler]# vim pod.yml 
[root@server2 sduler]# cat pod.yml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  nodeName: server3	##指定pod调度到server3节点
[root@server2 sduler]# kubectl apply -f pod.yml 
pod/nginx created
[root@server2 sduler]# kubectl get pod -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP            NODE      NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          13s   10.244.1.30   server3   <none>           <none>
[root@server2 sduler]#

在这里插入图片描述
测试：指定节点没有资源来容纳 pod，则pod 调度失败

3. nodeSelector

nodeSelector 是节点选择约束的最简单推荐形式。

给选择的节点添加标签：
kubectl label nodes server2 disktype=ssd

添加 nodeSelector 字段到 pod 配置中：

[root@server2 sduler]# kubectl label nodes server3 disktype=ssd	##添加标签到节点server3
node/server3 labeled
[root@server2 sduler]# kubectl get node --show-labels
NAME      STATUS   ROLES    AGE     VERSION   LABELS
server2   Ready    master   5d15h   v1.18.5   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disktype=ssd,kubernetes.io/arch=amd64,kubernetes.io/hostname=server2,kubernetes.io/os=linux,node-role.kubernetes.io/master=
server3   Ready    <none>   5d15h   v1.18.5   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disktype=ssd,kubernetes.io/arch=amd64,kubernetes.io/hostname=server3,kubernetes.io/os=linux
server4   Ready    <none>   5d15h   v1.18.5   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=server4,kubernetes.io/os=linux
[root@server2 sduler]# vim pod.yml 
[root@server2 sduler]# cat pod.yml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  nodeSelector: 	##按照所添加的标签选择节点
    disktype: ssd
[root@server2 sduler]# kubectl apply -f pod.yml
pod/nginx created
[root@server2 sduler]# kubectl get pod -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP            NODE      NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          19s   10.244.1.31   server3   <none>           <none>
[root@server2 sduler]#

在这里插入图片描述

未匹配到标签时，pod将一直处于pending状态