k8s的集群调度---下

发布时间:2024年01月09日

前情回顾

预算策略:过滤出合适的节点

优选策略:选择部署的节点

nodeName:硬匹配,不走调度策略。node01.

nodeSelector:根据节点的标签选择,会走调度算法。

只要是走调度算法,在不满足预算策略的情况下,所有pod都是pending。

node节点的亲和性:硬策略和软策略

硬策略:必须一定。匹配原则:根据节点的标签

软策略:尽量满足你的要求。

pod的亲和性和反亲和性

调度策略匹配标签操作符拓展域调度目标
node亲和性 主机标签 In,NotIn,Exists,DoesExists,Gt,Lt 不支持 指定主机
pod亲和性 pod的标签 In(在),NotIn(不在),Exists(存在),DoesExists(不存在) 支持 pod和指定标签的pod部署在同一个拓扑域
pod反亲和性 pod的标签 In,NotIn,Exists,DoesExists 支持 pod和指定标签的pod部署在同一个拓扑域

拓扑域:k8s集群节点当中的一个组织结构,可以根据节点的物理关系或者逻辑关系进行划分。

可以用来表示节点之间的空间关系,网络关系或者其他类型的关系。

pod内的拓扑域也就是? --->? 标签

pod亲和性演示操作

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx1
  name: nginx1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx1
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      containers:
      - image: nginx:1.22
        name: nginx1
      affinity:
        podAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - nginx1
            topologyKey: test1
#toplogyKey指定拓扑域的关键字段,表示正在使用test1作为拓扑域的关键字。test1一般都是节点标签,表示希望把pod调度到包含有app标签的Pod,值为nginx1的在test1的拓扑域上的节点。

部署pod时候会遇到pending的情况,是因为指定条件没有一个可以满足!!!!

pod亲和性的软策略展示

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx1
  name: nginx1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx1
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      containers:
      - image: nginx:1.22
        name: nginx1
      affinity:
        podAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: DoesNotExist
              topologyKey: test3

pod的反亲和性


apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx1
  name: nginx1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx1
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      containers:
      - image: nginx:1.22
        name: nginx1
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - nginx1
              topologyKey: test3

总结:反亲和性顾名思义和亲和性相反,相当于NotIn

注意点:

1.pod的亲和性策略,在配置时,必须要加上拓扑域的关键字

2.pod亲和性的策略也分为硬策略和软策略

3.pod亲和性的notin可以替代反亲和性

4.pod亲和性主要是为了把相关联的pod部署在同一个节点。

k8s中污点和容忍可以配合node的亲和性一块使用

污点与容忍的概念


节点亲和性,是Pod的一种属性(偏好或硬性要求),它使Pod被吸引到一类特定的节点。Taint 则相反,它使节点能够排斥一类特定的 Pod。

污点(Taint) 和 容忍(Toleration) 相互配合,可以用来避免 Pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ,这表示对于那些不能容忍这些 taint 的 Pod,是不会被该节点接受的。如果将 toleration 应用于 Pod 上,则表示这些 Pod 可以(但不一定)被调度到具有匹配 taint 的节点上。

当前 taint effect 支持如下三个选项:

●NoSchedule:表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上

●PreferNoSchedule:表示 k8s 将尽量避免将 Pod 调度到具有该污点的 Node 上

●NoExecute:表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上,同时会将 Node 上已经存在的 Pod 驱逐出去
?

注意点:节点服务器肯定是需要维护的,服务器关机,此时节点上的pod将会失效。在工作中我们主要部署pod的方式控制器部署。尤其是deployment用的最多。一旦节点使用的是驱逐。控制器创建的pod会在其他节点重新部署。所以驱逐的应用场景:资源迁移。

1.所有的pod都会被驱逐,和命名空间无关(包括flannel等),kube-proxy是节点组件,所以他还存在。

2.不论你的创建方式是什么,都会被驱逐

污点的基本操作

格式:kubectl describe nodes <节点名称> | grep Taints 
或者是kubectl describe nodes <节点名称> | grep -i taints
eg:查看master01的污点
kubectl describe nodes master01 |grep -i taints

如何设置污点

kubectl taint node node01 key=1:NoSchedule

kubectl taint node node名称 名称

污点的容忍机制

容忍:即使集群上设置了污点,有了容忍机制,依然可以在设置为污点的节点上部署pod。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx2
  name: nginx2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx2
  template:
    metadata:
      labels:
        app: nginx2
    spec:
      containers:
      - image: nginx:1.22
        name: nginx2
      tolerations:
      - key: key
        operator: Equal
        value: "1"
        effect: NoSchedule
容忍策略:容忍节点上的标签key,对应的标签值是1,effect就是对应的污点的类型

其他都是NoSchedule,所以无法匹配,就是pending。

污点---NoExcute

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx2
  name: nginx2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx2
  template:
    metadata:
      labels:
        app: nginx2
    spec:
      containers:
      - image: nginx:1.22
        name: nginx2
      tolerations:
      - key: key
        operator: Equal
        value: "2"
        effect: NoExecute
        tolerationSeconds: 10

到时间就会销毁,反复循环

特殊情况:NotExecute依然可以部署pod,但是有生命周期,时间一到,pod会被销毁,生命周期结束之后会驱逐一部分pod到其他节点

  tolerations:
      - key: key
        operator: Exists
        effect: NoSchedule


指定key的值(节点的标签值),但是不指定污点的类型,所有节点上只要包含了指定的标签名,可以容忍所有的污点

      tolerations:
      - operator: Exists
        effect: NoSchedule
没有key,不匹配节点的标签,容忍所有污点,但是类型是指定的类型(只要是effect指定的,我都能容忍)

总结:

多个master节点:

kubelet taint node master节点名称 node-role.kubernetes.io/master=PreferNoSchedule

尽量不往master节点上部署pod,但是不是一定的,防止资源浪费。自定义一个标签。

业务维护: node02需要维护两个小时,但是这个业务上还有pod在运行,此时就需要将这个节点的污点设置成NoExecute。

我们部署pod一般都使用deployment部署,会在其他的节点重新部署,并不是被杀死

自主式的pod会被杀死。

一旦节点恢复,一定要把污点驱逐

cordon和drain

cordon:可以直接把节点标记为不可用的状态。

kubectl get node
kubectl cordon master01
kkubectl get node
kubectl uncordon master01

drain

排水,把该节点下的节点全部转移到其他的node节点上运行。

1.一旦执行drain,被执行的节点会变成不可调度状态。

2.会驱逐该节点上的所有pod。

kubectl drain node02 --ignore-daemonsets --delete-local-data --force


drain:排水,标记node节点为不可调度,然后驱逐pod
--ignore-daemonsets:无视daemonsets部署的pod,daemonsets部署的pod还在节点
--delete-local-data:有本地挂载卷的pod会被强制杀死
--force:强制释放不是控制器管理的pod。
还是如何管理和部署pod

文章来源:https://blog.csdn.net/qq_51506982/article/details/135477486
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。