k8s 核心组件对照nova梳理
1. k8s 核心组件架构图
image.png
控制平面包括三个组件：
- kube-apiserver 资源 crud 接口
- kube-scheduler pod调度，node预选和优选
- kube-controller-manager ，控制资源的创建与回收（reconcile）
- etcd 数据持久化
计算节点组件：
kubelet 创建pod，触发cni加网卡，触发csi加磁盘
容器运行时 提供创建容器的接口
网络组件：
kube-proxy 该组件一般每个节点都要部署，这个图过于纯粹了，可能是为了突出节点和组件的相关性
计算节点组件：
nova-compute 创建虚拟机，加网卡，加磁盘，做快照，导出镜像，vnc等
libvirtd 提供创建虚拟机的接口
其实这些东西之前都是按照nova组件的逻辑去对照的，
1.nova-api restful 接口 资源 crud 接口
2.nova-scheduler 虚拟机调度，物理机预选和优选
3.nova-conductor 前期很多nova 服务都可以直连数据库进行写操作，后来发现并发写不太好控制，所以集中基于nova-conductor进行写操作
- mysql 数据持久化
计算节点组件：
nova-compute 创建虚拟机，加网卡，加磁盘，做快照，导出镜像，vnc等
libvirtd
2. k8s 核心组件和etcd的交互关系
image.png
可以看到和nova 控制面基本一样，也是只有一个服务操作数据库，
图里没展现的，kubelet也是只（直）连 kube-api的
etcd是如何适应k8s的？
1、 中心化控制器，像scheduler，controller-manager组件，以及第三方的crd控制器，比如操作pod和其他crd资源，这些服务都是集中式控制器，一主（多备）
2、“指定node的处理流程”，kubelet来负责处理pod资源的操作细节，类似的cni，csi在每个节点都有一个daemon用于处理磁盘和网卡。
小结：
kube-api 是一个信息中转中心，本身可以做多主，而scheduler，controller-manager 这种只能单点跑，所以大集群场景下，pod的调度速度就取决于并发的资源数，以及scheduler的调度速度，由于不同node上的资源是可以做并发的，而go本身就是面向并发的，所以在执行效率上肯定要比nova的调度效率好很多。
scheduler的设计可能考虑的因素有很多，比如node类型不同，gpu类型，cpu类型，共享以及独占的逻辑，磁盘类型，用户的使用场景，业务类型，亲和性等。
组件作用一览
kube-apiserver
如果需要与您的 Kubernetes 集群进行交互，就要通过 API。Kubernetes API 是 Kubernetes 控制平面的前端，用于处理内部和外部请求。API 服务器会确定请求是否有效（比如基于rbac），如果有效，则对其进行处理。您可以通过 REST 调用、kubectl 命令行界面或其他命令行工具（例如 kubeadm）来访问 API。
kube-scheduler
您的集群是否状况良好？如果需要新的容器，要将它们放在哪里？这些是 Kubernetes 调度程序所要关注的问题。
调度程序会考虑容器集的资源需求（例如 CPU 或内存）以及集群的运行状况。随后，它会将容器集安排到适当的计算节点。
kube-controller-manager
控制器负责实际运行集群，而 Kubernetes 控制器管理器则是将多个控制器功能合而为一。控制器用于查询调度程序，并确保有正确数量的容器集在运行。如果有容器集停止运行，另一个控制器会发现并做出响应。控制器会将服务连接至容器集，以便让请求前往正确的端点。
还有一些控制器用于创建帐户和 API 访问令牌，比如cert-manager。
etcd
配置数据以及有关集群状态的信息位于 etcd（一个键值存储数据库）中。etcd 采用分布式、容错设计，被视为集群的最终事实来源。
<header class="rh-standard-header--component" style="box-sizing: border-box; display: flex; margin-top: 0px; margin-bottom: 16px; flex-flow: row nowrap; align-items: center; justify-content: space-between;">
Kubernetes 节点中会发生什么？
</header>
