• kubernetes-调度


    目录

    一、k8s调度简介

    二、影响kubernetes调度的因素 

    1、nodename

    2、nodeselector

    3、亲和与反亲和

    (1)nodeaffinity

    (2)podaffinity(亲和)

    (3)podantiaffinity(反亲和)

    4、Taints

    5、cordon、drain、delete


    一、k8s调度简介

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

    二、影响kubernetes调度的因素 

    1、nodename

    • nodeName 是节点选择约束的最简单方法,但一般不推荐。如果 nodeNamePodSpec 中指定了,则它优先于其他的节点选择方法
    • 使用 nodeName 来选择节点的一些限制
    • 如果指定的节点不存在
    • 如果指定的节点没有资源来容纳 pod,则pod 调度失败
    • 云环境中的节点名称并非总是可预测或稳定的
    1. vim nodename.yaml
    2. apiVersion: v1
    3. kind: Pod
    4. metadata:
    5. name: nginx
    6. labels:
    7. app: nginx
    8. spec:
    9. containers:
    10. - name: nginx
    11. image: nginx
    12. nodeName: k8s3 #找不到节点pod会出现pending,优先级最高

    2、nodeselector

    • nodeSelector 是节点选择约束的最简单推荐形式。(标签优先调度到哪里下次还在哪里)。如果俩个同时有标签,但是一个的资源不够,才会调度到另一个主机上。

    1. vim nodeselector.yaml
    2. apiVersion: v1
    3. kind: Pod
    4. metadata:
    5. name: nginx
    6. spec:
    7. containers:
    8. - name: nginx
    9. image: nginx
    10. imagePullPolicy: IfNotPresent
    11. nodeSelector:
    12. disktype: ssd
    13. kubectl label nodes k8s2 disktype=ssd
    14. kubectl label nodes k8s3 disktype=ssd

     

    3、亲和与反亲和

    节点的:

    • 亲和与反亲和
    • nodeSelector 提供了一种非常简单的方法来将 pod 约束到具有特定标签的节点上。亲和/反亲和功能极大地扩展了你可以表达约束的类型
    • 你可以发现规则是“软”/“偏好”,而不是硬性要求,因此,如果调度器无法满足该要求,仍然调度该 pod
    • 你可以使用节点上的 pod 的标签来约束,而不是使用节点本身的标签,来允许哪些 pod 可以或者不可以被放置在一起。
    • 节点亲和
    • requiredDuringSchedulingIgnoredDuringExecution   必须满足
    • preferredDuringSchedulingIgnoredDuringExecution  倾向满足
    • IgnoreDuringExecution 表示如果在Pod运行期间Node的标签发生变化,导致亲和性策略不能满足,则继续运行当前的Pod
    • 参考:https://kubernetes.io/zh/docs/concepts/configuration/assign-pod-node/
    (1)nodeaffinity
    1. vim nodeaffinity.yaml
    2. apiVersion: v1
    3. kind: Pod
    4. metadata:
    5. name: node-affinity
    6. spec:
    7. containers:
    8. - name: nginx
    9. image: nginx
    10. affinity:
    11. nodeAffinity:
    12. requiredDuringSchedulingIgnoredDuringExecution: ## 必须满足
    13. nodeSelectorTerms: ##节点选择
    14. - matchExpressions: ##匹配kv
    15. - key: disktype
    16. operator: In
    17. values: ##ssd或fc
    18. - ssd
    19. - fc
    20. preferredDuringSchedulingIgnoredDuringExecution: ##倾向满足
    21. - weight: 1 ##权重(可以定向多种倾向满足类型)
    22. preference:
    23. matchExpressions:
    24. - key: kubernetes.io/hostname ##key
    25. operator: NotIn ##不在列表内
    26. values:
    27. - k8s3 ##key的值

     

    pod: 

    • pod 亲和性和反亲和性
    • podAffinity 主要解决POD可以和哪些POD部署在同一个拓扑域中的问题(拓扑域用主机标签实现,可以是单个主机,也可以是多个主机组成的cluster、zone等。)
    • podAntiAffinity主要解决POD不能和哪些POD部署在同一个拓扑域中的问题。它们处理的是Kubernetes集群内部POD和POD之间的关系。
    • Pod 间亲和与反亲和在与更高级别的集合(例如 ReplicaSets,StatefulSets,Deployments 等)一起使用时,它们可能更加有用。可以轻松配置一组应位于相同定义拓扑(例如,节点)中的工作负载。
    (2)podaffinity(亲和
    1. vim podaffinity.yaml
    2. apiVersion: apps/v1
    3. kind: Deployment ##创建控制器
    4. metadata:
    5. name: nginx-deployment
    6. labels:
    7. app: nginx
    8. spec:
    9. replicas: 3
    10. selector:
    11. matchLabels:
    12. app: nginx
    13. template:
    14. metadata:
    15. labels:
    16. app: nginx
    17. spec:
    18. containers:
    19. - name: nginx
    20. image: nginx
    21. affinity:
    22. podAffinity: ##pod亲和
    23. requiredDuringSchedulingIgnoredDuringExecution: ##必须满足
    24. - labelSelector:
    25. matchExpressions:
    26. - key: app ##app=nginx的pod
    27. operator: In
    28. values:
    29. - nginx
    30. topologyKey: "kubernetes.io/hostname"

     

    (3)podantiaffinity(反亲和
    1. [root@k8s2 node]# vim podantiaffinity.yaml
    2. apiVersion: apps/v1
    3. kind: Deployment
    4. metadata:
    5. name: nginx-deployment
    6. labels:
    7. app: nginx
    8. spec:
    9. replicas: 3
    10. selector:
    11. matchLabels:
    12. app: nginx
    13. template:
    14. metadata:
    15. labels:
    16. app: nginx
    17. spec:
    18. containers:
    19. - name: nginx
    20. image: nginx
    21. affinity:
    22. podAntiAffinity: ##比较亲和,加了Anti
    23. requiredDuringSchedulingIgnoredDuringExecution:
    24. - labelSelector:
    25. matchExpressions:
    26. - key: app
    27. operator: In
    28. values:
    29. - nginx
    30. topologyKey: "kubernetes.io/hostname"

    pod反亲和倾向满足

    1. apiVersion: apps/v1
    2. kind: Deployment
    3. metadata:
    4. name: node-affinity
    5. spec:
    6. replicas: 3
    7. selector:
    8. matchLabels:
    9. app: nginx
    10. template:
    11. metadata:
    12. labels:
    13. app: nginx
    14. spec:
    15. tolerations:
    16. - effect: NoSchedule
    17. operator: Exists
    18. - effect: NoExecute
    19. operator: Exists
    20. containers:
    21. - name: nginx
    22. image: nginx
    23. affinity:
    24. podAntiAffinity:
    25. preferredDuringSchedulingIgnoredDuringExecution:
    26. - weight: 100
    27. podAffinityTerm:
    28. labelSelector:
    29. matchExpressions:
    30. - key: app
    31. operator: In
    32. values:
    33. - nginx
    34. topologyKey: kubernetes.io/hostname
    35. nodeAffinity:
    36. requiredDuringSchedulingIgnoredDuringExecution:
    37. nodeSelectorTerms:
    38. - matchExpressions:
    39. - key: disktype
    40. operator: In
    41. values:
    42. - ssd
    43. - sata

    4、Taints

    • NodeAffinity节点亲和性,是Pod上定义的一种属性,使Pod能够按我们的要求调度到某个Node上,而Taints则恰恰相反,它可以让Node拒绝运行Pod,甚至驱逐Pod。
    • Taints(污点)是Node的一个属性,设置了Taints后,所以Kubernetes是不会将Pod调度到这个Node上的,于是Kubernetes就给Pod设置了个属性Tolerations(容忍),只要Pod能够容忍Node上的污点,那么Kubernetes就会忽略Node上的污点,就能够(不是必须)把Pod调度过去。
    • 可以使用命令 kubectl taint 给节点增加一个 taint
    • $ kubectl taint nodes node1 key=value:NoSchedule  //创建
    • $ kubectl describe nodes  server1 |grep Taints  //查询
    • $ kubectl taint nodes node1 key:NoSchedule-  //删除

    其中[effect] 可取值: [ NoSchedule | PreferNoSchedule | NoExecute ]

    • NoSchedule:POD 不会被调度到标记为 taints 节点。
    • PreferNoSchedule:NoSchedule 的软策略版本。
    • NoExecute:该选项意味着一旦 Taint 生效,如该节点内正在运行的 POD 没有对应 Tolerate 设置,会直接被逐出。

     

    1. vim taint.yaml
    2. apiVersion: apps/v1
    3. kind: Deployment
    4. metadata:
    5. labels:
    6. app: web
    7. name: web
    8. spec:
    9. replicas: 3
    10. selector:
    11. matchLabels:
    12. app: web
    13. template:
    14. metadata:
    15. labels:
    16. app: web
    17. spec:
    18. containers:
    19. - image: nginx
    20. name: nginx

    设置taint
    1. kubectl taint node k8s2 k1=v1:NoSchedule
    2. kubectl describe nodes k8s2 |grep Tain
    3. kubectl scale deployment web --replicas 6
    4. kubectl taint node k8s2 k1=v1:NoExecute
    5. kubectl describe nodes k8s2 |grep Tain

     设置 tolerations

    tolerations中定义的key、value、effect,要与node上设置的taint保持一直

    • 如果 operator 是 Exists value可以省略
    • 如果 operator 是 Equal ,则key与value之间的关系必须相等
    • 如果不指定operator属性,则默认值为Equal

    还有两个特殊值

    • 当不指定key,再配合Exists 就能匹配所有的key与value可以容忍所有污点
    • 当不指定effect则匹配所有的effect
    1. vim taint.yaml
    2. apiVersion: apps/v1
    3. kind: Deployment
    4. metadata:
    5. labels:
    6. app: web
    7. name: web
    8. spec:
    9. replicas: 6
    10. selector:
    11. matchLabels:
    12. app: web
    13. template:
    14. metadata:
    15. labels:
    16. app: web
    17. spec:
    18. tolerations:
    19. - operator: Exists ##
    20. effect: NoSchedule ##
    21. containers:
    22. - image: nginx
    23. name: nginx

     容忍所有taints

    1. vim taint.yaml
    2. apiVersion: apps/v1
    3. kind: Deployment
    4. metadata:
    5. labels:
    6. app: web
    7. name: web
    8. spec:
    9. replicas: 6
    10. selector:
    11. matchLabels:
    12. app: web
    13. template:
    14. metadata:
    15. labels:
    16. app: web
    17. spec:
    18. tolerations:
    19. - operator: Exists
    20. containers:
    21. - image: nginx
    22. name: nginx

    5、cordon、drain、delete

    • 影响Pod调度的指令还有:cordon、drain、delete,后期创建的pod都不会被调度到该节点上,但操作的暴力程度不一样。
    • cordon 停止调度
    • 影响最小,只会将node调为SchedulingDisabled,新创建pod,不会被调度到该节点,节点原有pod不受影响,仍正常对外提供服务。
    • drain 驱逐节点
    • 首先驱逐node上的pod,在其他节点重新创建,然后将节点调为SchedulingDisabled
    •  delete 删除节点
    • 最暴力的一个,首先驱逐node上的pod,在其他节点重新创建,然后,从master节点删除该node,master失去对其控制,如要恢复调度,需进入node节点,重启kubelet服务

     

    1. kubectl create deployment demo --image nginx --replicas 3
    2. kubectl cordon k8s2
    3. kubectl get node
    4. kubectl scale deployment demo --replicas 6
    5. kubectl drain k8s2 --ignore-daemonsets
    6. kubectl delete nodes k8s2
    7. kubectl get node

    k8s2节点重启kubelet服务重新加入集群

    1. systemctl restart kubelet
    2. kubectl get node

     

  • 相关阅读:
    你必须知道的4种 Redis 集群方案及优缺点对比
    AI模型风险评估 第1部分:动机
    08 SQL进阶 -- 集合运算 -- 表的连结(JOIN)
    mycat2搭建mysql一主双从集群
    嵌入式学习-核心板、开发板和单片机
    OSPF路由策略引入
    【python核心】函数式编程(二)
    同步工具 FreeFileSync
    结合均线分析k线图的基本知识
    MicroPython RP2040点灯实验
  • 原文地址:https://blog.csdn.net/weixin_56744753/article/details/134274385