乐趣区

关于kubernetes:Kubernetes-pod启动的流程

jiezi

整体流程

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…
退出移动版