背景

继上一篇《Kubernetes的污点和容忍(上篇)》,这是https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/ 译文的下半部分。

经常看外文文档或书籍多了,会产生一个问题:“不方便沟通。”不太会用大家习惯的表述方式来阐述一个问题。所以需要定期看一些中文书籍来学习「行话」。

译文

使用场景

污点和容忍是一种让Pod不被调度到指定node或者是把不该在某个node上运行的Pod踢掉的灵活方法。下面列举一些使用场景。

  • 指定node:如果想为特殊的用户指定一组node,可以添加一个污点到这组node上(运行命令: kubectl taint nodes nodename dedicated=groupName:NoSchedule)。然后添加对应的容忍到这个Pod上(这个最容易实现的方法是写一个客户端准入控制器)。带有相应容忍的Pod就可以像被调度到集群中其他node一样被调度到带有相应污点的node上。

  • 特殊硬件的node:在一个有一小组特殊硬件(例如GPU)的集群中,更希望将没有特殊硬件需求的Pod不调度到这些node上,留出空间给后来的需要这些特殊硬件的Pod。这个通过给特殊硬件打上污点(例如:kubectl taint nodes nodename special=true:NoSchedule or kubectl taint nodes nodename special=true:PreferNoSchedule),然后添加相应的容忍到Pod上来实现。在这些使用场景,最容易实现的方法是使用客户端准入控制器来实现。例如,推荐使用Extended Resources 来代表特殊硬件,将带有扩展资源名的硬件打上污点。然后运行ExtendedResourceToleration准入控制器. 现在,由于这些node已经被打上污点了,没有容忍的Pod不会被调度到上面。但是当你提交了一个需要扩展资源的Pod,ExtendedResourceToleration准入控制器会自动的添加正确的容忍到Pod上,Pod就可以被调度到这个特殊硬件的node上了。这会确保这些特殊硬件的node是需要相应的硬件的,并且不需要手动给Pod添加容忍。

  • 基于污点的驱逐(beta版本特性):下面我们会介绍当node发生故障时基于单个Pod配置的驱逐行为。

基于驱逐的污点

早期我们提到了NoExecute污点的effect会影响已经在node上运行的Pod。

  • 不能容忍污点的Pod会被立即驱逐。

  • Pod上的容忍没有指定tolerationSeconds会好好的呆在node上。

  • Pod上的容忍带有tolerationSeconds的会在node上停留指定的时间。

另外,Kubernets 1.6 引入了代表node问题的污点(在1.6版本是alpha版试用)。换句话说,node控制器当某种条件成立的时候会自动的给node打上污点。下面是其中内置的污点:

  • node.kubernetes.io/not-ready:node不是ready状态。对应于node的condition ready=false.

  • node.kubernetes.io/unreachable:node controller与node失联了。对应于node的condition ready=unknown

  • node.kubernetes.io/out-of-disk:node磁盘空间不足了。

  • node.kubernetes.io/network-unavailable:node的网断了

  • node.kubernets.io/unschedulable:node不是可调度状态

  • node.cloudprovider.kubernetes.io/uninitalized:kubelet是由外部云提供商提供的时候,刚开始的时候会打上这个污点来标记还未被使用。当cloud-controller-manager控制器初始化完这个node,kubelet会自动移除这个污点。

在1.13版本中,「基于污点的驱逐」特性被提升至beta版,并且被默认开启。因为这些污点会被自动添加到node控制器(或kubelet)中。而之前的常使用的逻辑:基于condition中ready状态来驱逐pod也被禁用了。

注意:

为了维持在node故障时对存在的Pod驱逐做限流,系统实际上是用限速的方法来添加污点的。这种措施防止了master与node脑裂而产生的大规模驱逐Pod的场景。

这个beta版本特性再结合tolerationSeconds,可以使得pod指定当node节点出现问题的时候一个pod能在node上呆多久。

举个栗子:

一个有很多本地状态的应用可能想在产生网络脑裂的时候还能在node上呆很久。这样是希望脑裂会恢复,从而避免pod被驱逐。为了达到这个目的,可以这样用:

