Kubernetes各组件工作原理 & Pod 生命周期

一、kubernets 组件工作原理

- 概述：

        在集群管理方面，kubernetes 将集群中的机器分为 Master（主）节点和一些 node（工作）节点。在 Master 节点上运行这一些集群管理相关的进程组件：kube-apiserver、kube-controller-manager 和 kube-scheduler ，这些组件进程实现了整个集群的资源管理、pod 调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，并且都是自动完成的。node 节点作为 kubernetes 集群当中的工作节点（work node），上面运行着真正提供服务的应用程序服务。在 node 节点上，kubernets 管理的最小工作单元是 pod，在 node 节点上运行着 kubelete、kube-proxy 服务进程，这些服务负责 pod 的创建、启动、监控、重启、销毁、以及实现软件模式的负载均衡器，接下来详细讲解各个组件的工作原理及流程；

- kubernetes 整个访问流程：

        如上图，用户执行 kubectl 或者在 Web UI 向集群内发起创建 pod 或其他增删改查的指令 ，请求会被送到 kube-apiserver 组件上，其中他们之间通信用的是 HTTP/HTTPS 协议，经过 kube-apiserver 认证授权（RBAC/ABAC）后，会经过 kube-scheduler 调度策略，kubelet 会定期的收集 node 节点上的资源利用率（cpu、mem、disk）并提交给 kube-scheduler，kube-scheduler 收到 kubelet 采集的节点信息之后会判断哪个 node 节点满足调度条件，然后告诉 kube-apiserver，kube-apiserver 会请求相关 node 的 kubelet，通过 kubelet 把 pod 运行起来，kube-apiserver 会将 pod 的信息保存在 etcd；pod运行起来后，kube-controller-manager 会负责管理 pod 的状态并管维护 pod 的生命周期，如果 pod 挂了，kube-controller-manager 会重新创建新的 pod 来维持副本数目（replicas）的期望值状态；pod 会有一个独立的 ip 地址由 flannel/calico 分配，但 pod 的 IP 是易变的，比如 pod 异常重启，或服务升级的时候，pod 的 IP 就会发生改变，还有一种情况就是 pod 需要对外提供服务访问，多个 pod 副本需要集中的对外部提供服务，此时就需要 Service 来进行 pod 的服务发现，通过标签的方式将 svc 和 pod 进行关联；完成 Service 工作的具体模块是 kube-proxy；在每个 node 上都会有一个 kube-proxy，在任何一个节点上访问一个 Service 的虚拟 ip（cluster IP），都可以访问到pod；如果需要将 pod 服务对集群外部提供访问，需要使用 NodePort 或 Ingerss-nginx 的方式对外提供，NodePort 对外提供的是 ip+端口的方式，而 ingress 则是提供域名访问的方式；

---

二、Pod 生命周期

- pod 的运行状态：

Pending状态（等待）：Pod已经被创建，但还没有完成调度，或者说有⼀个或多个镜像正处于从远程仓库下载的过程。处在这个阶段的Pod可能正在写数据到etcd中、调度、pull镜像或启动容器。
Running状态（运行）：该 Pod 已经绑定到了⼀个节点上，Pod 中所有的容器都已被创建。⾄少有⼀个容器正在运⾏，或者正处于启动或重启状态。
Succeeded状态（成功）：Pod中的所有的容器已经正常的执⾏后退出，并且不会⾃动重启，⼀般会是在部署job的时候会出现。
Failed 状态（失败）：Pod 中的所有容器都已终⽌了，并且⾄少有⼀个容器是因为失败终⽌。也就是说，容器以⾮0状态退出或者被系统终⽌。
Unkonwn（未知）：状态API Server⽆法正常获取到Pod对象的状态信息，通常是由于其⽆法与所在⼯作节点的kubelet通信所致。

- 什么是生命周期？

        生命周期既整个程序从开始运行到结束之间的范围称之为生命周期，如下将讲解 pod 在整个生命周期的详细流程；

-pod 生命周期流程

        管理员通过 kubectl 或者 webUI（ranger、kubeSphere）向 kubeAPI-server 下达创建 pod 的指令，请求会通过 etcd（存储配置创建等信息） 到达 kubelet，kubelet 会调用 CRI 来对容器进行初始化，初始化过程会先在 pod 中创建 pause 容器，该容器包含了 pod 中主容器的网络协议栈以及存储机制，pod 中的网络以及存储是通过 pause 容器进行联通的，如果设置 initC 机制 pause 会先执行 initC 容器，该容器会将 MainC 主容器所需要的前置工作，比如想要运行一个pod,里面运行两个不同的容器，这两个容器的运行条件就是在本机的xx存储下有一个xx文件存在他才能运行。通过 init C 生成该文件，初始化完成后进程就死亡。如果准备就绪并且该容器的退出状态码为 0 则代表前置任务准备无误，之后开始运行 MainC，MainC 在运行时会定义 START 机制，改操作会设置 MainC 容器启动时做什么操作，例如执行脚本或某个命令，之后时 readiness 和 Liveness 用于检测容器当中的服务是否正常启动，其次就是 STOP 定义容器在正常退出时会执行什么操作，下面将详细讲解 Main C 中的几种运行机制；

- InitC 是什么？

        initC 既初始化容器，在 kubelet  创建 pod 时假如定义了 initC,会先执行 initC 来完成主容器的初始化，也就是主容器在运行之前需要的前置工作，会由 initC 来完成，initC 容器与普通容器非常相似，不同的是 initC 容器总是运行到成功完成为止，每个 initC 容器都必须在下一个 initC 容器启动之前成功完成，如果 pod 的 initC 容器失败，kubernetes 默认会一直重启该 pod ，直到 initC 容器启动成功为止，如果定义重启策略（restartPolicy）为 Never 则不会重启 pod；

- MainC 的运行机制：

START：设置 MainC 容器启动时做什么操作，例如执行脚本或某个命令；

Readiness （就绪检测）：假设 Pod 中创建一个容器 tomcat，应用运行在容器里面，当容器开始启动之后程序并没有完全运行，但是 pod 依然是 running 状态，此时该容器已经通过svc将端口暴露到 k8s 集群之外的环境，客户端已经可以通过该端口进行访问，然而服务并没有完全运行，导致服务访问 404 或者其它问题，这种情况就可以通过 readiness 机制来实现该问题，readiness 可以通过检测 tcp 协议，或者http协议等等来对此容器中运行的应用程序进行检测，当服务正真的运行时则在集群中显示 running 状态（Read 状态为 1），也可以定义容器在启动之后的几秒之后启动该机制；

Liveness（生存检测）：假设pod中创建一个主容器(Main C) 运行的应用程序叫nginx，应用运行在容器里面,当容器在运行的过程中进程突然中断，出现僵死状态，此时服务还在运行，但是服务已经无法再正常的运行，此时就需要liveness来对该应用程序进行一个生存检测，当容器中的服务出现僵死状态时则会对该应用程序进行检测发现并进行重启容器或者删除容器等操作；

STOP：设置 MainC 容器退出停止时做什么操作，例如执行脚本或某个命令；