当前位置：首页 > article >正文

K8s pod 调度策略

article 2024/11/2 12:47:39

K8s pod 调度策略

一.通过node标签调度

1.给node节点打上标签

 # 添加标签
 kubectl label nodes node01 zone=sh
 # 删除标签
 kubectl label nodes node01 zone=sh-
 #查看标签
 kubectl label nodes --show-labels

2.通过nodeSelectro 调度pod

nodeSelectro为硬限制，必须要满足的条件有：指定标签和值。

apiVersion: v1
kind :Pod
metadata：
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:  # 硬限制
    disktype： ssd  # 只会把pod调度到node标签为disktype=ssd的节点上

二.Node 间亲和性（Affinity）调度

Affinity [əˈfɪnəti]/anti-affinity node 相对于nodeSelector机制更加的灵活和丰富
- 表达的语法：支持In,NotIn,Exists,DoesNotExist,Gt,Lt．匹配标签的方式
- 支持soft(preference)和hard(requirement),
  - hard表示pod sheduler到某个node上时必须满足的亲和性设置．
  - soft表示scheduler的时候，当无法满足节点的时候，会选择非 nodeSelector 匹配的节点．
  - requiredDuringSchedulingIgnoredDuringExecution 硬亲和性必须满足亲和性
  - preferredDuringSchedulingIgnoredDuringExecution 软亲和性能满足最好，不满足也没关系。
- nodeAffinity 的基础上添加多个 nodeSelectorTerms 字段，调度的时候 Node 只需要 nodeSelectorTerms 中的某一个符合条件就符合 nodeAffinity 的规则．在nodeSelectorTerms 中添加 matchExpressions，需要可以调度的Node是满足 matchExpressions 中表示的所有规则．
需要注意的是preferredDuringSchedulingIgnoredDuringExecution和requiredDuringSchedulingIgnoredDuringExecution名字中后半段字符串IgnoredDuringExecution表示的是，在Pod资源基于节点亲和性规则调度到某个节点之后，如果节点的标签发生了改变，调度器不会将Pod对象从该节点上移除，因为该规则仅对新建的Pod对象有效。

1.硬亲和性

硬亲和性是强制性的规则，Pod调度时必须满足的规则。
如果存在满足硬亲和性规则的节点，Pod将被调度至该节点；否则，Pod将无法正常调度，处于Pending状态。

apiVersion: v1
kind： Pod
metadata：
  name：pod-node
    labels:
    app: myapp
    tier: frontend
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
  affinity:   # 亲和性
    nodeAffinity: # 节点亲和性设置
      requiredDuringSchedulingIgnoredDuringExecution:   # 硬亲和条件
        nodeSelectorTerms:      # 使用node硬限制条件标签        
        - matchExpressions:     # 一个或多个匹配规则 用于筛选节点。
          - key: zone           # 匹配的lable键
            operator: In        # 匹配逻辑
            values:             # 匹配标签的值
            - foo
            - bar

# 在启动这个pod时需要给node加上指定的标签
[root@master01 ~]# kubectl label node node01 zone=foo

2.软亲和性

软亲和性允许Pod对象定义针对一组可以调度于其上的节点的偏好，调度器会尽量满足此需求，但在无法满足调度需求时，它会退而求其次地选择一个不匹配规则的节点。
优化Pod的调度，以便将Pod调度到满足特定条件的节点上，从而实现更高效的资源利用、提高容错性和性能等方面的需求。

apiVersion: v1
kind: Pod
metadata:
  name: pod-node2
  labels:
    app: myapp
    tier: frontend
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
  affinity: # 亲和性
    nodeAffinity:  # 节点亲和性设置
      preferredDuringSchedulingIgnoredDuringExecution: # 软亲和条件
      - preference: # 每个偏好项
          matchExpressions: # 一个或多个匹配规则 用于筛选节点
          - key: zone  
            operator: In  
            values:
            - foo
            - bar
        weight: 60  # 权重值 范围1-100 数字越高优先级越高
      - preference:
          matchExpressions:
          - key: zone1
            operator: In
            values:
            - foo1
            - bar1
        weight: 10

3.软硬亲和性同时存在

当软硬亲和性同时存在时，硬亲和性具有更高的优先级。调度器会首先检查硬亲和性规则，如果找到满足条件的节点，则将该Pod调度到该节点上。
如果找不到满足硬亲和性规则的节点，Pod将处于Pending状态，直到找到满足条件的节点或超时。

apiVersion: v1
kind: Pod
metadata:
  name: with-node