Kubernetes会自动给pod添加容忍:node.kubernetes.io/not-ready 实效是tolerationSeconds=300。但是如果用户自己给这个pod添加了node.kubernets.io/not-ready的容忍,用户的配置不会被覆盖。

类似的,它也会自动给pod添加容忍:node.kubernetes.io/unreachable 实效是tolerationSeconds=300。但是如果用户自己给这个pod添加了node.kubernetes.io/unreahable,用户的配置不会被覆盖。

这种自动添加容忍机制确保了默认pod如果宿主机发生故障在5分钟之内不会被自动驱逐。这两个默认的容忍都是https://github.com/kubernetes/kubernetes/tree/master/plugin/pkg/admission/defaulttolerationseconds (DefaultTolerationSeconds admission controller)这个控件来添加的。

DaemonSet的pod会默认添加一个NoExecute不带有tolerationSeconds的容忍:

  • node.kubernetes.io/unreachable

  • node.kubernetes.io/not-ready

这种方式确保了DaemonSet的Pod在发生故障的时候永远不会被驱逐。

condition驱动的污点

在版本1.12中,「condition驱动的污点」特性被提升到beta版,node的生命周期控制器自动的创建condition相应的污点。类似的,调度器并不检查node的condition,而是检查污点。这种方式是用来保证node的condition不会影响已经调度到这台node的Pod。用户可以用添加合适的容忍来忽视node的一些问题(condition是其中的代表)。在这个版本中「condition驱动的污点」只是打上了effect=NoSchedule的污点。而在1.13版本中才将effect=NoExcute作为beta版默认开启。

从Kubernetes1.8版本开始,DaemonSet控制器自动的添加了NoSchedule容忍到所有的daemon线程来避免DaemonSets中断。

  • node.kubernetes.io/memory-pressure

  • node.kubernetes.io/disk-pressure

  • node.kubernetes.io/out-of-disk(只对重要的pod生效)

  • node.kubernetes.io/unschedulable(1.10版本后生效)

  • node.kubernetes.io/network-unavailable(只针对主机网络)

添加这些容忍确保了向后兼容,用户可以随意对DaemonSets添加容忍。

相关阅读

《两地书》--K8s基础知识

Kubernetes的污点和容忍(上篇)

Kubernetes的污点和容忍(下篇)

作者是一个有美国硅谷、日本东京工作经验,十二年坚持一线写代码的程序媛。坚持原创文章。欢迎技术交流!

