背景
搭建了一个k8s(Kubernetes)的事件监听服务，监听事件之后对数据做处理。有天报了一个问题经调查是新版本的k8s集群添加会把unschedule等信息通过污点的方式反映。而这些污点是只有key没有value的。我的服务中只对value不会空的进行了处理就不对了。
发现这个问题，我跟leader解释了一下。解释的时候我就把k8s官方文档https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/ 拿出来。但是我当时只能给leader指一下是哪一行。现场翻译不能优雅的表达出来。
静儿是翻译出身的，很惭愧啊。所以今天把这篇文章笔译一下，也顺便加深一下理解。为避免篇幅过长，分成两篇。上篇是概念，下篇是使用场景。
译文
node(宿主机)的affinity，是pod（容器）用来关联到一组node的属性(不管是作为preference还是强需求)。污点是相反的，他们允许一个node排斥一组pod。
污点和容忍一起协作来确保pod不被调度到不合适的node上。一个或者多个污点如果被应用于一个node，这个标志着这个node不应该接收任何不容忍这个污点的pod。
容忍被应用于pod，允许这个pod被调度到相对应的污点上。
概念
添加一个污点到一个node上，使用kubectl taint。例如：
在一个node上打上污点node1。污点有key「key」，value「value」，污点effect「NoSchedule」。这意味着除非有相应的容忍，没有pod能够调度到node1上。想删除这个污点，可以执行下面的命令
在PodSpec可以指定一个容忍到一个pod上。下面的两个容忍都能匹配上面node上的污点，因此带有下面任意一个容忍的pod都能调度到node1上。
一个匹配污点容忍的条件是：key相同、effect相同，并且满足 operator 是Exists（这时候不应该指定value）或者operator是Equal并且value相同。
注意：有两种特殊的场景
1.一个空的key，operator是Exists 匹配所有的key、value、effect。就是说容忍任何污点
2. 一个空的effect 匹配所有的key为「key」的effect
上面的例子使用了effect=NoSchedule。也可以使用effect=PreferNoSchedule。这是一个preference或者soft版本的NoSchedule。系统会尽量避免将没有容忍的pod调度到这台node上，但是不是必须的。还有第三种effect叫NoExcute，一会儿讲。
一个node可以有多个污点，一个pod可以有多个node。k8s执行多个污点和容忍方法类似于过滤器：从node的所有污点开始，忽略pod所带的相应容忍，剩余不能被忽略的污点显式的作用到pod上。
注意：
-
如果至少有一个不能被忽略的污点带有effect=NoSchedule，k8s就不会调度pod到这台node上。
-
如果没有不能被忽略的污点带有effect=NoSchedule，但是至少有一个不能被忽略的污点带有effect=PreferNoShedule，这时候k8s会努力不要调度这个pod到这个node上。
-
如果至少有一个不能被忽略的污点effect=NoExecute，这个已经在node上运行的pod会被从node上驱逐掉。没有运行在node的pod不能被调度到这个node上。
举个例子：如果一个node被打了下面的污点
一个pod有两个容忍。
在这种场景下，pod就不能被调度到这个node上。因为没有容忍能够匹配第三个污点。但是添加这个污点的时候，如果pod已经在这个node上运行了，这个pod不会被踢掉，仍然可以继续运行。因为第三个污点是这个pod唯一没有容忍的污点。
正常情况下，如果一个污点带有effect=NoExecute被添加到了这个node。那么不能容忍这个污点的所有pod就会立即被踢掉。而带有容忍标签的pod就不会踢掉。然而，一个带有effect=Noexecute的容忍可以指定一个tolerationSeconds来指定当这个污点被添加的时候在多长时间内不被踢掉。例如：
意思是如果这个pod已经在有一个对应的污点上跑了。这个pod可以一直跑3600s后再被踢掉。如果这时候node的污点被移除了，这个pod就不会被踢掉。
总结
感悟
最近静儿发布代码的质量越来越高。在工作中也有了更大的灵活性。发现一个特别舒服的现象：我们leader从来路过我的工位不看我在干什么。这是基于一种信任：能进美团基础架构部的，都是有技术追求和职业素养的。另外也是基于一种理念和文化：活儿干好了管你在干什么呢。
技术人员没有上班时间和下班时间，有空就多为工作思考。
相关阅读
作者是一个有美国硅谷、日本东京工作经验，十二年坚持一线写代码的程序媛。坚持原创文章。欢迎技术交流！