spec:
  containers:
  - name: with-node-affinity
    image: nginx
  affinity: 
    nodeAffinity:  
      requiredDuringSchedulingIgnoredDuringExecution: 
        nodeSelectorTerms: 
        - matchExpressions:
          - key: zone
            operator: In
            values:
            - dev
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd

三.Pod 间的亲和性和反亲和性（Affinity/AntiAffinity）调度

基于已经运行在 Node 上 pod 的 labels 来决定需要新创建的Pods是否可以调度到node节点上，配置的时候可以指定那个namespace中的pod需要满足pod的亲和性．可以通过 topologyKey 来指定 topology domain, 可以指定为 node／cloud provider zone 的范围．

表达的语法：支持In, NotIn, Exists, DoesNotExist
Pod的亲和性和反亲和性可以分成
- requiredDuringSchedulingIgnoredDuringExecution　 # 硬要求
- preferredDuringSchedulingIgnoredDuringExecution　＃软要求
labelSelector : 选择跟那组Pod亲和
namespaces : 选择哪个命名空间
topologyKey : 指定节点上的哪个键，可以设置成如下几种类型(节点标签) 1、标签是不是存在（硬性），2、节点key的值相同的情况下只启动一个，应用场景，高可用上海，北京，广州 zone=beijing 多个node1-10 zone=shanghai 多个node11-20 zone=guangzhou 多个node21-30 rediis 3个节点夸区高可用部署
- kubernetes.io/hostname　　＃Node
- failure-domain.beta.kubernetes.io/zone　＃Zone
- 可以设置node上的label的值来表示node的name,zone,region等信息，pod的规则中指定topologykey的值表示指定topology 范围内的 node 上运行的 pod 满足指定规则

1.pod亲和性

Pod反亲和性场景，当应用服务A和数据库服务B要求尽量不要在同一台节点上的时候。

apiVersion: v1
kind: Pod
metadata:
  name: pod-first
  labels:
    app: myapp
    tier: frontend
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-second
  labels:
    app: db
    tier: db
spec:
  containers:
  - name: busybox
    image: busybox
    imagePullPolicy: IfNotPresent
    command: ["sh","-c","sleep 3600"]
  affinity:
    podAffinity:  # 亲和性调度策略
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - {key: app, operator: In, values: ["myapp","app"]}
        topologyKey: kubernetes.io/hostname
        
# 运行会发现这两个pod在同一个节点上。
NAME         READY   STATUS    RESTARTS   AGE   IP              NODE     NOMINATED NODE   READINESS GATES
pod-first    1/1     Running   0          11s   10.233.113.44   node02   <none>           <none>
pod-second   1/1     Running   0          6s    10.233.113.45   node02   <none>           <none>

2.pod反亲和性

Pod反亲和性场景，当应用服务A和数据库服务B要求尽量不要在同一台节点上的时候。

apiVersion: v1  
kind: Pod  
metadata:  
  name: pod-first-web  
  labels:  
    app: web  
spec:  
  containers:  
  - name: myapp  
    image: ikubernetes/myapp:v1  
  
---  
apiVersion: v1  
kind: Pod  
metadata:  
  name: pod-second  
  labels:  
    app: backend  
    tier: db  
spec:  
  containers:  
  - name: busybox  
    image: busybox:latest  
    imagePullPolicy: IfNotPresent  
    command: ["sh","-c","sleep 3600"]  
  affinity:  
    podAntiAffinity:  # 反亲和性调度策略
      requiredDuringSchedulingIgnoredDuringExecution:  
      - labelSelector:  
          matchExpressions:  
          - {key: app, operator: In, values: ["myapp", "web", "mysql"]}  
        topologyKey: kubernetes.io/hostname
        
# 运行会发现这两个pod不在同一个节点上
NAME            READY   STATUS    RESTARTS   AGE   IP              NODE     NOMINATED NODE   READINESS GATES
pod-first-web   1/1     Running   0          31s   10.233.82.52    node01   <none>           <none>
pod-second      1/1     Running   0          8s    10.233.113.48   node02   <none>           <none>

3.pod亲和性和反亲和性

# 给node01 和node02 打上标签
[root@master01 ~]# kubectl label node node01 zone=test1
node/node01 labeled
[root@master01 ~]# kubectl label node node02 zone=test
node/node02 labeled
apiVersion: v1
kind: Pod
metadata:
  name: pod-test1
  labels:
    security: S1
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
  nodeSelector:
    zone: test1
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-test2
  labels:
    security: S1
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
  nodeSelector:
    zone: test
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-test3
  labels:
    security: S2
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
  nodeSelector:
    zone: test    
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-first
  labels:
    security: S2
    tier: frontend2
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1    
  nodeSelector:
    zone: test1
