云原生之K8S------list-watch机制，调度约束以及故障排查

一，list-watch机制

1，list-watch介绍

1，kubernetes是通过list-watch的机制进行每个组件的动作，保持数据同步的，每个组件之间的设计实现了解耦。

2，用户是通过kubelet根据配置文件，向apiserver发送命令，在node节点上面建立pod和container。

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

3，在kubernetes中，所以部署的信息都会写到etcd中保存，实际上etcd在存储部署信息的时候，会发送create事件给APIserver会通过监听（watch）etcd发过来的事件。其他组件也会监听APIserver发出来的事件。

2，list-watch工作流程

pod是kubernetes的基础单元，pod启动典型创建过程如下：

 1，这里有三个list-watch，分别是controller manager（运行在Master），Scheduler（运行在Master），kubelet（运行在node）。他们在进程已启动就会监听（watch）APIserver出来的事件。

2，用户通过kubectl或其他API客户端请求给APIserver来建立一个pod对象副本。

3，APIserver尝试着将pod对象的相关元信息存入etcd中，带写入操作执行完成，APIserver即会返回确认信息至客户端。

4，当etcd接受创建pod信息1以后，会发送一个create事件给APIserver。

5，由于controller manager 一直在监听（watch ，通过http的8080端口）APIserver中的事件，次时APIserver接受到了create事件，又会发送给controller manager。

6，controller manager 在接到create事件后，调用其中的replication controller 来保证node上面需要创建的副本数量。一旦副本数量少于rc中定义的数量，RC会自动创建副本，总之它是保证副本数量的controller。

7，在controller manager  创建pod副本以后，APIserver会在etcd中记录这个pod的详细信息。

例如pod的副本数，container的内容是什么。

8，同样的etcd会将创建pod的详细通过时间发送给APIserver。

9，由于 Scheduler 在监听（Watch）APIServer，并且它在系统中起到了“承上启下”的作用，“承上”是指它负责接收创建的Pod 事件，为其安排 Node；“启下”是指安置工作完成后，Node 上的 kubelet 进程会接管后继工作，负责 Pod生命周期中的“下半生”。 换句话说，Scheduler 的作用是将待调度的 Pod 按照调度算法和策略绑定到集群中 Node 上。

10，Scheduler 调度完毕以后会更新 Pod 的信息，此时的信息更加丰富了。除了知道 Pod 的副本数量，副本内容。还知道部署到哪个Node 上面了。并将上面的 Pod 信息更新至 API Server，由 APIServer 更新至 etcd 中，保存起来。

11，etcd将更新成功的事件发送给APIaerver，APIserver也开始反映此pod对象的调度结果。

12，kubelet 是在 Node 上面运行的进程，它也通过 List-Watch的方式监听（Watch，通过https的6443端口）APIServer 发送的 Pod 更新的事件。kubelet会尝试在当前节点上调用 Docker 启动容器，并将 Pod 以及容器的结果状态回送至 APIServer。

13，APIServer 将 Pod 状态信息存入 etcd 中。在 etcd确认写入操作成功完成后，APIServer将确认信息发送至相关的 kubelet，事件将通过它被接受。

注意：在创建pod的工作就已经完成了后，为什么kubelet还要一直监听呢？原因很简单，假设这个时候kubectl发命令，要扩充pod副本数量，那么上面的流程又会被触发一遍，kubelet会根据最新的pod的部署情况调整node的资源，又或者pod副本数量没有发生变化，，但是其中的镜像文件升级了，kubelet也会自动获取最新的镜像文件并且加载。

二，调度约束（scheducer调度器）

kubernetes通过list-watch的机制进行每个组件的协助，每个组件之间的设计实现了解耦。

1，基本的调度方式

1，nodeName用于将pod调度到指定的node名称上（跳过调度器之间分配）

2，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
 

 

kubectl apply  -f node1.yaml
kubectl get pods -o wide

 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设置标签分别
[root@master ~]#kubectl label nodes node1 zz=cxk
 
[root@master ~]#kubectl label nodes node2 cc=cxk
查看标签
kubectl get nodes --show-labels

[root@master ~]# vim nodeselector.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-example
  labels:
    app: nginx
spec:
  nodeSelector:
    lc: fuheinan
  containers:
  - name: nginx
    image: nginx:1.15

kubectl delete -f nodeselectl.yaml
kubectl get pods -o wide
 

 

三，故障排查

#查看pod事件
kubectl describe TYPE NAME_PREFIX  
#查看pod日志（Failed状态下）
kubectl logs POD_NAME
#进入pod（状态为running，但是服务没有提供）
kubectl exec –it POD_NAME bash