三只兔子的故事理解 Kubernetes 污点和容忍-低调大师

三只兔子的故事理解 Kubernetes 污点和容忍

2022-01-11 544

本文通过自身理解进行述说，如有不准确的地方，请指正。

在讲述一系列相关专业术语之前，先尝试用一个通俗易懂的故事来说明 Kubernetes 中 node 与 pod 之间的爱恨情仇。

雄性（node）| 雌性（pod）

在银河系以外的一个星球上，有着一群两性生物，分别是雌性（pod）和雄性（node）。雌性生物居多，而雄性生物由于优胜劣汰，只剩下 3 只优质的雄性生物（node）。雄雌在一起就容易产生吸引，就会有以下的情况产生：

（1）雄（node）少雌（pod）多，而这三只优质的雄性生物性格、优点都是一致的，雌性生物选谁都一样。于是，雌性生物就分为均等分为三列和三只雄性生物在一起。这种类似于平均分配的原则。

k8s 中的概念：在 k8s 中是最常见最普通的 pod 分布方式，常用与 deployment 和 daemonset 控制器。

（2）时间一长，生物开始了进化。三只雄性（node）生物各自有了不一样的地方，编号 1 的雄性学会了种植（node01 label skill='grow'）；编号 2 的雄性学会了打猎（node02 label skill='hunt'）；编号 3 的雄性啥也没学会（没学会就保持默认）。普通的雌性（pod）仍然保持着平均分配的原则。而一些进化快的雌性（pod）生物发现了三只优质雄性（node）生物各自的不同，各自也开始有了一些选择。一些雌性更加青睐学会种植的雄性生物（nodeSelector skill='grow'）；一些雌性更加青睐学打猎的雄性生物（nodeSelector skill='hunt'）；而有些雌性生物喜欢的特点很奇特，它们喜欢会飞的雄性，而仅存的三只雄性生物都无法满足这一特点。如果有天一只雄性生物进化会飞了，它们就会依附与会飞的雄性生物，如果始终没有进化出会飞的雄性生物，则它们一直等下去这在 k8s 中，就是 yaml 文件中 nodeSelector 的使用。

k8s 中的概念：当 node 打上特定的标签后，会出现如下情况：

pod 中未指定 nodeSelector ，则保持默认 schedule 调度算法的方式；

pod 中指定了 nodeSelector ，且指定 nodeSelector 中的 key、value 符合某一个 node 中的某一个 key、value，则这个 pod 直接调度到该 node；

pod 中指定了 nodeSelector ，指定 nodeSelector 中的 key、value 不包含在任何一个 node 中，则这个 pod 会一直处于 padding 状态。

（3）三只雄性（node）不仅优点增长了，缺点也随之而来。编号 1 的雄性喜欢打脸（node01 taint hobby='face'）；编号 2 的雄性喜欢打屁股（node01 taint hobby='hunkers'）；编号 3 的雄性喜欢踩脚（node01 taint hobby='foot'）；普通的雌性（pod）生物仍然保持平均分配的原则，而一些再次进化的雌性生物也有了自己的性格。能够容忍打脸的雌性则和编号 1 的雄性在一起（tolerations hobby='face'），但是这个容忍可能是永久，也可能是 1 天（tolerationSeconds=86400）。而这三只雄性生物偶尔会在一起鬼混，编号 1 的雄性生物说不定哪天就嗜好就变为了喜欢睡懒觉。而一些无法容忍它睡懒觉嗜好的雌性生物就会隔一段时间或者马上就离开它。

k8s 中的概念：这就是污点与容忍。

污点和容忍还有其他的选项参数，后文展开解说。

nodeSelector

将 pod 分配给指定的节点。

集群如下：

$ kubectl get nodes
NAME         STATUS   ROLES    AGE   VERSION
k8s-master   Ready    master   20h   v1.19.7
k8s-node01   Ready    <none>   20h   v1.19.7
k8s-node02   Ready    <none>   20h   v1.19.7

为 k8s-node01 添加一个标签

$ kubectl label nodes k8s-node01 disktype=ssd
node/k8s-node01 labeled

查看标签

$ kubectl get nodes --show-labels
NAME         STATUS   ROLES    AGE   VERSION   LABELS
k8s-master   Ready    master   20h   v1.19.7   ..., kubernetes.io/hostname=k8s-master
k8s-node01   Ready    <none>   20h   v1.19.7   ..., disktype=ssd,kubernetes.io/hostname=k8s-node01
k8s-node02   Ready    <none>   20h   v1.19.7   ..., kubernetes.io/hostname=k8s-node02

