Deployment和污点、容忍度

最新推荐文章于 2025-03-15 16:20:19 发布
最新推荐文章于 2025-03-15 16:20:19 发布
阅读量981 收藏 28
点赞数 12
文章标签： k8s
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/xiaogengtongxu/article/details/141467075
版权

文章目录

一、污点、容忍度

Kubernetes（k8s）中的“污点”（Taints）和“污点容忍”（Tolerations）是用于节点调度控制的一种机制。它们提供了一种方法来影响 Pod 被调度到节点上的策略，通过这种方式，你可以防止特定的 Pod 被调度到不合适的节点，或仅允许特定的 Pod 被调度到指定的节点。

污点（Taints）

污点是应用在节点上的属性，它告诉调度器不可以将 Pods 安排到这个节点上，除非该 Pod 可以容忍该污点。每个污点包含三个属性：

  1. 键（Key） ：一个唯一标识污点的名称。

  2. 值（Value） ：键的附加信息。

  3. 效应（Effect） ：当污点存在而 Pod 无法容忍时，会产生的影响。主要有以下三种类型：

    • NoSchedule: 调度器不会将 Pod 调度到有此污点的节点上。
    • PreferNoSchedule: 调度器会尽量不将 Pod 调度到有此污点的节点上，但不是绝对的。
    • NoExecute: 除了不允许新的 Pod 调度到节点上，还会驱逐当前不容忍此污点的 Pod。

污点容忍（Tolerations）

Pod 可以有相应的容忍来匹配节点的污点，这允许 Pod 在有污点的节点上运行。容忍由键、值和效果组成，并必须匹配节点上的污点才能调度 Pod 到该节点。

应用场景

  1. 隔离工作负载：通过使用污点和容忍，可以确保特定类型的工作负载不会混合在同一节点上。例如，隔离开发和生产环境下的负载。
  2. 优先处理关键任务：可以通过设置污点来保护关键节点，使得只有特定的关键任务 Pod 可以被调度到这些节点上。
  3. 管理资源和节点健康状况：用来限制访问资源紧张的节点或正在进行维护的节点。
  4. 节点动态维护：在节点需要维护时，使用 NoExecute 污点来驱逐不需要的工作负载。

实际操作

配置污点
标记污点

kubectl taint node slave node-type=production:NoShchedule

注意需要选择污点类型。

删除污点

kubectl taint node slave node-type=production:NoShchedule-

查看污点

kubectl describe node slave1|grep -i Taints

在这里插入图片描述
当我在slave1上配置了污点之后，master主动将pod全部调度到slave2上。

在这里插入图片描述
配置容忍度

apiVersion: apps/v1  
kind: ReplicaSet  
metadata:  
  name: my-replicaset  
spec:  
  replicas: 10  
  selector:  
    matchLabels:  
      app: myapp  
  template:  
    metadata:  
      labels:  
        app: myapp  
    spec:  
      containers:  
      - name: mycontainer  
        image: harbor.hiuiu.com/nginx/nginx:1.21.5  
        ports:  
        - containerPort: 80
      tolerations:
      - key: "node-type"
        operator: "Equal"
        value: "production"
        effect: "NoSchedule"

由于node2节点并没有配置污点，所以master会随机调度到两个节点上。
在这里插入图片描述

二、Deployment

在 Kubernetes 中，Deployment 是一种用于部署和管理应用程序的控制器，它提供了一种声明式的方式来创建和管理 Pod 和集群的相关资源。Deployment 是应用管理中最常用的资源类型之一，因为它提供了许多强大的功能用来维护和更新应用程序的状态。

核心组件

  1. 控制器模式（Controller Pattern） ：

    • Kubernetes 使用控制器模式来实现资源的自动化管理。Deployment 控制器是 Kubernetes 控制平面的一部分，负责监视 Deployment 对象的状态，并确定需要进行哪些操作以达到期望状态。

  2. 副本集（ReplicaSet） ：

    • Deployment 的主要作用是管理 Pod 的副本集。ReplicaSet 确保指定数量的 Pod 副本在任何给定时间内都是运行的。Deployment 创建并管理这些 ReplicaSet。
    • 每次更新 Deployment 时，Deployment 控制器创建一个新的 ReplicaSet，并通过控制旧的和新的 ReplicaSet 的标签选择器来逐步增加新 Pod 的副本数量，减少旧 Pod 的副本数量。

