乐趣区

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

整体流程

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