可以看到 k8s-node01 节点标签：disktype=ssd

创建一个调度到选择节点的 Pod

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: ngx
  name: ngx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ngx
  template:
    metadata:
      labels:
        app: ngx
    spec:
      containers:
      - image: nginx:alpine-arm64
        name: nginx
      nodeSelector:
        disktype: ssd    #### 选择服务 key: value 的节点

创建 pod 查看是否调度到指定的节点

$ kubectl apply -f  ngx.yaml
deployment.apps/ngx created
$ kubectl get po -o wide
NAME                   READY   STATUS    RESTARTS   AGE   IP            NODE         NOMINATED NODE   READINESS GATES
ngx-5f4df66559-hjmzg   1/1     Running   0          10s   10.244.1.13   k8s-node01   <none>           <none>
ngx-5f4df66559-wqgdb   1/1     Running   0          10s   10.244.1.14   k8s-node01   <none>           <none>

k8s 亲和性

说道亲和性，亲和性主要分为两类：nodeAffinity 和 podAffinity 。

nodeAffinity

nodeAffinity 就是节点亲和性，调度可以分成软策略和硬策略两种方式，软策略就是如果你没有满足调度要求的节点的话，POD 就会忽略这条规则，继续完成调度过程，说白了就是满足条件最好了，没有的话也无所谓了的策略；而硬策略就比较强硬了，如果没有满足条件的节点的话，就不断重试直到满足条件为止，简单说就是你必须满足我的要求，不然我就不干的策略。nodeAffinity就有两上面两种策略：

requiredDuringSchedulingIgnoredDuringExecution ：硬策略
preferredDuringSchedulingIgnoredDuringExecution ：软策略

硬策略

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: ngx
  name: ngx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ngx
  template:
    metadata:
      labels:
        app: ngx
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: disktype ## key 的值
                operator: In ## 包括
                values:
                - ssd ## value
      containers:
      - image: nginx:alpine-arm64
        name: nginx
      nodeSelector:
        disktype: ssd

上面这两个 pod 只会运行在满足 node label disktype=value 的节点上，如果没有节点满足这个条件，则一直处于 pending 状态。

$ kubectl get po -o wide
NAME                  READY   STATUS    RESTARTS   AGE     IP            NODE         NOMINATED NODE   READINESS GATES
ngx-7b65b44bc-gff9x   1/1     Running   0          3m53s   10.244.1.15   k8s-node01   <none>           <none>
ngx-7b65b44bc-w7bsf   1/1     Running   0          3m53s   10.244.1.16   k8s-node01   <none>           <none>

$ kubectl get nodes k8s-node01 --show-labels
NAME         STATUS   ROLES    AGE   VERSION   LABELS
k8s-node01   Ready    <none>   22h   v1.19.7   ..., disktype=ssd,kubernetes.io/arch=arm64,kubernetes.io/hostname=k8s-node01

软策略

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: ngx
  name: ngx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ngx
  template:
    metadata:
      labels:
        app: ngx
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 10
            preference:
              matchExpressions:
              - key: disktype
                operator: In
                values:
                - hdd

      containers:
      - image: nginx:alpine-arm64
        name: nginx

软策略就是，第一选择是 node label disktype=hdd 的节点，如果没有，就采用默认 scheduler 的调度策略，没有强制性。

$ kubectl get po -o wide
NAME                  READY   STATUS    RESTARTS   AGE     IP            NODE         NOMINATED NODE   READINESS GATES
ngx-d4754b6fd-lr96g   1/1     Running   0          2m55s   10.244.2.13   k8s-node02   <none>           <none>
ngx-d4754b6fd-ns7hs   1/1     Running   0          2m55s   10.244.1.28   k8s-node01   <none>           <none>

operator 提供如下几种操作：

In：label 的值在某个列表中
NotIn：label 的值不在某个列表中
Gt：label 的值大于某个值
Lt：label 的值小于某个值
Exists：某个 label 存在
DoesNotExist：某个 label 不存在

如果nodeSelectorTerms下面有多个选项的话，满足任何一个条件就可以了；如果matchExpressions有多个选项的话，则必须同时满足这些条件才能正常调度 POD。

污点和容忍

