背景
了解一个新的技术，必须要了解的它的历史，它为啥会出现？解决了什么样的问题？
image.png
我们知道现在应用部署的发展史可以分成3个阶段，传统部署->虚拟化部署->容器化部署，那么这3个阶段都解决了什么样的问题，带来了哪些方面的提升呢？
- 传统部署：一台物理主机部署多个应用，多个应用之间会相互抢占资源，不好控制资源分配的问题，也没有办法做到不同的应用之间资源隔离。
- 虚拟化部署：为了解决资源隔离和资源分配的问题，引入了虚拟化的技术，在一台机器上虚拟多台虚拟机，虚拟机之间资源隔离，互不干扰；虚拟化技术是一项重量级的技术，需要重新虚拟化硬件设备，非常耗资源。
- 容器化部署：相比虚拟化，容器化是一项轻量级的技术，各个容器需要遵循CRI的规范创建镜像，然后通过Container Runtime来统一运行和分配资源；容器是轻量级，所有的容器共享操作系统资源，通过Container Runtime调用OCI来做硬件资源和系统资源隔离。
通过上述这些内容我们了解了应用部署的一个发展史，所有的这些技术都是为了更合理的利用机器的资源；K8S只是为了管理容器化后的应用（POD）所产生的一套技术规范，比如：POD需要部署在哪一个node节点上是如果被调度？pod中的镜像是如何启动的？POD如何回收？POD的存储怎么解决？POD的网络如何处理？POD资源如何分配隔离等等？
架构图
image.png
上图是K8S的官网架构图，下面来分析各个组件的作用：
- API-server：提供了控制面访问node上的应用的统一入口，就跟我们java应用网关一样是后端集群的统一入口一样。
- Controller-manager：负责运行控制器的进程
image.png
- Cloud controller manager：不同的云产商通过k8s调用云产商的不同的产品来实现自己的产品和k8s的整合，例如，sevice 的type=loadbancer的，阿里云是通过SLB来实现的，还有一些SLS日志库的操作都是通过CCM来实现的。
image.png
- 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
image.png
- 当一个pod的yml文件通过kubectl提交，需要通过K8S的控制面的kube-scheduler的进行调度。
- 一个pod需要调度到合适的node节点上执行，需要符合相应的调度规则。
- 亲和性：表示pod通过标签优先挂载到哪个node上。
- 污点度：跟亲和性的功能作用不一样，亲和性是优先部署，污点度是排他性的。
- scheduler通过亲和性和污点度的一个调度规则来把pod调度到合适的work 的node节点上。
kubelet启动pod
image.png
- 当一个pod被调度到一个node上的时候。
- kubelet通过pod判断是否有指定Runtime Class ，如果没有使用默认的，如果有使用指定的Container Runtime。
- kubelet通过gRPC协议调用符合CRI接口的Container Runtime启动POD的容器，然后调用相应OCI的实现来做硬件隔离和资源隔离。
pod状态流转图
image.png
- Pending：Pod 已被 Kubernetes 系统接受，但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间。
- Running：Pod 已经绑定到了某个节点，Pod 中所有的容器都已被创建。至少有一个容器仍在运行，或者正处于启动或重启状态。
- Succeeded：pod中的所有容器都已经成功终止，并且不会重新启动。
- Failed：Pod 中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被系统终止。
- Unknown：因为某些原因无法取得 Pod 的状态。这种情况通常是因为与 Pod 所在主机通信失败。
- Terminating：终止的临时状态，需要被调度进行终止，并不是最终的状态。
容器状态
image.png
- Waiting：如果容器并不处在 Running 或 Terminated 状态之一，它就处在 Waiting 状态。 处于 Waiting 状态的容器仍在运行它完成启动所需要的操作：例如， 从某个容器镜像仓库拉取容器镜像，或者向容器应用 Secret 数据等等。 当你使用 kubectl 来查询包含 Waiting 状态的容器的 Pod 时，你也会看到一个 Reason 字段，其中给出了容器处于等待状态的原因。
- Running： Running 状态表明容器正在执行状态并且没有问题发生。 如果配置了 postStart 回调，那么该回调已经执行且已完成。 如果你使用 kubectl 来查询包含 Running 状态的容器的 Pod 时， 你也会看到关于容器进入 Running 状态的信息。
- Terminated：处于 Terminated 状态的容器已经开始执行并且或者正常结束或者因为某些原因失败。 如果你使用 kubectl 来查询包含 Terminated 状态的容器的 Pod 时， 你会看到容器进入此状态的原因、退出代码以及容器执行期间的起止时间。
