让建站和SEO变得简单

让不懂建站的用户快速建站,让会建站的提高建站效率!

极速购彩官网 NEWS
你的位置:极速购彩 > 极速购彩官网 > 何如用三只兔子的故事来粗略透露 Kubernetes 谬误和容忍
何如用三只兔子的故事来粗略透露 Kubernetes 谬误和容忍
发布日期:2022-03-13 19:39    点击次数:191

绪论

本文通过本身透露进行论说,如有不准确的地点,请指正。

在文书一系列联系专科术语之前,先尝试用一个下里巴人的故事来阐明 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:      matchLabs:        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

谬误完了

在使用 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 也曾无路可退了。 



上一篇:没有了

下一篇:为什么会内分泌雄伟