特性和功能

  1. 声明式更新：Deployment 允许用户声明所需的状态（如应用程序版本或副本数），Kubernetes 将自动调整集群以匹配这个状态。这种机制能够确保更新过程是一致的并且易于管理。
  2. 滚动更新：将应用程序从一个版本更新到另一个版本是 Deployment 最常用的功能之一。Deployment 可以以控制的速度逐步替换旧版本的 Pod，以便在发生问题时可以轻松回滚。
  3. 回滚更新：如果新版本的更新出现问题，可以轻松地滚回到之前的一个稳定版本。Kubernetes 会自动记录 Deployment 的历史版本，以便于回滚。
  4. 扩展和缩减：使用 Deployment 可以轻松调整应用的副本数，这意味着可以轻松地应对流量的变化。
  5. 自愈（自愈合） ：如果一个 Pod 出现故障，Deployment 会基于定义的状态即刻进行恢复操作，确保应用程序始终处于所需的状态。
  6. 多副本控制：确保集群中始终有指定数量的 Pod 正在运行，此功能对于负载均衡和高可用性至关重要。

应用场景

  1. 持续交付和集成：在 CI/CD 流水线中，Deployment 常用于自动发布新应用版本，利用其滚动更新和回滚功能简化管理和发布过程。
  2. 负载扩展：对于流量波动较大的应用程序，可以通过调整 Deployment 的副本数量来快速扩容或缩容。
  3. 高可用性：使用 Deployment 保证跨多个节点部署 Pod，增加应用的冗余性和可用性。
  4. 测试和实验：可以快速部署新版本的应用以进行测试和实验，同时确保即便在实验中出现问题也可以快速回滚。
  5. 应用稳定性管理：以自愈能力来增强应用的鲁棒性，在节点或 Pod 故障时自动恢复到正常状态。

Deployment 在 Kubernetes 集群管理中占据核心位置，它为开发和运维人员提供了一种简化且高效的方式来管理容器化应用的生命周期。它不仅能简化应用的部署流程，还能带来稳健性和灵活性。

实际操作

创建deployment

创建deployment一般是用yaml文件创建的。
查看配置

kubectl describe deployments.apps  +名字

在这里插入图片描述

查看状态

kubectl rollout status deployment/名字

在这里插入图片描述

查看当前命名空间下的deployment对象资源

kubectl get deployments.apps
kubectl get rs
kubectl get pod

配置文件

apiVersion: apps/v1  
kind: Deployment  
metadata:  
  name: nginx-deployment  
  labels:  
    app: nginx-dep  
spec:  
  replicas: 10  
  selector:  
    matchLabels:  
      app: nginx  
  template:  
    metadata:  
      labels:  
        app: nginx  
    spec:  
      containers:  
      - name: nginx  
        image: harbor.hiuiu.com/nginx/nginx:1.21.5  
        ports:  
        - containerPort: 80

在这里插入图片描述
这里构建pod的流程是先构建ReplicaSet，然后由副本集构建下面的pod。观察各个资源对象的名字就可以知道。

判断deployment升级

在 Kubernetes 中，Deployment 判断是否需要升级及进行升级的过程是通过对比期望状态和当前状态来实现的。该过程涉及以下几个关键环节：

比较期望状态和现有状态
  1. 期望状态：由用户通过 YAML/JSON 文件定义，描述应用的期望状态（包括镜像版本、配置、环境变量等）。
  2. 当前状态：由 Kubernetes 控制平面实时维护，表示集群中相关资源的实际状态。

当这两者之间存在差异时（例如改变镜像版本、修改副本数量或调整环境变量等），Kubernetes 就会认为需要进行一次更新或升级操作。

如何确定需要升级
  • 版本变更：如果 Deployment 配置的容器镜像版本有所变化（即 .spec.template.spec.containers[].image 发生变化）。
  • 配置变更：任何 Pod 模板中的配置变更（如环境变量、端口定义、资源限制等）都会触发新的 ReplicaSet 的创建。
  • 副本数变更：改变 .spec.replicas（Pod副本数）会直接导致 Deployment 动态调整正在运行的 Pod 数量。