在 Kubernetes 中，节点亲和性 NodeAffinity 是 Pod 上定义的一种属性，能够使 Pod 按我们的要求调度到某个节点上，而 Taints(污点) 则恰恰相反，它是 Node 上的一个属性，可以让 Pod 不能调度到带污点的节点上，甚至会对带污点节点上已有的 Pod 进行驱逐。当然，对应的 Kubernetes 可以给 Pod 设置 Tolerations(容忍) 属性来让 Pod 能够容忍节点上设置的污点，这样在调度时就会忽略节点上设置的污点，将 Pod 调度到该节点。一般时候 Taints 通常与 Tolerations 配合使用。

污点（Taints）

查看污点

查看 node 的污点

$ kubectl describe nodes k8s-master
...
Taints:             node-role.kubernetes.io/master:NoSchedule
...


# 也可通过下面操作查看：
$ kubectl get nodes k8s-master -o go-template={{.spec.taints}}
[map[effect:NoSchedule key:node-role.kubernetes.io/master]]

污点内容一般组成为 key、value 及一个 effect 三个元素，表现为：

<key>=<value>:<effect>

这里的 value 可以为空，表现形式为：

node-role.kubernetes.io/master:NoSchedule
- key: node-role.kubernetes.io/master
- value: 空
- effect: NoSchedule

设置污点

一般我们需要想要设置某个节点只允许特定的 Pod 进行调度，这时候就得对节点设置污点，可以按 kubectl taint node [node] key=value[effect] 格式进行设置，其中 effect 可取值如下：

PreferNoSchedule： 尽量不要调度。
NoSchedule： 一定不能被调度。
NoExecute： 不仅不会调度, 还会驱逐 Node 上已有的 Pod。

一般时候我们设置污点，就像下面例子一样对齐进行设置：

### 设置污点并不允许 Pod 调度到该节点
$ kubectl taint node k8s-master key1=value1:NoSchedule

### 设置污点尽量阻止污点调度到该节点
$ kubectl taint node k8s-master key2=value2:PreferNoSchedule

### 设置污点，不允许普通 Pod 调度到该节点，且将该节点上已经存在的 Pod 进行驱逐
$ kubectl taint node k8s-master key3=value3:NoExecute

删除污点

上面说明了如何对 Node 添加污点阻止 Pod 进行调度，下面再说一下如何删除节点上的污点，可以使用下面命令：

kubectl taint node [node] [key]-

上面语法和创建污点类似，不过需要注意的是删除污点需要知道 key 和最后面设置一个 "-" 两项将污点删除，示例如下：

为了方便演示，先给节点设置污点：

### 设置污点1
$ kubectl taint node k8s-master key1=value1:PreferNoSchedule
node/k8s-master tainted

### 设置污点2
$ kubectl taint node k8s-master key2=value2:NoSchedule
node/k8s-master tainted

### 设置污点3，并且不设置 value
$ kubectl taint node k8s-master key2=:PreferNoSchedule
node/k8s-master tainted

查看污点，可以看到上面设置的三个值：

$ kubectl describe nodes k8s-master
...
Taints:             key2=value2:NoSchedule
                    node-role.kubernetes.io/master:NoSchedule
                    key1=value1:PreferNoSchedule
                    key2:PreferNoSchedule
...

然后删除污点

### 删除污点，可以不指定 value，指定 [effect] 值就可删除该 key[effect] 的污点
$ kubectl taint node k8s-master key1:PreferNoSchedule-

### 也可以根据 key 直接将该 key2 的所有 [effect] 都删除：
$ kubectl taint node k8s-master key2-

再次查看污点，可以看到以上污点都被删除：

$ kubectl describe nodes k8s-master
...
Taints:             node-role.kubernetes.io/master:NoSchedule
...

容忍 (toleratints)

Pod 设置容忍

为了使某些 Pod 禁止调度到某些特定节点上，就可以对节点设置污点 taints。当然，如果希望有些 Pod 能够忽略节点的污点，继续能够调度到该节点，就可以对 Pod 设置容忍，让 Pod 能够容忍节点上设置的污点，例如：

对一个节点设置污点：

kubectl taint node k8s-node01 key=value:NoSchedule

对于 Pod 设置容忍，以下两种方式都可以：

### 容忍的 key、value 和对应 effect 也必须和污点 taints 保持一致
......
tolerations:
- key: "key"
  operator: "Equal"
  value: "value"
  effect: "NoSchedule"