---
apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: kubernetes.io/hostname
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: kubernetes.io/hostname   # 在反亲和性的条件下做判断，区分不同拓扑域，每个拓扑域做反亲和
  containers:
  - name: with-pod-affinity
    image: nginx


# 例子中指定了pod的亲和性和反亲和性，指定的规则是pod将会调度到的node尽量会满足如下条件：
NAME                READY   STATUS    RESTARTS   AGE   IP              NODE     NOMINATED NODE   READINESS GATES
pod-first           1/1     Running   0          7s    10.233.82.58    node01   <none>           <none>
pod-test1           1/1     Running   0          7s    10.233.82.57    node01   <none>           <none>
pod-test2           1/1     Running   0          7s    10.233.113.53   node02   <none>           <none>
pod-test3           1/1     Running   0          7s    10.233.113.54   node02   <none>           <none>
with-pod-affinity   1/1     Running   0          7s    10.233.113.55   node02   <none>           <none>

1)、podAffinity 亲和性要求满足

node上具有 kubernetes.io/hostname区域，并且 node 上运行有一个pod 包含标签 label为securtity=S1.

2)、podAntiAffinity 反亲和性要求满足

不会调度 pod 到运行包含有 security=S2 的 pod 的 node上．
如果这里将topologyKey＝ kubernetes.io/hostname，那么 pod 将不会调度到 node
满足的条件是：node上具有 kubernetes.io/hostname 相同的 value,并且这些相同 zone下的 node 上运行有 security=S2 的 pod

3)、对于topologyKey字段具有如下约束第一步要配置有key (节点标签名)，第二步这个标签相同值的节点只能启动一个pod zone=cd

topologyKey 定义pod亲和性调度和反亲和性调度中需要各个相关的pod对象是否运行于"同一位置"，指定“同一位置” 是通过 topologyKey 来定义的，topologyKey 对应的值是 node 上的一个标签名称
如果topologyKey指定区域已经在运行一个或多个满足LabelSelector规则的Pod，则该Pod应该（或者在非亲和性的情况下不应该）在 topologyKey 中运行
对于亲和性和反亲和性 requiredDuringSchedulingIgnoredDuringExecution （硬亲和），topologyKey 不能为空。
对于反亲和性 requiredDuringSchedulingIgnoredDuringExecution（硬亲和），引入 LimitPodHardAntiAffinityTopology 准入控制器来限制 topologyKey 只能是 kubernetes.io/hostname。如果要使用自定义拓扑域，则需要修改准入控制器，或者直接禁用它。
对于反亲和性 preferredDuringSchedulingIgnoredDuringExecution （软亲和），空的 topologyKey 表示所有拓扑域，没有限制。
topologyKey 除上述情况外，可以是 node 任何合法的标签 key。规则中可以指定匹配pod所在namespace,如果定义了但是为空，它表示所有namespace范围内的pod.
所有关联requiredDuringSchedulingIgnoredDuringExecution（硬亲和）的matchExpressions全都满足之后，系统才能将pod调度到某个node上。

4.topologKey 调度

需求：当前有两个机房（ beijing，shanghai），需要部署一个nginx产品，副本为两个，为了保证机房容灾高可用场景，需要在两个机房分别部署一个服务器

# 给node分别打上beijing 和shanghai的标签
[root@master01 ~]# kubectl label node node01 zone=beijing
node/node01 labeled
[root@master01 ~]# kubectl label node node02 zone=shanghai
node/node02 labeled


apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-affinity-test
spec:
  replicas: 2
  selector:
    matchLabels:
      service: nginx
  template:
    metadata:
      name: nginx
      labels:
        service: nginx
    spec:
      affinity:
        podAntiAffinity: # 反亲和
          requiredDuringSchedulingIgnoredDuringExecution: # 硬亲和标签
          - labelSelector:
              matchExpressions:
              - key: service
                operator: In
                values:
                - nginx
            topologyKey: zone    # 在反亲和性的条件定义为zone键下做判断，区分不同拓扑域，每个拓扑域做反亲和
      containers:
      - name: nginx
        image: busybox:latest
        command: ["sh","-c","sleep 3600"]
        