Kubernetes的污点和容忍(下篇)的更多相关文章

  1. Kubernetes的污点和容忍(上篇)

    背景 搭建了一个k8s(Kubernetes)的事件监听服务,监听事件之后对数据做处理.有天报了一个问题经调查是新版本的k8s集群添加会把unschedule等信息通过污点的方式反映.而这些污点是只有 ...

  2. Kubernetes 调度 - 污点和容忍度详解

    当我们使用节点亲和力(Pod 的一个属性)时,它会将Pod吸引到一组节点(作为偏好或硬性要求).污点的行为完全相反,它们允许一个节点排斥一组 Pod. 在 Kubernetes 中,您可以标记(污染) ...

  3. Kubernetes之Taints与Tolerations 污点和容忍

    NodeAffinity节点亲和性,是Pod上定义的一种属性,使Pod能够按我们的要求调度到某个Node上,而Taints则恰恰相反,它可以让Node拒绝运行Pod,甚至驱逐Pod. Taints(污 ...

  4. kubernetes(k8s)Pod污点与容忍

    污点(taints)与容忍(tolerations) 对于nodeAffinity无论是硬策略还是软策略方式,都是调度 pod 到预期节点上,而Taints恰好与之相反,如果一个节点标记为 Taint ...

  5. 七、kubernetes污点和容忍

    Kubernetes污点和容忍 一.Taint 和 Toleration介绍 节点亲和性,是 pod 的一种属性(偏好或硬性要求),它使 pod 被吸引到一类特定的节点.Taint 则相反,它使节点能 ...

  6. 009.kubernets的调度系统之污点和容忍

    Taints和Tolerations(污点和容忍) Taint需要与Toleration配合使用,让pod避开那些不合适的node.在node上设置一个或多个Taint后,除非pod明确声明能够容忍这 ...

  7. k8s-Pod污点与容忍

    目录 Pod污点与容忍 大白话先解释一下污点与容忍 为什么要用污点和容忍? 官方解释 Taints参数 标记污点 容忍污点 取消所有节点污点 Pod污点与容忍 大白话先解释一下污点与容忍 污点:被打上 ...

  8. Kubernetes 配置 Taint 和 Toleration(污点和容忍)

    通过污点和容忍让pod运行在特定节点上 参考官网:https://k8smeetup.github.io/docs/concepts/configuration/taint-and-toleratio ...

  9. Kubernetes-14:一文详解Pod、Node调度规则(亲和性、污点、容忍、固定节点)

    Kubernetes Pod调度说明 简介 Scheduler 是 Kubernetes 的调度器,主要任务是把定义的Pod分配到集群的节点上,听起来非常简单,但要考虑需要方面的问题: 公平:如何保证 ...

随机推荐

  1. distinct的用法

    1.  Distinct 位置 单独的distinct只能放在开头,否则报错,语法错误 例:SELECT Sid,DISTINCT(Sscore) score from t_student; [SQL ...

  2. BZOJ_1925_[Sdoi2010]地精部落_递推

    BZOJ_1925_[Sdoi2010]地精部落_递推 Description 传说很久以前,大地上居住着一种神秘的生物:地精. 地精喜欢住在连绵不绝的山脉中.具体地说,一座长度为 N 的山脉 H可分 ...

  3. BZOJ4554: [Tjoi2016&Heoi2016]游戏 luoguP2825 loj2057

    题面描述:尽可能多的放置符合要求的炸弹. 分析: 在i,j处放置炸弹,则在第i行,上一个硬石头之后,下一个硬石头之前,第j列,上一个硬石头之后,下一个硬石头之前,不能再次放置炸弹. 首先,这个题,一看 ...

  4. Security - 轻量级Java身份认证、访问控制安全框架

    前言 此框架由小菜独立开发,并且已经在生产环境中运行大约一年时间. 也就是说,Security 框架写出来有一段时间了,但是一直没有公布.开源,经过不断迭代完善,终于算是拿得出手啦~ Security ...

  5. jenkins+ant+jmeter测试环境部署

    1.安装java 2.安装jenkins 3.下载apache-jmeter-4.0,解压后放在 /home/用户名/ 下 4.下载apache-ant-1.10.3,解压后放在 /home/用户名/ ...

  6. i春秋——Misc之百度杯

    今天心里很是不开森,想想往日何必那么努力呢?不如你的比比皆是,可是人家就是因为有关系,你又能怎样呢? 你所有应该有的都被打翻了,别灰心,至少你曾经努力过! 愿我未来的学弟学妹们都能一直开开心心的过好每 ...

  7. Hadoop配置第1节-集群网络配置

    Hadoop-集群网络配置 总体目标:完成zookeeper+Hadoop+Hbase 整合平台搭建   进度:1:集群网络属性配置2:集群免密码登陆配置3:JDK的安装4:Zookeeper的安装5 ...

  8. 钉钉开发获取APPKEY, APPSECRET, CorpId和SSOSecret

    首先用自己的钉钉账号注册一个企业: https://oa.dingtalk.com/index.htm 一.获取应用APPKEY及APPSECRET方法: 1.登录钉钉开放平台创建应用: https: ...

  9. python接口自动化(二十一)--unittest简介(详解)

    简介 前边的随笔主要介绍的requests模块的有关知识个内容,接下来看一下python的单元测试框架unittest.熟悉 或者了解java 的小伙伴应该都清楚常见的单元测试框架 Junit 和 T ...

  10. 干货|一个案例学会Spring Security 中使用 JWT

    在前后端分离的项目中,登录策略也有不少,不过 JWT 算是目前比较流行的一种解决方案了,本文就和大家来分享一下如何将 Spring Security 和 JWT 结合在一起使用,进而实现前后端分离时的 ...