### 容忍 tolerations 的 key 和要污点 taints 的 key 一致，且设置的 effect 也相同，不需要设置 value
......
tolerations:
- key: "key"
  operator: "Exists"
  effect: "NoSchedule"

Node 和 Pod 对于污点与容忍基本概念

概念

一个 node 可以有多个污点；
一个 pod 可以有多个容忍；
kubernetes 执行多个污点和容忍方法类似于过滤器

如果一个 node 有多个污点，且 pod 上也有多个容忍，只要 pod 中容忍能包含 node 上设置的全部污点，就可以将 pod 调度到该 node 上。如果 pod 上设置的容忍不能够包含 node 上设置的全部污点，且 node 上剩下不能被包含的污点 effect 为 PreferNoSchedule，那么也可能会被调度到该节点。

注意

当 pod 总存在容忍，首先 pod 会选择没有污点的节点，然后再次选择容忍污点的节点。

如果 node 上带有污点 effect 为 NoSchedule，而 pod 上不带响应的容忍，kubernetes 就不会调度 pod 到这台 node 上。
如果 Node 上带有污点 effect 为 PreferNoShedule，这时候 Kubernetes 会努力不要调度这个 Pod 到这个 Node 上。
如果 Node 上带有污点 effect 为 NoExecute，这个已经在 Node 上运行的 Pod 会从 Node 上驱逐掉。没有运行在 Node 的 Pod 不能被调度到这个 Node 上。一般使用与当某个节点处于 NotReady 状态下，pod 迅速在其他正常节点启动。

Deployment 中设置容忍

在 kubernetes 中 deployment 设置容忍，示例如下：

apiVersion: apps/vl
kind: Deployment
metadata:
  name: example
spec:
  replicas: 5
  template:
    spec:
      ......
      tolerations:
      - key: "key"
        operator: "Equal"
        value: "value"
        effect: "NoSchedule"

设置容忍时间

正常情况下，如果一个污点带有 effect=NoExecute 被添加到了这个 Node。那么不能容忍这个污点的所有 Pod 就会立即被踢掉。而带有容忍标签的 Pod 就不会踢掉。然而，一个带有 effect=Noexecute 的容忍可以指定一个 tolerationSeconds 来指定当这个污点被添加的时候在多长时间内不被踢掉。例如：

tolerations:
- key: "key"
  operator: "Equal"
  value: "value"
  effect: "Noexecute"
  tolerationSeconds: 3600

如果这个 Pod 已经在这个带污点且 effect 为 NoExecute 的 node 上。这个 pod 可以一直运行到 3600s 后再被踢掉。如果这时候 Node 的污点被移除了，这个 Pod 就不会被踢掉。

容忍示例

Operator 默认是 Equal，可设置为 Equal 与 Exists 两种，按这两种进行示例：

Operator 是 Exists

容忍任何污点

例如一个空的 key，将匹配所有的 key、value、effect。即容忍任何污点。

tolerations:
- operator: "Exists"

容忍某 key 值的污点

例如一个空的 effect，并且 key 不为空，那么将匹配所有与 key 相同的 effect：

tolerations:
- key: "key"
  operator: "Exists"

Operator 是 Equal

node 上有一个污点

Node 和 Pod 的 key 为 key1、value1 与 effect 相同则能调度：

#污点
key1=value1:NoSchedule

#Pod设置
tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"

node 上有多个污点

Node 的污点的 key、value、effect 和 Pod 容忍都相同则能调度：

## 设置污点
key1=value1:NoSchedule
key2=value2:NoExecute

## Pod设置容忍
tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
- key: "key2"
  operator: "Equal"
  value: "value2"
  effect: "NoExecute"

Node 的污点和 Pod 的大部分都相同，不同的是 Node 污点 effect 为 PreferNoSchedule 的，可能会调度：

## 污点
key1=value1:NoSchedule
key2=value2:NoExecute
key3=value3:PreferNoSchedule

## Pod设置容忍
tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
- key: "key2"
  operator: "Equal"
  value: "value2"
  effect: "NoExecute"

Node 的污点和 Pod 的大部分都相同，不同的是 Node 污点 effect 为 NoSchedule 和 NoExecute 的，不会被调度：

## 污点
key1=value1:NoSchedule
key2=value2:NoExecute
key3=value3:PreferNoSchedule

## Pod设置容忍
tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
- key: "key3"
  operator: "Equal"
  value: "value3"
  effect: "PreferNoSchedule"

对比理解 Exists 和 Equal 之间的区别：