# 两个node上分别有zone标签，来标注自己属于哪个机房，topologyKey定义为zone，pod所以在调度的时候，会根据node上zone标签来区分拓扑域，当前用的上 反亲和性调度 根据拓扑纬度调度，beijing机房调度完一个pod后，然后控制器判断beijing 拓扑域已经有server=nginx标签的pod，就在下一个拓扑域的node上调度了
        
# 可以看到俩个pod通过toplogyKey匹配到了不同的node下
NAME                                   READY   STATUS    RESTARTS   AGE   IP              NODE     NOMINATED NODE   READINESS GATES
nginx-affinity-test-6d68d588cd-27xnj   1/1     Running   0          8s    10.233.82.59    node01   <none>           <none>
nginx-affinity-test-6d68d588cd-qkfj4   1/1     Running   0          8s    10.233.113.56   node02   <none>           <none>

四.Pod亲和性调度常用场景

1.pod反亲和性调度

创建了一个Deployment,副本数为３，指定了反亲和规则如上所示，pod的label为app:store,那么pod调度的时候将不会调度到node上已经运行了label为app:store的pod了，这样就会使得Deployment的三副本分别部署在不同的host的node上

apiVersion: apps/v1 
kind: Deployment
metadata:
  name: redis-cache
spec:
  replicas: 3    # 必须有对应的节点数（master不能创建pod）
  selector:
    matchLabels:
      app: store
  template:
    metadata:
      labels:
        app: store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: redis-server
        image: redis:3.2-alpine
# 每个节点保证有一个pod 必须满足这个 pod 有 app = store 这样的标签，如果存在这样的 pod 就不满足要求

2.pod亲和性调度

在一个例子中基础之上，要求pod的亲和性满足 requiredDuringSchedulingIgnoredDuringExecution 中topologyKey=”kubernetes.io/hostname”,并且 node上需要运行有 app=store 的label.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  replicas: 4   #必须有对应的节点数（master不能创建pod）
  selector:
    matchLabels:
      app: web-store
  template:
    metadata:
      labels:
        app: web-store
    spec:
      affinity:
        podAntiAffinity: # 反亲和性
          requiredDuringSchedulingIgnoredDuringExecution: # 硬亲和
          - labelSelector:
              matchExpressions:
              - key: app 
                operator: In
                values:
                - web-store
            topologyKey: "kubernetes.io/hostname"
        podAffinity: # 亲和性
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: web-app
        image: nginx:1.12-alpine

3.pod亲和性调度

在一些应用中，pod副本之间需要共享cache,需要将pod运行在一个节点之上

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: web-store
    spec:
      affinity:
        podAffinity: # 亲和性
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - web-store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: web-app
        image: nginx

五.污点容忍调度(Taint和Toleration)

污点（Taints）和污点容忍（Tolerations）是 Kubernetes（k8s）中用于节点调度的另一种重要机制。以下是对污点容忍调度的详细解释：

1、污点（Taints）

污点是定义在节点上的键值型属性数据，用于让节点拒绝将 Pod 调度运行于其上，除非 Pod 有接纳节点污点的容忍度。污点可以使节点能够排斥一类特定的 Pod，避免 Pod 调度到特定节点上。

污点的格式：

key=value:effect

key 和 value 是污点的标签。

effect 描述污点的作用，支持以下三个选项：

NoSchedule：Pod 将不会被调度到具有该污点的节点上，但已经正在运行中的 Pod 不受影响。

PreferNoSchedule：Pod 将尽量避免调度到具有该污点的节点上，已经正在运行中的 Pod 不受影响。

NoExecute：Pod 将不会被调度到具有该污点的节点上，同时将节点上已经存在的 Pod 进行驱逐。如果因节点污点变动或 Pod 容忍度变动而不再满足匹配规则，Pod 对象将被驱逐。

# 添加污点：
kubectl taint nodes <node-name> key=value:effect

# 删除污点：
kubectl taint nodes <node-name> key[:effect]-（effect 可以省略）

2、污点容忍（Tolerations）

污点容忍是定义在 Pod 上的键值型属性数据，用于配置 Pod 可容忍的污点。调度器只能将 Pod 调度到该 Pod 能够容忍的污点的节点上。

# 污点容忍的格式：
在 Pod 的 spec 字段中定义 tolerations 列表，每个 toleration 都包含 key、operator、value 和 effect 字段。

key：污点的键。

operator：操作符，可以是 Equal（等于）或 Exists（存在）。Equal 表示污点的键和值都必须匹配，Exists 表示只需匹配键即可。

value：污点的值（当 operator 为 Equal 时需要）。

