What happens when I type kubectl run?

https://github.com/jamiehannaford/what-happens-when-k8s

kubectl

• 验证和生成器（Validation and generators）：kubectl run 命令首先通过 kubectl 客户端的内置验证机制来检查您输入的命令行参数。这包括检查必要的参数是否存在，以及参数格式是否正确。一旦验证通过，kubectl 使用命令行参数来生成 Kubernetes 资源对象（如 Deployment、Pod 等）的定义。这个定义包含了您希望部署的容器的镜像、副本数量、环境变量等信息。

• API 组和版本协商（API groups and version negotiation）：kubectl 客户端与 API 服务器之间会进行 API 版本的协商，以确保使用正确的 API 版本来创建资源。这是通过在 API 服务器查询支持的 API 版本并选择合适的 API 路径来完成的。

• 客户端认证（Client auth）：Kubectl 在发送请求到服务器之前需要认证用户身份。这通常涉及读取 kubeconfig 配置文件中的用户凭证，可能是证书、令牌或基本认证信息。认证成功后，kubectl 才会向 API 服务器发送创建资源的请求。

kube-apiserver

• 认证（Authentication）：API 服务器首先验证请求者的身份，确认他们是否为系统中认证的用户。这一步骤确保了请求是由一个已认证的用户发起的。

• 授权（Authorization）：一旦用户通过认证，API 服务器接下来会进行授权检查，确保用户有权执行他们请求的操作。这通常通过角色基于访问控制（RBAC）来实现。

• 准入控制器（Admission Controller）：在资源对象被最终创建或更新前，准入控制器对请求进行进一步的处理和验证。它们可以修改请求对象或直接拒绝不符合集群政策的请求。

etcd

• Kubernetes 使用 etcd 作为其所有资源状态的存储后端。当 kube-apiserver 验证并授权请求后，它将新的资源状态存储到 etcd 中。etcd 必须保证高可用性和一致性，以确保 Kubernetes 集群的稳定性。

控制循环（Control loops）

• 部署控制器（Deployment Controller）：当部署资源在 etcd 中被更新后，部署控制器会响应这些变化，确保部署中的 Pod 数量和状态与用户定义的期望状态一致。如果需要，它会启动或关闭 Pod，以匹配声明的副本数量。

• 副本集控制器（ReplicaSet Controller）：类似地，副本集控制器管理着 Pod 的副本集，确保部署和缩放操作符合用户的设定。

• 通知器（Informers）：通知器为控制器提供了关于 Kubernetes 资源的最新信息。这些通知器监听 etcd 中资源的变化，并将更新推送给相关的控制器。

• 调度器（Scheduler）：当有新的 Pod 需要被创建时，调度器选择一个最适合的节点来运行这个 Pod。它根据资源需求、策略约束、亲和性规则等因素做出决策。

Kubelet

• Pod 同步（Pod Sync）：一旦 Pod 被调度到节点上，Kubelet 负责初始化 Pod，包括启动容器、监视容器的状态，并报告回控制平面。

• CRI 和暂停容器（CRI and pause container）：Kubelet 通过容器运行时接口（CRI）与容器运行时进行通信，管理容器的生命周期。暂停容器充当每个 Pod 的网络和存储命名空间的锚点。

• CNI 和 Pod 网络（CNI and pod networking）：Kubelet 使用容器网络接口（CNI）插件来设置 Pod 的网络连接，确保 Pod 之间以及 Pod 与外部世界的正确网络通信。

• 跨主机网络（Inter-host networking）：处理节点之间的网络流量，确保数据可以在它们之间安全有效地传输。

• 容器启动（Container startup）：Kubelet 根据调度决策，执行容器的实际启动过程，包括从镜像库拉取镜像、创建容器、启动容器等。
1. 拉取容器的镜像。如果是私有仓库的镜像，就会使用 PodSpec 中指定的 imagePullSecrets 来拉取该镜像；
2. 通过 CRI 创建容器。 Kubelet 使用 PodSpec 中的信息填充了一个 ContainerConfig 数据结构（在其中定义了 command， image， labels， mounts， devices， environment variables 等），然后通过 protobufs 发送给 CRI。 对于 Docker 来说，它会将这些信息反序列化并填充到自己的配置信息中，然后再发送给 Dockerd 守护进程。在这个过程中，它会将一些元数据（例如容器类型，日志路径，sandbox ID 等）添加到容器中；
3. 然后 Kubelet 将容器注册到 CPU 管理器，它通过使用 UpdateContainerResources CRI 方法给容器分配给本地节点上的 CPU 资源；
4. 最后容器真正地启动；
5. 如果 Pod 中包含 Container Lifecycle Hooks，容器启动之后就会运行这些 Hooks。 Hook 的类型包括两种：Exec（执行一段命令） 和 HTTP（发送HTTP请求）。如果 PostStart Hook 启动的时间过长、挂起或者失败，容器将永远不会变成 Running 状态。