检测和执行升级

  1. 检测变更：Deployment 控制器会监控与 Deployment 关联的所有资源。当检测到变更时，控制器会开始执行升级过程。

  2. 滚动更新：

    • Deployment 创建一个新的 ReplicaSet 来部署新的 Pod 模板版本。
    • 逐渐增加新的 ReplicaSet 中 Pod 的数量，同时减少旧 ReplicaSet 中 Pod 的数量，从而实现平滑过渡。

  3. 回滚支持：在升级过程中，如果检测到任何问题（例如健康检查失败、Pod 启动失败等），可以自动或手动回滚到前一个稳定的版本。
    使用该命令kubectl rollout status deployment/nginx-deployment查看升级状态

滚动更新

方法：

  1. vim 修改 YAML 文件

    • 使用命令行文本编辑器 vim 编辑一个 YAML 文件，通常是用来手动更新 Kubernetes 资源的配置。编辑器打开后，你可以手动更改 Deployment 的配置，例如更新镜像版本。

  2. ​kubectl set image deployment.v1.apps/nginx-deployment nginx1=镜像名​

    • 这个命令使用 kubectl 直接在命令行中更新 Deployment 中指定容器的镜像版本。
    • deployment.v1.apps/nginx-deployment 指定了要更新的 Deployment 资源的类型和名称。

  3. ​kubectl edit deployment/nginx-deployment​

    • 这个命令使用默认的命令行文本编辑器（通常是 vim）来直接编辑 Kubernetes 中现有的 Deployment 资源。
    • 它会拉取当前集群中 nginx-deployment 的 YAML 配置文件，你可以手动修改例如镜像版本、资源限制等部署配置。
    • 保存并退出编辑器后，Kubernetes 会应用这些更改。
      在这里插入图片描述

使用场景

  • ​kubectl set image​：
    用于快速更新 Deployment 中的镜像版本。这种方式快捷且减少可能的手动错误，但只是更新镜像，不能进行其他更复杂的配置更改。
  • ​kubectl edit​：
    用于需要对 Deployment 进行更细粒度的修改时，不仅可以更新镜像，还有更多关于应用配置的控制，类似于直接修改配置文件。

实验效果
滚动更新前：
在这里插入图片描述

滚动更新：
在这里插入图片描述
滚动更新后：
在这里插入图片描述

滚动更新策略

在 Kubernetes 中，自定义更新策略可以决定在应用更新过程中 Pod 的替换方式。这些策略是通过 Deployment 中的 strategy 字段配置的，主要有两种类型：Recreate 和 RollingUpdate。

  1. Recreate 策略
    在使用 Recreate 策略时，Kubernetes 会先终止旧版本的所有 Pod 然后再创建新版本的 Pod。这种策略适用于不需要保持服务可用性或在旧版本终止后新版本启动间允许短暂停机的情况。

    spec:  
  strategy:  
    type: Recreate

  2. RollingUpdate 策略
    RollingUpdate 策略通过逐步替换旧版本的 Pod 为新版本来更新服务，确保在整个更新过程中，服务始终保持可用状态。这是默认的更新策略，通常适用于需要保持高可用性的应用。

    • maxSurge: 控制在更新过程中可超出的最大副本数量。可以是绝对数量，或是占期望副本数的百分比。
    • maxUnavailable: 控制在更新过程中允许的最大不可用副本数量。同样可以是绝对数量或百分比。

    例如，配置为：

    spec:  
  strategy:  
    type: RollingUpdate  
    rollingUpdate:  
      maxSurge: 50%         # 超过的最大副本数允许是总副本数的 50%  
      maxUnavailable: 50%   # 更新过程中允许有 50% 的副本不可用

用法解释

  • Recreate:

    • 适合于没有客户端访问的应用，或者可以承受短暂中断的情况。
    • 更新过程中会出现停机，因为旧的全部停止后再启动新的。

  • RollingUpdate:

    • 适合于需要提供持续服务的应用。
    • 最大努力保持服务的可用性，通过逐步替换 Pod 的方式进行。
    • maxSurge 和 maxUnavailable 可以灵活配置，以优化更新速度与服务可用性之间的平衡。

常见命令

  1. 查看升级历史

    kubectl rollout history deployment/nginx-deployment
    • 用于查看指定 Deployment 的版本历史记录，包括每个版本的修订号和一些摘要信息。

  2. 回滚到指定版本

    kubectl rollout undo deployment/nginx-deployment --to-revision=1
    • 用于将 Deployment 回滚到指定的历史版本。--to-revision=1 指定回滚到版本 1。

  3. 动态缩放

    kubectl scale deployment/nginx-deployment --replicas=10
    • 用于动态调整 Deployment 的 Pod 副本数，将其修改为 10 个。
    • 也可以通过修改配置文件来更改。

  4. 锁定当前版本

    kubectl rollout pause deployment/nginx-deployment
    • 用于暂停 Deployment 的滚动更新。暂停后可以安全地进行检查或其他批量操作，而不会触发新的滚动更新。

  5. 解除锁定

    kubectl rollout resume deployment/nginx-deployment
    • 用于恢复 Deployment 的更新过程。如果之前暂停了 Deployment 的更新，恢复后更新会继续进行。