Exists 是包含，Equal 是等于，Exists 使用范围更广，而 Equal 则是精准匹配。
当污点中存在 NoExecute 时，而容忍中不存在 NoExecute 时，不会被调度到该节点。
Exists 可以不写 value ，而 Equal 则一定要指定对应的 value
搭建一套完整的企业级 K8s 集群（v1.22，二进制方式）

污点驱逐

在使用 kubernetes 时，会遇到某个 node 节点明明已经宕机了，查看 node 状态从 Ready 状态变为 NotReady 状态，但是节点所在的 pod 却已经处于 running 状态，过了很长一段时间才会转为 Terminating 状态，这是为什么呢？

污点是对于 node 节点来讲，如果 node 节点 effect 设置为 NoExecute ，它会影响节点上已经运行的 Pod，如下所示：

立即将没有匹配容忍的 pod 驱逐。
设置容忍但是没有指定 tolerationSeconds 参数的，那么该容忍永久生效，不会被驱逐。
设置容忍但是有指定 tolerationSeconds 参数的，那么在指定的时间内容忍有效，超过指定时间后将被剔除。（pod 默认设置，tolerationSeconds = 300s）

此外，当某些条件为 true 时，节点控制器会自动污染节点。内置以下污点：

key	注释
node.kubernetes.io/not-ready	节点尚未准备好。这对应于 NodeCondition Ready 为 false。
node.kubernetes.io/unreachable	无法从节点控制器访问节点。这对应于 NodeCondition Ready 为 Unknown。
node.kubernetes.io/out-of-disk	节点磁盘不足。
node.kubernetes.io/memory-pressure	节点有内存压力。
node.kubernetes.io/disk-pressure	节点有磁盘压力。
node.kubernetes.io/network-unavailable	节点的网络不可用。
node.kubernetes.io/unschedulable	节点不可调度。
node.cloudprovider.kubernetes.io/uninitialized	当 kubelet 从 "外部" 云提供程序开始时，此污点在节点上设置为将其标记为不可用。来自 cloud-controller-manager 的控制器初始化此节点后，kubelet 删除此污点。

通过上面知识的铺垫，当一个节点宕机时，kubernetes 集群会给它打上什么样的污点呢？

一个 Ready 状态的节点

$ kubectl get node k8s-node02 -o go-template={{.spec.taints}}
<no value>

一个 NotReady 状态的节点

$ kubectl get node k8s-node02 -o go-template={{.spec.taints}}
[map[effect:NoSchedule key:node.kubernetes.io/unreachable timeAdded:2021-12-23T13:49:58Z] map[effect:NoExecute key:node.kubernetes.io/unreachable timeAdded:2021-12-23T13:50:03Z]]

处于 NotReady 状态的节点被打上了下面两个污点：

Taints:             node.kubernetes.io/unreachable:NoExecute
                    node.kubernetes.io/unreachable:NoSchedule

接下来测试 kubernetes 集群会给 Pod 分配什么样的容忍。

$ kubectl get po nginx-745b4df97d-mgdmp -o yaml
...
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300  ## 300/60=5min
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300 ## 300/60=5min
...

看到这里，Pod 的失效机制已经很明白了，当 node 节点处于 NotReady 状态或者 unreachable 状态时，Pod 会容忍它 5 分钟，然后被驱逐。而这 5 分钟内就算 Pod 处于 running 状态，也是无法正常提供服务的。因此，可以在 yaml 清单中手动指明 0 容忍，清单文件如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      tolerations:
      - effect: NoExecute
        key: node.kubernetes.io/not-ready
        operator: Exists
        tolerationSeconds: 0
      - effect: NoExecute
        key: node.kubernetes.io/unreachable
        operator: Exists
        tolerationSeconds: 0
      containers:
      - image: nginx:alpine
        name: nginx

生成 Pod

$ kubectl get po -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP            NODE         NOMINATED NODE   READINESS GATES
nginx-84f6f75c6-c76fm   1/1     Running   0          6s    10.244.3.16   k8s-node02   <none>           <none>
nginx-84f6f75c6-hsxq5   1/1     Running   0          6s    10.244.3.15   k8s-node02   <none>           <none>
nginx-84f6f75c6-wkt52   1/1     Running   0          6s    10.244.1.63   k8s-node01   <none>           <none>
nginx-84f6f75c6-xmkjs   1/1     Running   0          6s    10.244.3.17   k8s-node02   <none>           <none>

