了解k8s架构及工作流程
· 阅读需 6 分钟
kubernetes架构及工作流程
本章学习kubernetes的架构及工作流程,重点介绍如何使用Workload管理业务应用的生命周期,实现服务不中断的滚动更新,通过服务发现和集群内负载均衡来实现集群内部的服务间访问,并通过ingress实现外部使用域名访问集群内部的服务。
学习过程中会逐步对Django项目做k8s改造,从零开始编写所需的资源文件。通过本章的学习,学员会掌握高可用k8s集群的搭建,同时Django demo项目已经可以利用k8s的控制器、服务发现、负载均衡、配置管理等特性来实现生命周期的管理。
纯容器模式的问题
- 业务容器数量庞大,哪些容器部署在哪些节点,使用了哪些端口,如何记录、管理,需要登录到每台机器去管理?
- 跨主机通信,多个机器中的容器之间相互调用如何做,iptables规则手动维护?
- 跨主机容器间互相调用,配置如何写?写死固定IP+端口?
- 如何实现业务高可用?多个容器对外提供服务如何实现负载均衡?
- 容器的业务中断了,如何可以感知到,感知到以后,如何自动启动新的容器?
- 如何实现滚动升级保证业务的连续性?
- ......
容器调度管理平台
Docker Swarm Mesos Google Kubernetes
2017年开始Kubernetes凭借强大的容器集群管理功能, 逐步占据市场,目前在容器编排领域一枝独秀
架构图
分布式系统,两类角色:管理节点和工作节点
核心组件
-
ETCD:分布式高性能键值数据库,存储整个集群的所有元数据
-
ApiServer: API服务器,集群资源访问控制入口,提供restAPI及安全访问控制
-
Scheduler:调度器,负责把业务容器调度到最合适的Node节点
-
Controller Manager:控制器管理,确保集群资源按 照期望的方式运行
- Replication Controller
- Node controller
- ResourceQuota Controller
- Namespace Controller
- ServiceAccount Controller
- Token Controller
- Service Controller
- Endpoints Controller
-
kubelet:运行在每个节点上的主要的“节点代理”,脏活累活
- pod 管理:kubelet 定期从所监听的数据源获取节点上 pod/container 的期望状态(运行什么容器、运行的副本数量、网络或者存储如何配置等等),并调用对应的容器平台接口达到这个状态。
- 容器健康检查:kubelet 创建了容器之后还要查看容器是否正常运行,如果容器运行出错,就要根据 pod 设置的重启策略进行处理.
- 容器监控:kubelet 会监控所在节点的资源使用情况,并定时向 master 报告,资源使用数据都是通过 cAdvisor 获取的。知道整个集群所有节点的资源情况,对于 pod 的调度和正常运行至关重要
-
kube-proxy:维护节点中的iptables或者ipvs规则
-
kubectl: 命令行接口,用于对 Kubernetes 集群运行命令 https://kubernetes.io/zh/docs/reference/kubectl/
工作流程
- 用户准备一个资源文件(记录了业务应用的名称、镜像地址等信息),通过调用APIServer执行创建Pod
- APIServer收到用户的Pod创建请求,将Pod信息写入到etcd中
- 调度器通过list-watch的方式,发现有新的pod数据,但是这个pod还没有绑定到某一个节点中
- 调度器通过调度算法,计算出最适合该pod运行的节点,并调用APIServer,把信息更新到etcd中
- kubelet同样通过list-watch方式,发现有新的pod调度到本机的节点了,因此调用容器运行时,去根据pod的描述信息,拉取镜像,启动容器,同时生成事件信息
- 同时,把容器的信息、事件及状态也通过APIServer写入到etcd中
架构设计的几点思考
- 系统各个组件分工明确(APIServer是所有请求入口,CM是控制中枢,Scheduler主管调度,而Kubelet负责运行),配合流畅,整个运行机制一气呵成。
- 除了配置管理和持久化组件ETCD,其他组件并不保存数据。意味
除ETCD外
其他组件都是无状态的。因此从架构设计上对kubernetes系统高可用部署提供了支撑。 - 同时因为组件无状态,组件的升级,重启,故障等并不影响集群最终状态,只要组件恢复后就可以从中断处继续运行。
- 各个组件和kube-apiserver之间的数据推送都是通过list-watch机制来实现。