K8s集群调度

目录

List-Watch机制

Pod创建过程

Pod调度

预选策略的常见算法

常见的优先级选项包括

指定调度节点

亲和性

污点(Taint) 和 容忍(Tolerations)

污点（taint）

容忍(Tolerations)

cordon 和 drain

Pod启动阶段

如何删除 Unknown 状态的 Pod ?

Worker  Node节点宕机，Pod的驱逐流程

K8S常用的排障手段

---

List-Watch机制

        Kubernetes 是通过 List-Watch 的机制进行每个组件的协作，保持数据同步的，每个组件之间的设计实现了解耦。

        用户是通过 kubectl 根据配置文件，向 APIServer 发送命令，在 Node 节点上面建立 Pod 和 Container。

        APIServer 经过 API 调用，权限控制，调用资源和存储资源的过程，实际上还没有真正开始部署应用。这里需要 Controller Manager、Scheduler 和 kubelet 的协助才能完成整个部署过程。

        在 Kubernetes 中，所有部署的信息都会写到 etcd 中保存。实际上 etcd 在存储部署信息的时候，会发送 Create 事件给 APIServer，而 APIServer 会通过监听（Watch）etcd 发过来的事件。其他组件也会监听（Watch）APIServer 发出来的事件。

Pod创建过程

1）客户端向apiserver发送创建Pod的请求，然后apiserver将请求信息存入到etcd中

2）存入完成后，etcd会通过apiserver发出创建Pod资源的事件

3）controller manager通过list-watch机制一直监听着apiserver发出的事件，创建相关Pod资源，创建完成后，再通过apiserver存入到etcd中

4）etcd存入Pod资源创建成功的信息后，再次通过apiserver发出调度Pod的事件

5）scheduler通过list-watch机制一直监听着apiserver发出的事件，将新创建的Pod资源调度到合适的node节点上，然后scheduler通过apiserver将调度信息存入到etcd中

6）etcd存入调度信息后，有一次通过apiserver发出创建与管理Pod的事件

7）kubelet通过list-watch机制一直监听着apiserver发出的事件，在调度的node节点上完成Pod的创建与管理

Pod调度

Scheduler 是 kubernetes 的调度器，主要的任务是把定义的 pod 分配到集群的节点上。

其主要考虑的问题如下：

• 公平：如何保证每个节点都能被分配资源
• 资源高效利用：集群所有资源最大化被使用
• 效率：调度的性能要好，能够尽快地对大批量的 pod 完成调度工作
• 灵活：允许用户根据自己的需求控制调度的逻辑

Sheduler 是作为单独的程序运行的，启动之后会一直监听 APIServer，获取 spec.nodeName 为空的 pod，对每个 pod 都会创建一个 binding，表明该 pod 应该放到哪个节点上。

调度分为几个部分：

• 首先是过滤掉不满足条件的节点，这个过程称为预算策略（predicate）；
• 然后对通过的节点按照优先级排序，这个是优选策略（priorities）；
• 最后从中选择优先级最高的节点。

如果中间任何一步骤有错误，就直接返回错误。

预选策略的常见算法

• PodFitsResources：节点上剩余的资源是否大于 pod 请求的资源。
• PodFitsHost：如果 pod 指定了 NodeName，检查节点名称是否和 NodeName 匹配。
• PodFitsHostPorts：节点上已经使用的 port 是否和 pod 申请的 port 冲突。
• PodSelectorMatches：过滤掉和 pod 指定的 label 不匹配的节点。
• NoDiskConflict：已经 mount 的 volume 和 pod 指定的 volume 不冲突，除非它们都是只读。

如果在 预选（predicate） 过程中没有合适的节点，pod 会一直在 pending 状态，不断重试调度，直到有节点满足条件。 经过这个步骤，如果有多个节点满足条件，就继续 优选（priorities）过程：按照优先级大小对节点排序。

优先级由一系列键值对组成，键是该优先级项的名称，值是它的权重（该项的重要性）。

常见的优先级选项包括

• LeastRequestedPriority：通过计算CPU和Memory的使用率来决定权重，使用率越低权重越高。也就是说，这个优先级指标倾向于资源使用比例更低的节点。
• BalancedResourceAllocation：节点上 CPU 和 Memory 使用率越接近，权重越高。这个一般和上面的一起使用，不单独使用。比如 node01 的 CPU 和 Memory 使用率 20:60，node02 的 CPU 和 Memory 使用率 50:50，虽然 node01 的总使用率比 node02 低，但 node02 的 CPU 和 Memory 使用率更接近，从而调度时会优选 node02。
• ImageLocalityPriority：倾向于已经有要使用镜像的节点，镜像总大小值越大，权重越高。

