背景

了解一个新的技术，必须要了解的它的历史，它为啥会出现？解决了什么样的问题？

我们知道现在应用部署的发展史可以分成3个阶段，传统部署->虚拟化部署->容器化部署，那么这3个阶段都解决了什么样的问题，带来了哪些方面的提升呢？

• 传统部署：一台物理主机部署多个应用，多个应用之间会相互抢占资源，不好控制资源分配的问题，也没有办法做到不同的应用之间资源隔离。
• 虚拟化部署：为了解决资源隔离和资源分配的问题，引入了虚拟化的技术，在一台机器上虚拟多台虚拟机，虚拟机之间资源隔离，互不干扰；虚拟化技术是一项重量级的技术，需要重新虚拟化硬件设备，非常耗资源。
• 容器化部署：相比虚拟化，容器化是一项轻量级的技术，各个容器需要遵循CRI的规范创建镜像，然后通过Container Runtime来统一运行和分配资源；容器是轻量级，所有的容器共享操作系统资源，通过Container Runtime调用OCI来做硬件资源和系统资源隔离。

通过上述这些内容我们了解了应用部署的一个发展史，所有的这些技术都是为了更合理的利用机器的资源；K8S只是为了管理容器化后的应用（POD）所产生的一套技术规范，比如：POD需要部署在哪一个node节点上是如果被调度？pod中的镜像是如何启动的？POD如何回收？POD的存储怎么解决？POD的网络如何处理？POD资源如何分配隔离等等？

架构图

上图是K8S的官网架构图，下面来分析各个组件的作用：

• API-server：提供了控制面访问node上的应用的统一入口，就跟我们java应用网关一样是后端集群的统一入口一样。
• Controller-manager：负责运行控制器的进程

• Cloud controller manager：不同的云产商通过k8s调用云产商的不同的产品来实现自己的产品和k8s的整合，例如，sevice 的type=loadbancer的，阿里云是通过SLB来实现的，还有一些SLS日志库的操作都是通过CCM来实现的。

• etcd：持久化存储的数据库，用于存储集群的持久化的数据。
• kubelet：node节点上的管理员，单一个pod被调度到一个node上的时候，kubelet就会调用相应的Container Runtime来启动pod中的镜像，管理pod的健康状态。
• kube-proxy：node节点上的网络管理员，实现了Service中的部分概念，例如：通过服务名路由到可供选择的pod上去。
• scheduler：集群调度器，用于POD调度哪个node上，怎么进行选择，亲和性和污点；也用于调度定时任务。
• node：用于部署K8S控制面组件和业务自己的pod，可分为master和worker节点，master主要用于部署K8S相关的组件，worker节点用于部署业务相关的POD。

pod启动流程

schduler调度pod

1. 当一个pod的yml文件通过kubectl提交，需要通过K8S的控制面的kube-scheduler的进行调度。
2. 一个pod需要调度到合适的node节点上执行，需要符合相应的调度规则。
3. 亲和性：表示pod通过标签优先挂载到哪个node上。
4. 污点度：跟亲和性的功能作用不一样，亲和性是优先部署，污点度是排他性的。
5. scheduler通过亲和性和污点度的一个调度规则来把pod调度到合适的work 的node节点上。

kubelet启动pod

1. 当一个pod被调度到一个node上的时候。
2. kubelet通过pod判断是否有指定Runtime Class ，如果没有使用默认的，如果有使用指定的Container Runtime。
3. kubelet通过gRPC协议调用符合CRI接口的Container Runtime启动POD的容器，然后调用相应OCI的实现来做硬件隔离和资源隔离。

pod状态流转图

• Pending：Pod 已被 Kubernetes 系统接受，但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间。
• Running：Pod 已经绑定到了某个节点，Pod 中所有的容器都已被创建。至少有一个容器仍在运行，或者正处于启动或重启状态。
• Succeeded：pod中的所有容器都已经成功终止，并且不会重新启动。
• Failed：Pod 中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被系统终止。
• Unknown：因为某些原因无法取得 Pod 的状态。这种情况通常是因为与 Pod 所在主机通信失败。
• Terminating：终止的临时状态，需要被调度进行终止，并不是最终的状态。

容器状态

• Waiting：如果容器并不处在 Running 或 Terminated 状态之一，它就处在 Waiting 状态。 处于 Waiting 状态的容器仍在运行它完成启动所需要的操作：例如， 从某个容器镜像仓库拉取容器镜像，或者向容器应用 Secret 数据等等。 当你使用 kubectl 来查询包含 Waiting 状态的容器的 Pod 时，你也会看到一个 Reason 字段，其中给出了容器处于等待状态的原因。
• Running： Running 状态表明容器正在执行状态并且没有问题发生。 如果配置了 postStart 回调，那么该回调已经执行且已完成。 如果你使用 kubectl 来查询包含 Running 状态的容器的 Pod 时， 你也会看到关于容器进入 Running 状态的信息。
• Terminated：处于 Terminated 状态的容器已经开始执行并且或者正常结束或者因为某些原因失败。 如果你使用 kubectl 来查询包含 Terminated 状态的容器的 Pod 时， 你会看到容器进入此状态的原因、退出代码以及容器执行期间的起止时间。