kubernetes的基本架构
kubernetes 采用 “控制面/数据面”（Control Plane / Data Plane）架构，集群中计算机被称为“节点”（node），可以是实体机器，也可以是虚拟机器，少量的节点用作控制面来执行集群的维护工作，其他的大部分节点都被规划为数据面，用来跑业务应用。
控制面的节点在kubernetes里叫做 Master Node, 一般简称为Master，它是整个集群的重要部分，相当于kubernetes的大脑和心脏。
数据面的节点在kubernetes里叫做 Woker Node, 一般简称为Worker或者Node，相当于kubernetes的手和脚，在Master的指挥下干活。
Node的数量非常多，构成了一个资源池，kubernetes就在这个池里分配资源，调度应用。
可以使用命令 kubectl get node 来查看 Kubernetes 的节点状态
kubectl get node
节点内部结构
分为组件（Component）和插件（Addon）
组件实现了Kubernetes的核心功能特性，没有这些组件Kubernetes就无法启动
插件则是Kubernetes的一些附加功能，属于“锦上添花”，不安装也不会影响Kubernetes的正常运行
Master 里的组件有哪些
Master 里有 4 个组件，分别是apiserver、etcd、scheduler、controller-manager
apiserver
- 是Master 节点，同时也是整个 Kubernetes 系统的唯一入口
- 对外公开了一系列的 RESTful API，并且加上了验证、授权等功能，所有其他组件都只能和它直接通信
- 是 Kubernetes 里的联络员
etcd
- 是一个高可用的分布式 Key-Value 数据库，用来持久化存储系统里的各种资源对象和状态
- Kubernetes里的配置管理员
- 只与apiserver有直接联系，任何其他组件想要读写etcd里的数据都必须经过apiserver
scheduler
- 负责容器的编排工作
- 检查节点的资源状态，把Pod调度到最适合的节点上运行
- Kubernetes里的部署人员
- 因为节点状态和Pod信息都存储在etcd里，所以scheduler必须通过apiserver才能获得
controller-manager
- 负责维护容器和节点等资源的状态，实现故障检测、服务迁移、应用伸缩等功能
- Kubernetes里的监控运维人员
- 必须通过apiserver获得存储在etcd里的信息，才能够实现对资源的各种操作
这4个组件都被容器化了，运行在集群的Pod里,使用kubectl get pod -n kube-system查看它们的状态
kubectl get pod -n kube-system
Node 里的组件有哪些
Node 里有 3 个组件，分别是 kubelet、kube-proxy、container-runtime
kubelet
- Node的代理，管理Node相关的绝大部分操作
- Node上只有它能够与apiserver通信，实现状态报告、命令下发、启停容器等功能
- Node上的一个“小管家”
kube-proxy
- 是Node的网络代理
- 只负责管理容器的网络通信，简单来说就是为Pod转发TCP/UDP数据包
- Node上专职的“小邮差”
container-runtime
- 容器和镜像的实际使用者，在kubelet的指挥下创建容器，管理Pod的生命周期
- Node上真正干活的“苦力”
这3个组件中只有kube-proxy被容器化了
kubelet因为必须要管理整个节点，容器化会限制它的能力 ，因此必须在container-runtime之外运行
可以通过ps -ef|grep kubelet找到它
ps -ef|grep kubelet
工作流
- 每个Node上的kubelet会定期向apiserver上报节点状态，apiserver再存到etcd里
- 每个Node上的kube-proxy实现了TCP/UDP反向代理，让容器对外提供稳定的服务
- scheduler通过apiserver得到当前的节点状态，调度Pod，然后apiserver下发命令给某个Node的 kubelet，kubelet调用container-runtime启动容器
- controller-manager也通过apiserver得到实时的节点状态，监控可能的异常情况，再使用相应的手段去调节恢复。
希望本篇文章对你有所帮助，谢谢。