通过算法对所有的优先级项目和权重进行计算，得出最终的结果。

指定调度节点

1）通过指定nodeName将pod直接调度到指定的Node节点上，会跳过 Scheduler 的调度策略，该匹配规则是强制匹配

示例：

vim myapp.yaml
apiVersion: apps/v1  
kind: Deployment  
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      nodeName: node01
      containers:
      - name: myapp
        image: soscscs/myapp:v1
        ports:
        - containerPort: 80
		
kubectl apply -f myapp.yaml

kubectl get pods -o wide

//查看详细事件（发现未经过 scheduler 调度分配）
kubectl describe pod myapp-6bc58d7775-6wlpp

2）通过绑定node节点的标签选择器实现指定节点调度，由调度器调度策略匹配 label，然后调度 Pod 到目标节点，该匹配规则属于强制约束

获取标签帮助

kubectl label --help

需要获取 node 上的 NAME 名称

kubectl get node

给对应的 node 设置标签分别为 heitui=hei 和 heitui=tui

kubectl label nodes node01 heitui=hei

kubectl label nodes node02 heitui=tui

查看标签

kubectl get nodes --show-labels

将之前的yaml配置清单修改成 nodeSelector 调度方式

vim myapp1.yaml
apiVersion: apps/v1
kind: Deployment  
metadata:
  name: heitui
spec:
  replicas: 3
  selector:
    matchLabels:
      app: heitui
  template:
    metadata:
      labels:
        app: heitui
    spec:
      nodeSelector:
	    heitui: hei
      containers:
      - name: heitui
        image: nginx
        ports:
        - containerPort: 80

kubectl apply -f myapp1.yaml 

kubectl get pods -o wide

查看详细事件（通过事件可以发现要先经过 scheduler 调度分配）

kubectl describe pod heitui-6fd9455cbb-rz48p

修改一个 label 的值，需要加上 --overwrite 参数

kubectl label nodes node02 heitui=a --overwrite

删除一个 label

kubectl label nodes node02 heitui-

指定标签查询 node 节点

kubectl get node -l heitui=hei

 

亲和性

1）节点亲和性(nodeAffinity)

匹配指定node节点的标签，将要部署的Pod调度到满足条件的node节点上
2）Pod亲和性(podAffinity)

匹配指定的Pod的标签，将要部署的Pod调度到与指定Pod所在的node节点处于同一个拓扑域的node节点上

如果有多个node节点属于同一个拓扑域，通过Pod亲和性部署多个Pod时则调度器会试图将Pod均衡的调度到处于同一个拓扑域的node节点上

3）Pod反亲和性(podAntiAffinity)

匹配指定的Pod的标签，将要部署的Pod调度到与指定Pod所在的node节点处于不同的拓扑域的node节点上

如果有多个node节点不在同一个拓扑域，通过Pod反亲和性部署多个Pod时则调度器会试图将Pod均衡的调度到不在同一个拓扑域的node节点上

如何判断是否在同一个拓扑域？

通过拓扑域key(topologyKey)判断，如果有其它node节点拥有与指定Pod所在的node节点相同的拓扑域key的标签key和值，那么它们就属于同一个拓扑域

pod亲和性调度硬策略

示例：

vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: affinity
  labels:
    app: node-affinity-pod
spec:
  containers:
  - name: with-node-affinity
    image: busybox
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: heitui    #指定node的标签
            operator: NotIn     #设置Pod安装到kubernetes.io/hostname的标签值不在values列表中的node上
            values:
            - tui
		

kubectl apply -f pod1.yaml

kubectl get pods -o wide

pod亲和性调度软策略

示例：

vim pod2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: affinity
  labels:
    app: node-affinity-pod
spec:
  containers:
  - name: with-node-affinity
    image: soscscs/myapp:v1
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1   #如果有多个软策略选项的话，权重越大，优先级越高
        preference:
          matchExpressions:
          - key: heitui
            operator: NotIn
            values:
            - tui

kubectl apply -f pod2.yaml

kubectl get pods -o wide

使用 Pod 反亲和性调度