effect：污点的作用效果，必须与节点上的污点效果匹配。

# 使用污点容忍：
如果 Pod 想被调度到具有特定污点的节点上，必须在该 Pod 的定义中添加与该污点匹配的容忍度。

容忍度允许调度但并不保证调度，即使 Pod 具有容忍度，调度器仍然会根据其他调度策略（如亲和性、资源限制等）来决定是否将 Pod 调度到该节点上。

# 应用场景
1. 维护节点：当需要对某个节点进行维护时，可以给该节点添加一个污点，以阻止新的 Pod 被调度到该节点上。同时，可以给需要继续在该节点上运行的 Pod 添加相应的容忍度。
2. 隔离特定工作负载：可以使用污点和容忍度来隔离特定的工作负载，确保它们不会与其他工作负载混合在一起运行。
3. 利用专用硬件：如果集群中有一些节点配备了专用硬件（如 GPU），可以使用污点和容忍度来确保只有特定的 Pod 能够被调度到这些节点上。

3.污点与容忍度匹配规则

当Pod的容忍度与节点的污点在键、值（当操作符为Equal时）和效应上完全匹配时，Pod可以被调度到该节点上。
如果Pod的容忍度使用Exists操作符，则只需匹配键和效应，无需匹配值。
Pod可以具有多个容忍度，以匹配节点上的多个污点。

4.操作实例

# 为节点添加污点
[root@master01 ~]# kubectl taint nodes node01 special=gpu:NoSchedule
node/node01 tainted
[root@master01 ~]# kubectl taint nodes node02 node-type=dev:NoSchedule
node/node02 tainted
# 查看节点污点命令
[root@master01 ~]# kubectl describe nodes |grep Taint -A 2
Taints:             node-role.kubernetes.io/control-plane:NoSchedule
Unschedulable:      false
Lease:
--
Taints:             special=gpu:NoSchedule
Unschedulable:      false
Lease:
--
Taints:             node-type=dev:NoSchedule
Unschedulable:      false
Lease:

apiVersion: v1  
kind: Pod  
metadata:  
  name: mypod  
spec:  
  containers:  
  - name: nginx 
    image: nginx  
  tolerations:  
  - key: "special"  
    operator: "Equal" 
    value: "gpu"  
    effect: "NoSchedule"

# 可以看到pod匹配到了可以容忍的污点上
NAME    READY   STATUS    RESTARTS   AGE   IP              NODE     NOMINATED NODE   READINESS GATES
mypod   1/1     Running   0          5s    10.233.113.58   node01   <none>           <none>

5.设置容忍时间

污点容忍时间，主要涉及的是当节点被设置了NoExecute类型的污点时，Pod如果没有相应的容忍度，则会被驱逐出该节点。然而，如果Pod具有对应的容忍度，并且容忍度中设置了tolerationSeconds字段，那么Pod在被驱逐前还可以在节点上继续运行一段时间。tolerationSeconds字段指定了Pod在节点上可以继续运行的时间（单位为秒），这相当于给Pod一个宽限期，让其有时间完成必要的清理工作或等待其他操作完成。

# 假如有一个节点被设置成NoExecute
kubectl taint nodes node-1 key=value:NoExecute

# 此时，如果一个Pod想要被调度到该节点上，并且希望在被驱逐前有3600秒的宽限期，那么它需要在容忍度中设置如下内容：
tolerations:  
- key: "key"  
  operator: "Equal"  
  value: "value"  
  effect: "NoExecute"  
  tolerationSeconds: 3600
# 这样，当Pod被调度到该节点上时，如果节点出现了NoExecute类型的污点，Pod仍然可以在节点上继续运行3600秒，然后才会被驱逐。
# 污点容忍时间在Kubernetes中主要用于控制Pod在被驱逐前的运行时间，以确保Pod有足够的时间完成必要的操作。通过合理设置tolerationSeconds字段的值，可以满足不同的业务需求。

6.污点驱逐

边我们提到了污点的effect可以设置为 NoExecute，它会影响节点上已经运行的pod，如下所示：

立即将没有配置容忍的pod逐出。
设置容忍但是没有指定 tolerationSeconds 参数的，那么该容忍永久生效。
设置容忍但是有指定 tolerationSeconds 参数的，那么在指定的时间内，容忍有效，超出指定时间后将被剔除。

此外，当某些条件为true时，节点控制器会自动污染节点。也就是k8s的内置污点：

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删除此污点。

查看全文

http://www.kler.cn/a/375841.html