接下来强制关闭 k8s-node02 节点，查看 Pod 是否转移。

$ kubectl get po -o wide
NAME                    READY   STATUS        RESTARTS   AGE    IP            NODE         NOMINATED NODE   READINESS GATES
nginx-84f6f75c6-c76fm   1/1     Terminating   0          116s   10.244.3.16   k8s-node02   <none>           <none>
nginx-84f6f75c6-csqf4   1/1     Running       0          13s    10.244.1.66   k8s-node01   <none>           <none>
nginx-84f6f75c6-hsxq5   1/1     Terminating   0          116s   10.244.3.15   k8s-node02   <none>           <none>
nginx-84f6f75c6-r2v4p   1/1     Running       0          13s    10.244.1.64   k8s-node01   <none>           <none>
nginx-84f6f75c6-v4knq   1/1     Running       0          13s    10.244.1.65   k8s-node01   <none>           <none>
nginx-84f6f75c6-wkt52   1/1     Running       0          116s   10.244.1.63   k8s-node01   <none>           <none>
nginx-84f6f75c6-xmkjs   1/1     Terminating   0          116s   10.244.3.17   k8s-node02   <none>           <none>

在 node 节点转为 NotReady 状态后，Pod 立刻进行了转移。这是通过在 yaml 清单文件中明确指定容忍时间。还可以直接修改 apiserver 配置来修改默认容忍时间。

vim /etc/kubernetes/manifests/kube-apiserver.yaml
...
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=192.168.1.11
    - --default-not-ready-toleration-seconds=1    ## 新增行
    - --default-unreachable-toleration-seconds=1  ## 新增行
...

修改保存后， kube-apiserver-k8s-masterpod 会自动重载最新配置。

$ kubectl get po nginx-84f6f75c6-wkt52 -o yaml
...
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 0
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 0
...

对于小型集群，可以直接设置全局变量。

注意：当 kubernetes 集群只有一个 node 节点时，无法做到 Pod 转移，因为 Pod 已经无路可退了。

微信关注我们

原文链接：https://my.oschina.net/u/4518151/blog/5395463

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

关于DevOps CI/CD Pipeline，看这篇就够了

来源：CIO Talk 作者：马景贺提到DevOps，很多人就想到了CI/CD Pipeline，甚至很多个人或者企业认为完成了CI/CD Pipeline就等于实现了DevOps，虽然这种观点有失偏颇，但是从侧面反映了CI/CD Pipeline在DevOps中扮演着举足轻重的地位。CI/CD 是DevOps 的两大关键核心能力。CI/CD Pipeline的真正实现会加速企业向DevOps转型的进程。本文将揭开CI/CD Pipeline的神秘面纱，来一探究竟。一、什么是 CI/CD Pipeline Pipeline 指管道或者流水线，类似于工厂里的生产线，原料从一端输入，中间经过多个工作中心，一个工作中心的输出作为下一个工作中心的输入，最终在另一端输出高质量的产品。CI/CD Pipeline 指CI/CD的流水线，在输入端输入源码，经过既定工作流，最后在输出端输出对用户有价值的产品。从字面就能看出侧重点持续、流水线。 CI/CD Pipeline的简单示意图如下。开发人员提交完代码，经过一系列的流程，最后生产出有价值的应用程序。二、为什么需要 CI/CD Pipeli...

2022-01-11

710

熟悉 Python 开发的同学都知道，Python 有默认参数的存在，使得我们在实例化一个对象的时候，可以根据需要来选择性的覆盖某些默认参数，以此来决定如何实例化对象。当一个对象有多个默认参数时，这个特性非常好用，能够优雅地简化代码。而 Go 语言从语法上是不支持默认参数的，所以为了实现既能通过默认参数创建对象，又能通过传递自定义参数创建对象，我们就需要通过一些编程技巧来实现。对于这些程序开发中的常见问题，软件行业的先行者们总结了许多解决常见场景编码问题的最佳实践，这些最佳实践后来成为了我们所说的设计模式。其中选项模式在 Go 语言开发中会经常用到。通常我们有以下三种方法来实现通过默认参数创建对象，以及通过传递自定义参数创建对象：使用多个构造函数默认参数选项选项模式通过多构造函数实现第一种方式是通过多构造函数实现，下面是一个简单例子： package main import "fmt" const ( defaultAddr = "127.0.0.1" defaultPort = 8000 ) type Server struct { Addr string Port i...

2022-01-11

528

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。