整体流程

client向APIServer发送创立pod的申请：

  1. APIServer将pod信息存入etcd，告诉Scheduler；
  2. Scheduler依据调度算法，为pod抉择一个节点，而后向APIServer发送更新spec.nodeName；
  3. APIServer更新结束，告诉对应节点的kubelet；
  4. 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之间是程序启动的，参考源码；

参考

  1. kubernetes in action
  2. container启动源码：https://github.com/kubernetes...