整体流程
client向APIServer发送创建pod的请求:
- APIServer将pod信息存入etcd,通知Scheduler;
- Scheduler根据调度算法,为pod选择一个节点,然后向APIServer发送更新spec.nodeName;
- APIServer更新完毕,通知对应节点的kubelet;
- kubelet发现pod调度到本节点,创建并运行pod的容器;
APIServer处理pod启动
APIServer收到创建pod的请求后:
- 首先,对client来源进行认证,实现方式是证书(cert)或token(sa);
- 然后,对client进行鉴权,确认其是否有创建pod的权限,实现方法是rbac;
- 然后,通过准入控制插件验证或修改资源请求,常用的准入控制插件有:LimitRanger/ResourceQuota/NamespaceLifecycle;
- 最后,将pod资源存储到etcd;
Scheduler处理pod启动
Scheduler监听到APIServer创建pod的事件后:
- 按照默认的调度算法(预选算法+优选算法),为pod选择一个可运行的节点nodeName;
- 向APIServer发送更新pod的消息:pod.spec.nodeName;
- APIServer更新pod,通知nodeName上的kubelet,pod被调度到了nodeName;
Kubelet处理pod启动
kubelet监听到APIServer创建pod的事件后,通知容器运行时dockerd拉取镜像,创建容器,启动容器。
pod中容器的启动过程:
InitC容器:
- 多个initC顺序启动,前一个启动成功后才启动下一个;
- 仅当最后一个initC执行完毕后,才会启动主容器;
- 常用于进行初始化操作或等待依赖的服务已ok;
postStart钩子:
- postStart与container的主进程并行执行;
- 在postStart执行完毕前,容器一直是waiting状态,pod一直是pending状态;
- 若postStart运行失败,容器会被杀死;
startupProbe钩子:
- v1.16版本后新增的探测方式;
- 若配置了startupProbe,就会先禁止其他探测,直到成功为止;
readinessProbe探针:
- 探测容器状态是否ready,准备好接收用户流量;
- 探测成功后,将pod的endpoint添加到service;
livenessProbe探针:
- 探测容器的健康状态,若探测失败,则按照重启策略进行重启;
containers:
- 多个container之间是顺序启动的,参考源码;
参考
- kubernetes in action
- container启动源码:https://github.com/kubernetes...
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。