1、核心架构
Docker：Manager-Worker
K8s：Master：主节点。掌控整个集群的调度，领导人。
Node-Worker：工作节点。未来的应用默认部署在worker节点。
1主+2从（非高可用的）
底层，容器化环境支持。Docker run？
所有对k8s集群的操作，不会直接操作node（worker）节点，master进行掌控。
高可用方式。master<—>master。集群的状态最终都会到达最终一致性。
1、整体主从方式
2、主节点
-
kube-apiserver
- 主节点上负责提供 Kubernetes API 服务的组件；它是 Kubernetes 控制面的前端。
- kube-apiserver 在设计上考虑了水平扩缩的需要。 换言之，通过部署多个实例可以实现扩缩。 参见构造高可用集群。
-
etcd（redis，mysql）
etcd 是兼具一致性C和高可用性P的键值数据库，持久化存储，可以作为保存 Kubernetes 所有集群数据的后台数据库。
您的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。要了解 etcd 更深层次的信息，请参考 etcd 文档。
可以高可用单独部署，目前实验环境–>和master放在一起部署即可
-
kube-scheduler（调度）
主节点上的组件，该组件监视那些新创建的未指定运行节点的 Pod（一组容器），（Container）并选择节点让 Pod 在上面运行。
调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。
应用部署到哪个节点，scheduler进行调度
-
kube-controller-manager
在主节点上运行控制器的组件。
从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。
这些控制器包括:
- 节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应。
- 副本控制器（Replication Controller）: 负责为系统中的每个副本控制器对象维护正确数量的 Pod。
- 端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)。
- 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌.
未来要应用部署–》部署3个副本。—》controllermanager根据要求进行应用相关配置等信息的创建。—》创建好以后Scheduler才进行调度
-
kubectl
操作k8s的命令行工具。kubectl 。底层就是发请求
3、工作节点
Node 节点：真正干活的
节点组件在每个节点上运行，维护运行的 Pod 并提供 Kubernetes 运行环境。
Pod：
在docker里面，最小的部署单元是 Container；
在k8s里面，最小的部署单元是Pod（一个完整的部署应用）；
Pod是一组Container的集合。容器化环境（Docker、）
容器是在Pod内。k8s整个最小操作单元是 Pod。
- kubelet
一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中。
kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中描述的容器处于运行状态且健康。kubelet 不会管理不是由 Kubernetes 创建的容器。
kubelet可以控制，当前node的所有Pod的生命周期。 docker run/
- kube-proxy
kube-proxy 是集群中每个节点上运行的网络代理,实现 Kubernetes Service 概念的一部分。
kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。
如果操作系统提供了数据包过滤层并可用的话，kube-proxy会通过它来实现网络规则。否则，kube-proxy 仅转发流量本身。
- 容器运行环境(Container Runtime)
容器运行环境是负责运行容器的软件。
Kubernetes 支持多个容器运行环境: Docker、 containerd、cri-o、 rktlet 以及任何实现 Kubernetes CRI (容器运行环境接口)。
k8s+Docker
- Fluentd 日志收集 EFK的日志系统
4、架构
watch、list；监听
1、创建tomcat集群 请求过来-》master节点的apiserver
2、apiserver解析请求，把需要干的活解析出来，放在etcd存储集群中
3、apiserver通知 controller manager ，要干活了，controller manager 再从apiserver获取现在还没做的部署
4、controller manager拿到需要做的部署，产生一次部署信息。把这个东西又存到etcd里面。
5、通知 schduler（调度器），该进行调度了，schduler再从apiserver里面拿到刚才controller manager生产的部署信息，进行调度（找一个闲的节点，进行调度）。
6、scheduler 把这个调度规则保存到etcd里面。
7、其他node节点的kubelet 会监听apiserver。发现有自己要干的活了。kubelet就要来活。进行部署