示例：

vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp01
  labels:
    app: myapp01
spec:
  containers:
  - name: myapp01
    image: nginx
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: heitui
              operator: In
              values:
              - hei
          topologyKey: kubernetes.io/hostname

#如果节点处于 Pod 所在的同一拓扑域且具有键“app”和值“myapp01”的标签， 则该 pod 不应将其调度到该节点上。 （如果 topologyKey 为 kubernetes.io/hostname，则意味着当节点和具有键 “heitui”和值“hei”的 Pod 处于相同的拓扑域，Pod 不能被调度到该节点上。）

kubectl apply -f pod3.yaml

kubectl get pods --show-labels -o wide

污点(Taint) 和 容忍(Tolerations)

污点（taint）

        节点亲和性，是Pod的一种属性（偏好或硬性要求），它使Pod被吸引到一类特定的节点。Taint 则相反，它使节点能够排斥一类特定的 Pod。

        Taint 和 Toleration 相互配合，可以用来避免 Pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ，这表示对于那些不能容忍这些 taint 的 Pod，是不会被该节点接受的。如果将 toleration 应用于 Pod 上，则表示这些 Pod 可以（但不一定）被调度到具有匹配 taint 的节点上。

        使用 kubectl taint 命令可以给某个 Node 节点设置污点，Node 被设置上污点之后就和 Pod 之间存在了一种相斥的关系，可以让 Node 拒绝 Pod 的调度执行，甚至将 Node 已经存在的 Pod 驱逐出去。

污点的组成格式

key=value:effect

每个污点有一个 key 和 value 作为污点的标签，其中 value 可以为空，effect 描述污点的作用。

当前 taint effect 支持如下三个选项：

• NoSchedule：表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上
• PreferNoSchedule：表示 k8s 将尽量避免将 Pod 调度到具有该污点的 Node 上
• NoExecute：表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上，同时会将 Node 上已经存在的 Pod 驱逐出去

设置污点

格式：
    kubectl taint node  key=[value]:effect
例子：
    kubectl taint node node01 key1=value1:NoSchedule

去除污点

格式：
    kubectl taint node  key[=value:effect]-
例子：
    kubectl taint node node01 key1:NoSchedule-

 修改node节点的污点

格式：
    kubectl taint node  key=[value]:effect --overwrite
例子：
    kubectl taint node node01 key=value:NoSchedule --overwrite

容忍(Tolerations)

        设置了污点的 Node 将根据 taint 的 effect:NoSchedule、PreferNoSchedule、NoExecute 和 Pod 之间产生互斥的关系，Pod 将在一定程度上不会被调度到 Node 上。但我们可以在 Pod 上设置容忍(Tolerations)，意思是设置了容忍的 Pod 将可以容忍污点的存在，可以被调度到存在污点的 Node 上。

Pod设置容忍 toleration

格式：
spec:
  tolerations:
  - key: 污点键名
    operator: Equal|Exists
    value: 污点键值
    effect: NoSchedule|PreferNoSchedule|NoExecute

vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp02
  labels:
    app: myapp02
spec:
  containers:
  - name: with-node-affinity
    image: nginx

其它注意事项

（1）当不指定 key 值时，表示容忍所有的污点 key
  tolerations:
  - operator: "Exists"
  
（2）当不指定 effect 值时，表示容忍所有的污点作用
  tolerations:
  - key: "key"
    operator: "Exists"

（3）有多个 Master 存在时，防止资源浪费，可以如下设置
kubectl taint node Master-Name node-role.kubernetes.io/master=:PreferNoSchedule

实践案例：

如果某个 Node 更新升级系统组件，为了防止业务长时间中断，可以先在该 Node 设置 NoExecute 污点，把该 Node 上的 Pod 都驱逐出去
kubectl taint node node01 check=mycheck:NoExecute

此时如果别的 Node 资源不够用，可临时给 Master 设置 PreferNoSchedule 污点，让 Pod 可在 Master 上临时创建
kubectl taint node master node-role.kubernetes.io/master=:PreferNoSchedule

待所有 Node 的更新操作都完成后，再去除污点
kubectl taint node node01 check=mycheck:NoExecute-

cordon 和 drain

将 Node 标记为不可调度的状态，这样就不会让新创建的 Pod 在此 Node 上运行

kubectl cordon  		 #该node将会变为SchedulingDisabled状态

