一，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
三，故障排查
| 值 | 描述 |
| pending | Pod创建已经提供到kubernettes，但是，因为某种原因而不能顺利创建，例如下载镜像慢，调度不成功 |
| Running | Pod已经绑定到一个节点，并且已经创建了所以容器，至少有一个容器正在运行中，或正在启动或重新启动。 |
| Successed | pod中所以容器都已经成功终止，不会重新启动 |
| Failed | Pod的所以容器均已终止，且至少有一个容器已在故障中终止，也就是说，容器要么以非零状态退出，要不被系统终止， |
| Unknown | 由于某种原因apiserver无法获得pod的状态，通常是由Master与pod所在主机kubelet通信时出错。 |
#查看pod事件
kubectl describe TYPE NAME_PREFIX
#查看pod日志（Failed状态下）
kubectl logs POD_NAME
#进入pod（状态为running，但是服务没有提供）
kubectl exec –it POD_NAME bash