一,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