kubernetes|kubernetes (k8s) list-watch机制、调度约束 docker|云原生|linux

目录
一、list-watch工作流程
二、list-watch机制
二、调度约束（scheducer调度器）
1、基本调度方式
2、nodeName
3、nodeSelector
三、故障排查
???????
文章图片

一、list-watch工作流程 Pod是Kubernetes的基础单元，Pod 启动典型创建过程如下
文章图片

这里有三个 List-Watch，分别是 Controller Manager（运行在 Master），Scheduler（运行在Master），kubelet（运行在 Node）。他们在进程已启动就会监听（Watch）APIServer 发出来的事件。
用户通过 kubectl 或其他 API 客户端提交请求给 APIServer 来建立一个 Pod 对象副本。
APIServer 尝试着将 Pod 对象的相关元信息存入 etcd 中，待写入操作执行完成，APIServer即会返回确认信息至客户端。
当 etcd 接受创建 Pod 信息以后，会发送一个 Create 事件给 APIServer。
由于 Controller Manager 一直在监听（Watch，通过http的8080端口）APIServer 中的事件。此时APIServer 接受到了 Create 事件，又会发送给 Controller Manager。
Controller Manager 在接到 Create 事件以后，调用其中的 Replication Controller 来保证Node 上面需要创建的副本数量。一旦副本数量少于 RC 中定义的数量，RC 会自动创建副本。总之它是保证副本数量的Controller（PS：扩容缩容的担当）。
在 Controller Manager 创建 Pod 副本以后，APIServer 会在 etcd 中记录这个 Pod的详细信息。例如 Pod 的副本数，Container 的内容是什么。
同样的 etcd 会将创建 Pod 的信息通过事件发送给 APIServer。
由于 Scheduler 在监听（Watch）APIServer，并且它在系统中起到了“承上启下”的作用，“承上”是指它负责接收创建的Pod 事件，为其安排 Node；“启下”是指安置工作完成后，Node 上的 kubelet 进程会接管后继工作，负责 Pod生命周期中的“下半生”。换句话说，Scheduler 的作用是将待调度的 Pod 按照调度算法和策略绑定到集群中 Node 上。
【kubernetes|kubernetes (k8s) list-watch机制、调度约束】Scheduler 调度完毕以后会更新 Pod 的信息，此时的信息更加丰富了。除了知道 Pod 的副本数量，副本内容。还知道部署到哪个Node 上面了。并将上面的 Pod 信息更新至 API Server，由 APIServer 更新至 etcd 中，保存起来。
etcd 将更新成功的事件发送给 APIServer，APIServer 也开始反映此 Pod 对象的调度结果。
kubelet 是在 Node 上面运行的进程，它也通过 List-Watch的方式监听（Watch，通过https的6443端口）APIServer 发送的 Pod 更新的事件。kubelet会尝试在当前节点上调用 Docker 启动容器，并将 Pod 以及容器的结果状态回送至 APIServer。
APIServer 将 Pod 状态信息存入 etcd 中。在 etcd确认写入操作成功完成后，APIServer将确认信息发送至相关的 kubelet，事件将通过它被接受。
注意：在创建 Pod 的工作就已经完成了后，为什么 kubelet 还要一直监听呢？
原因很简单，假设这个时候 kubectl 发命令，要扩充 Pod 副本数量，那么上面的流程又会触发一遍，kubelet 会根据最新的 Pod 的部署情况调整 Node 的资源。又或者 Pod 副本数量没有发生变化，但是其中的镜像文件升级了，kubelet 也会自动获取最新的镜像文件并且加载。
二、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 发出来的事件。
二、调度约束（scheducer调度器） Kubernetes通过list-watch的机制进行每个组件的协作，每个组件之间的设计实现了解耦。

文章图片

1、基本调度方式

nodeName用于将Pod调度到指定的Node名称上（跳过调度器直接分配）
nodeSelector用于将Pod调度到匹配Label的Node上

2、nodeName

apiVersion: v1 kind: Pod metadata: name: pod-example labels: app: nginx spec: nodeName: node1 containers: - name: nginx image: nginx:1.15

kubernetes|kubernetes (k8s) list-watch机制、调度约束

文章图片

kubectl create -f pod-example.yaml kubectl get pods -o wide

文章图片

kubectl describe po pod-example

文章图片

#清空pod kubectl delete -f .

3、nodeSelector

#查看标签用法 kubectl label --help Usage: kubectl label [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version] [options]

#需要获取node上的NAME名称 kubectl get node#给对应的node设置标签分别为li=yo和zb=xx kubectl label nodes node1（节点名字为none的用IP） ly=yo kubectl label nodes node2 zb=xx #查看标签 kubectl get nodes --show-labels

文章图片

apiVersion: v1 kind: Pod metadata: name: pod-example labels: app: nginx spec: nodeSelector: zb=xx containers: - name: nginx image: nginx:1.14

文章图片

kubectl create -f pod-example.yaml kubectl get pods -o wide

文章图片

kubectl describe po pod-example #查看详细事件（通过事件可以观察经过调度器分配）

文章图片

三、故障排查

值	描述
Pending	Pod创建已经提交到Kubernetes.但是，因为某种原因而不能顺利创建。例如下载镜像慢，调度不成功
Running	Pod已经绑定到一个节点，并且已经创建了所有容器。至少有一个容器正在运行中，或正在启动或重新启动。
Successed	Pod中的所有容器都已经成功终止，不会重新启动
Failed	Pod的所有容器均已终止，且至少有一个容器已在故障中终止。也就是说，容器要么以非零状态退出，要么被系统终止
Unknown	由于某种原因apiserver无法获得Pod的状态，通常是由于Master与Pod所在主机kubelet通信时出错。