【云原生】Kubernetes中关于污点、亲和性和容忍度的详细用法教程与应用实战
景天科技苑
08-01 2万+
在Kubernetes中，污点（Taints）、亲和性（Affinity）和容忍度（Tolerations）是三个强大的工具，它们允许集群管理员精细控制Pod在节点上的调度。这些机制共同工作，确保Pod被调度到最适合它们的节点上，从而提高集群的效率和稳定性。本文将结合具体案例，详细介绍污点、亲和性和容忍度的用法。
亲和、反亲和调度、污点和污点容忍
叱咤少帅的博客
01-29 123
亲和与反亲和调度
K8S 污点和容忍度（Taint，Toleration）
小五
04-17 2141
在 Kubernetes 中，污点（Taints）和容忍度（Tolerations）是用于节点调度的一种机制，它们允许你控制哪些 Pod 能够调度到哪些节点上。
污点与容忍
m0_56014908的博客
04-04 729
文章目录一、污点设置二、添加，查看，删除污点三、添加容忍总结 一、污点设置 kubectl taint node node名 key=value:污点三个可选值 当前taint effect支持如下三个选项: NoSchedule:表示k8s将不会将Pod调度到具有该污点的Node上 PreferNoschedule:表示k8s将尽量避免将Pod调度到具有该污点的Node上 NoExecute:表示k8s将不会将Pod调度到具有该污点的Node上,同时会将Node上已经存在的Pod驱逐出去 注：每
【一起来学kubernetes】11、Deployment使用详解
技术人集结地
03-15 1126
Deployment是Kubernetes中一种声明式控制器，用于管理和维护一组Pod副本。它主要用于管理无状态应用的生命周期，通过声明Deployment，可以自动化地控制应用的副本数量、进行无停机更新、扩展、缩容等。
Kubernetes Taint(污点) 和 Toleration(容忍)
RAB
10-31 1133
Kubernetes Taint(污点) 和 Toleration(容忍)。
K8S（七）—污点、容忍
qq_51010919的博客
12-13 1356
污点是一种节点级别的属性，它告诉Kubernetes哪些节点不适合运行特定类型的Pod。节点上的污点可以阻止Pod被调度到不适合的节点上。
Kubernetes-污点和容忍
咸鱼很闲
12-13 472
污点和容忍 污点(Taints) 前面的调度方式都是站在Pod的角度上，通过在Pod上添加属性，来确定Pod是否要调度到指定的Node上，其实我们也可以站在Node的角度上，通过在Node上添加污点属性，来决定是否允许Pod调度过来。 Node被设置上污点之后就和Pod之间存在了一种相斥的关系，进而拒绝Pod调度进来，甚至可以将已经存在的Pod驱逐出去。 污点的格式为: `key=valueleffect ’ , key和value是污点的标签，effect描述污点的作用，支持如下三个选项: Prefer
Kubernetes之pod的污点和容忍度
qq_63627848的博客
08-11 2074
pod的污点和容忍度
K8s污点容忍度横向主节点
weixin_40418457的博客
06-16 344
污点 节点亲和性 容忍度 污点是K8s高级调度的特性，用于限制哪些Pod可以被调度到某一个节点。在普通节点横向时我们可以使用污点容忍度创建恶意pod来对主节点进行横向控制。 1、kube-scheduler调度 kube-scheduler是Kubernetes 集群的默认调度器，并且是集群控制面(master)的一部分。对每一个新创建的Pod或者是未被调度的Pod，kube-scheduler会选择一个最优的Node去运行这个Pod。 然而，Pod内的每一个容器对资源都有不同的需求，而且Pod本身也有不同
K8S标签和污点容忍
qq_41296573的博客
07-13 1600
K8S标签和污点案例
k8s-污点 (Taint)和容忍 (Tolerations)
weixin_61269220的博客
10-13 1万+
如果一个节点被标记为有污点，那么意味着不允许pod调度到该节点，除非pod也被标记为可以容忍污点节点在使用kubeadm部署的k8s集群的时候应该会发现，通常情况下，应用是不会调度到master节点的。因为kubeadm部署的k8s集群默认给master节点加了Taints（污点）设置了污点的Node将根据taint的effect：NoSchedule、PreferNoSchedule、NoExecute和Pod之间产生互斥的关系，Pod将在一定程度上不会被调度到Node上。
【云原生之kubernetes系列】--污点与容忍
weixin_58519482的博客
02-01 729
【代码】【云原生之kubernetes系列】--污点与容忍。
19，污点和容忍
weixin_43292547的博客
10-13 155
污点（Taints） 前面的调度方式都是站在Pod的角度上，通过在Pod上添加属性，来确定Pod是否要调度到指定的Node上，其实我们也可以站在Node的角度上，通过在Node上添加污点属性，来决定是否允许Pod调度过来。 Node被设置上污点之后就和Pod之间存在了一种相斥的关系，进而拒绝Pod调度进来，甚至可以将已经存在的Pod驱逐出去。 污点的格式为：key=value:effect, key和value是污点的标签，effect描述污点的作用，支持如下三个选项： PreferNoSchedule：
k8s--基础--20--污点和容忍度
zhou920786312的博客
08-11 3653
一个toleration和一个taint相"匹配"是指它们有一样的key和effect如果 operator 是 Exists，此时toleration不能指定value如果 operator 是 Equal，此时它们的value应该相等如果一个toleration的effect为空，则key值与之相同的相匹配taint的effect可以是任意值。NoSchedule：不允许调度，已经调度的不受影响。...
17、Kubernetes核心技术 - 污点（Taints）和污点容忍（Tolerations）
weixiaohuai的博客
01-05 1969
上一篇文章介绍了节点亲和性，它主要实现的是将Pod强制或者尽可能调度到满足某些条件的node节点上【通过在Pod上添加属性，来确定Pod是否要调度到指定的节点上，k8s中的污点，它的行为刚好与节点亲和性相反，污点可以将节点和 Pod 达到互斥的效果，让Pod不被调度到存在污点的那些节点上【在Node节点上添加污点属性（Taints），来避免Pod被分配到不合适的节点上】；k8s中的污点容忍，则可以让 Pod 调度到带有污点的节点上。taints（污点）
3.11 污点和容忍度
u010502101的博客
10-05 1231
文章目录一、污点和容忍度介绍1、显示污点信息2、显示容忍度信息3、污点因子二、污点应用三、污点容忍度应用 上一章节介绍了，pod的调度方式有选择器、节点亲和性、pod亲和性和反亲和性，本章节继续介绍pod的其他调度方式：污点和容忍度。 一、污点和容忍度介绍 污点是相对于节点说的，一旦给某个节点上打了污点了标签，pod调度时就会阻止pod调度在该节点上，如果pod设置了容忍这个节点的污点的话，pod也可以调度在有污点的节点上。 1、显示污点信息 在集群上部署pod时经常发现，pod一般被调度在各个子节点上进行
Kubernetes集群Pod资源污点及容忍详解（二十）
热门推荐
江晓龙的博客
08-06 1万+
1.pod污点和容忍 污点（Taints） 定向调度和亲和性调度都是站在pod的角度上，选择要调度在那个node节点上，其实也可以站在node的角度上，在node节点上添加污点属性，决定是否允许pod调度过来 node被设置上污点之后就和pod之间存在了一种相斥的关系，从而拒绝pod调度进来，甚至可以将已存在的pod驱逐出去 污点的设置格式为：key=value:effect，key和value都是人为自己定义的，是设置污点的标签，effect是描述污点的作用 使用kubeadm搭建的k8s集群，maste
【Kubernetes】Kubernetes的污点和容忍度
wjianwei666的专栏
09-25 342
在K8S中，如果Pod能容忍某个节点上的污点，那么Pod就可以调度到该节点。如果不能容忍，那就无法调度到该节点。
污点和容点什么意思
最新发布
04-22
<think>好的，我现在需要详细解释Kubernetes中的污点（Taints）和容忍度（Tolerations）。用户之前的问题是关于Pod调度的问题，特别是当节点资源不足或设置了污点时的情况。现在用户明确想了解污点和容忍度的具体含义，我需要结合之前的回答和提供的引用内容来组织信息。 首先，用户提供的引用[1]、[2]、[3]都涉及到污点和容忍度的定义、作用以及使用场景。我需要整合这些信息，确保覆盖基本概念、核心作用、使用方法、注意事项以及最佳实践。同时，用户之前的问题中提到了当控制器Pod满了或节点资源不足时的处理，所以需要将污点和容忍度与这些实际场景联系起来。 我应该从定义开始，解释污点和容忍度各自是什么，然后说明它们如何协同工作。需要提到污点的三种效果（NoSchedule、PreferNoSchedule、NoExecute）以及容忍度的匹配规则。接着，结合引用中的信息，比如引用[3]提到的污点格式和kubectl命令，给出具体的操作示例，帮助用户理解如何实际应用。 另外，用户可能对如何查看节点的污点和如何为Pod设置容忍度感兴趣，需要提供相关的kubectl命令和YAML示例。同时，要注意区分污点与节点亲和性的不同，避免混淆，如引用[3]提到的亲和性，但用户当前问题主要关注污点和容忍度，所以需要明确两者的区别。 还需要包括使用场景，比如专用节点、节点维护、驱逐Pod等，这些在引用[2]和[3]中都有提到。案例分析部分可以增强实用性，例如如何为GPU节点设置污点，或者如何在维护期间驱逐Pod。最后，总结最佳实践，帮助用户正确应用这一机制，避免常见错误。 需要检查是否有遗漏的重要点，比如多个污点和容忍度的处理逻辑，引用[1]提到Kubernetes处理多个污点的方式是过滤，这点需要详细说明。同时，注意引用中的关键点，如NoExecute不仅影响调度还会驱逐现有Pod，这点在之前的回答中也提到过，需要强调。 最后，确保语言通俗易懂，结构清晰，分点阐述，并附上示例和命令，方便用户理解与实践。可能还需要回答用户潜在的问题，比如如何处理多个污点，或者如何调试调度问题，但根据当前问题，主要集中在含义和详解上，所以保持聚焦。</think>### Kubernetes 污点（Taints）与容忍度（Tolerations）详解 --- #### 一、基本概念 1. **污点（Taints）** 污点是**施加在节点上的标记**，用于限制哪些 Pod 可以调度到该节点。它的核心作用是**排斥不匹配的 Pod**，类似于在节点上贴“禁止进入”的告示牌。 - **语法格式**：`key=value:effect` 例如：`gpu=true:NoSchedule` - **核心作用**： - 隔离专用节点（如 GPU 节点、高存储节点） - 防止普通 Pod 调度到关键节点 - 节点维护时驱逐 Pod 2. **容忍度（Tolerations）** 容忍度是**赋予 Pod 的属性**，允许 Pod 忽略节点的污点限制。它相当于 Pod 的“通行证”，使其能够调度到被污染的节点。 - **语法格式**（YAML 示例）： ```yaml tolerations: - key: "gpu" operator: "Equal" value: "true" effect: "NoSchedule" ``` - **核心作用**： - 允许特定 Pod 突破污点限制 - 实现精细化资源分配（如机器学习任务调度到 GPU 节点） --- #### 二、污点的三种效果（Effect） | 类型 | 行为 | 适用场景 | |------------------|----------------------------------------------------------------------|------------------------------| | `NoSchedule` | 禁止无容忍度的 Pod 调度到节点（**仅影响新调度**） | 专用节点隔离 | | `PreferNoSchedule` | 尽量避免调度，但非强制（**低优先级限制**） | 非关键资源预留 | | `NoExecute` | 禁止调度 + **驱逐已运行但无容忍度的 Pod**（默认驱逐延迟 300 秒） | 节点维护、故障隔离 | --- #### 三、工作原理 1. **调度流程中的污点过滤** Kubernetes 调度器按以下逻辑处理污点与容忍度： - 检查节点所有污点 → 过滤 Pod 已容忍的污点 → 剩余污点决定是否允许调度 - **关键规则**： - Pod 必须容忍节点**所有未被忽略的污点**（`effect=NoSchedule/NoExecute`） - 若剩余污点含 `NoSchedule` → 禁止调度 - 若剩余污点含 `NoExecute` → 禁止调度并驱逐现有 Pod 2. **多污点与多容忍度匹配逻辑** - **示例**：节点设置两个污点 ```bash kubectl taint nodes node01 gpu=true:NoSchedule # 污点1 kubectl taint nodes node01 ssd=true:NoExecute # 污点2 ``` - **Pod 容忍度配置**： ```yaml tolerations: - key: "gpu" # 仅容忍污点1 operator: "Exists" effect: "NoSchedule" ``` - **结果**： - 污点2（`ssd=true:NoExecute`）未被容忍 → Pod 无法调度到 `node01` --- #### 四、核心操作指南 1. **管理节点污点** - **添加污点**： ```bash kubectl taint nodes <node-name> key=value:effect # 示例：禁止普通 Pod 调度到 GPU 节点 kubectl taint nodes gpu-node-1 hardware=gpu:NoSchedule ``` - **删除污点**： ```bash kubectl taint nodes <node-name> key:effect- # 示例：移除 GPU 节点的 NoSchedule 限制 kubectl taint nodes gpu-node-1 hardware:NoSchedule- ``` - **查看节点污点**： ```bash kubectl describe node <node-name> | grep Taints ``` 2. **配置 Pod 容忍度** **YAML 示例**（允许 Pod 调度到含 `disk=ssd:NoSchedule` 污点的节点）： ```yaml apiVersion: v1 kind: Pod metadata: name: ssd-app spec: containers: - name: nginx image: nginx tolerations: - key: "disk" operator: "Equal" value: "ssd" effect: "NoSchedule" ``` 3. **高级匹配规则** - **`operator: Exists`**：容忍所有含指定 `key` 的污点（无需匹配 `value`） ```yaml tolerations: - key: "gpu" operator: "Exists" # 容忍所有 effect 为 NoSchedule 的 gpu 污点 effect: "NoSchedule" ``` - **容忍所有污点**（慎用！可能破坏隔离性）： ```yaml tolerations: - operator: "Exists" # 无 key 和 effect 限制 ``` --- #### 五、典型使用场景 1. **专用硬件节点隔离** - **场景**：GPU 节点仅允许机器学习任务使用 - **操作**： ```bash # 节点添加污点 kubectl taint nodes gpu-node-1 hardware=gpu:NoSchedule ``` ```yaml # Pod 添加容忍度 tolerations: - key: "hardware" operator: "Equal" value: "gpu" effect: "NoSchedule" ``` 2. **节点维护与驱逐** - **场景**：节点需要停机维护，需驱逐所有 Pod - **操作**： ```bash # 添加 NoExecute 污点触发驱逐 kubectl taint nodes node-01 maintenance=true:NoExecute # 维护完成后移除污点 kubectl taint nodes node-01 maintenance:NoExecute- ``` 3. **灰度发布控制** - **场景**：限制新版本 Pod 仅调度到特定节点 - **操作**： ```bash # 为测试节点添加污点 kubectl taint nodes test-node-1 env=test:NoSchedule ``` ```yaml # 新版本 Deployment 配置容忍度 spec: template: spec: tolerations: - key: "env" operator: "Equal" value: "test" effect: "NoSchedule" ``` --- #### 六、注意事项与最佳实践 1. **避免过度使用 `NoExecute`** - 若大量节点设置 `NoExecute` 污点且 Pod 未配置容忍度，可能导致 Pod 频繁被驱逐，引发服务不稳定。 2. **区分** `污点` **与** `节点亲和性` | 机制 | 作用方向 | 优先级逻辑 | |---------------|----------------|-------------------------| | 污点/容忍度 | **排斥性**控制 | “必须满足”条件 | | 节点亲和性 | **吸引性**控制 | “尽量满足”条件 | 3. **调试调度问题** - 检查 Pod 事件日志： ```bash kubectl describe pod <pod-name> | grep Events -A 10 ``` - 查看节点资源与污点状态： ```bash kubectl describe node <node-name> | grep -E "Taints|Allocatable" ``` --- ### 总结 污点与容忍度是 Kubernetes 中实现**精细化调度控制**的核心机制，通过“节点排斥”与“Pod 豁免”的配合，可有效管理专用资源、保障集群稳定性。实际使用中需注意避免过度宽松的容忍度配置（如 `operator: Exists`），并结合亲和性规则实现更灵活的调度策略[^1][^2][^3]。 --- ### 相关问题 1. 如何通过节点亲和性（Node Affinity）实现 Pod 的定向调度？ 2. Kubernetes 中 `NoExecute` 污点的驱逐延迟（TolerationSeconds）如何配置？ 3. 如何结合污点与 Pod 优先级（PriorityClass）实现分级调度？
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值