kubectl drain 可以让 Node 节点开始释放所有 pod，并且不接收新的 pod 进程。

kubectl drain  --ignore-daemonsets --delete-emptydir-data --force

--ignore-daemonsets：无视 DaemonSet 管理下的 Pod。
--delete-emptydir-data：如果有 mount local volume 的 pod，会强制杀掉该 pod。
--force：强制释放不是控制器管理的 Pod。

注：执行 drain 命令，会自动做了以下两件事情

• 设定此 node 为不可调度状态（cordon)
• evict（驱逐）了 Pod

kubectl uncordon 将 Node 标记为可调度的状态

kubectl uncordon 

Pod启动阶段

Pod 创建完之后，一直到持久运行起来，中间有很多步骤，也就有很多出错的可能，因此会有很多不同的状态。

一般来说，pod 这个过程包含以下几个步骤：

（1）调度到某台 node 上。kubernetes 根据一定的优先级算法选择一台 node 节点将其作为 Pod 运行的 node

（2）拉取镜像

（3）挂载存储配置等

（4）容器运行起来。如果有健康检查，会根据检查的结果来设置其状态

Pod的可能状态有：

• Pending：表示APIServer创建了Pod资源对象并已经存入了etcd中，但是它并未被调度完成（比如还没有调度到某台node上），或者仍然处于从仓库下载镜像的过程中。
• Running：Pod已经被调度到某节点之上，并且Pod中所有容器都已经被kubelet创建。至少有一个容器正在运行，或者正处于启动或者重启状态（也就是说Running状态下的Pod不一定能被正常访问）。
• Succeeded：有些pod不是长久运行的，比如job、cronjob，一段时间后Pod中的所有容器都被成功终止，并且不会再重启。需要反馈任务执行的结果。
• Failed：Pod中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止，比如 command 写的有问题。
• Unknown：表示无法读取 Pod 状态，通常是 kube-controller-manager 无法与 Pod 通信。Pod 所在的 Node 出了问题或失联，从而导致 Pod 的状态为 Unknow

如何删除 Unknown 状态的 Pod ?

• 从集群中删除有问题的 Node。使用公有云时，kube-controller-manager 会在 VM 删除后自动删除对应的 Node。 而在物理机部署的集群中，需要管理员手动删除 Node（kubectl delete node ）。
• 被动等待 Node 恢复正常，Kubelet 会重新跟 kube-apiserver 通信确认这些 Pod 的期待状态，进而再决定删除或者继续运行这些 Pod。
• 主动删除 Pod，通过执行 kubectl delete pod --grace-period=0 --force 强制删除 Pod。但是这里需要注意的是，除非明确知道 Pod 的确处于停止状态（比如 Node 所在 VM 或物理机已经关机），否则不建议使用该方法。特别是 StatefulSet 管理的 Pod，强制删除容易导致脑裂或者数据丢失等问题。

Worker  Node节点宕机，Pod的驱逐流程

1）K8s的节点生命控制器在超出一定事件后不能与kubelet通信，就会将该节点标记为unknown状态

2）然后自动创建NoExecute污点防止调度器调度新的Pod到该节点

3）已经存在的该节点上的Pod，在经过容忍度时间后（默认tolerationSeconds: 300），会被NoExecute污点自动驱逐

K8S常用的排障手段

kubectl get pods                                   查看Pod的运行状态和就绪状态
kubectl describe <资源类型|pods> <资源名称>        查看资源的详细信息和事件描述，主要是针对没有进入Running阶段的排查手段
kubectl logs  -c <容器名称> [-p]          查看Pod容器的进程日志，主要是针对进入Running阶段后的排查手段
kubectl exec -it  -c <容器名称> sh|bash   进入Pod容器查看容器内部相关的（进程、端口、文件等）状态信息
kubectl debug -it  --image=<临时容器的镜像名> --target=<目标容器>    在Pod中创建临时容器进入目标容器进行调试，主要是针对没有调试工具的容器使用
nsenter -n --target <容器pid>                      在Pod容器的宿主机使用nsenter转换网络命名空间，直接在宿主机进入目标容器的网络命名空间进行抓包等调试

kubectl get nodes           查看node节点运行状态
kubectl describe nodes      查看node节点详细信息和资源描述
kubectl get cs              查看master组件的健康状态
kubectl cluster-info        查看集群信息

journalctl -u kubelet -f    跟踪查看kubelet进程日志