Kubernetes设计架构
[TOC]
# 纯容器模式的问题
- 业务容器数量庞大,哪些容器部署在哪些节点,使用了哪些端口,如何记录、管理,需要登录到每台机器去管理?
- 跨主机通信,多个机器中的容器之间相互调用如何做,iptables规则手动维护?
- 跨主机容器间互相调用,配置如何写?写死固定IP+端口?
- 如何实现业务高可用?多个容器对外提供服务如何实现负载均衡?
- 容器的业务中断了,如何可以感知到,感知到以后,如何自动启动新的容器?
- 如何实现滚动升级保证业务的连续性?
- ......
# 容器调度管理平台
Docker Swarm Mesos Google Kubernetes
2017年开始Kubernetes凭借强大的容器集群管理功能, 逐步占据市场,目前在容器编排领域一枝独秀 https://kubernetes.io/
# K8S架构图
Kubernetes集群包含两类角色:管理节点和工作节点,一切都基于分布式的存储系统。下面这张图是Kubernetes的架构图。
# 核心组件
ETCD:分布式高性能键值数据库,存储整个集群的所有元数据
ApiServer: API服务器,集群资源访问控制入口,并提供认证、授权、访问控制、API注册和发现等机制;
Scheduler:调度器,负责资源的调度,按照预定的调度策略将Pod调度到相应的机器上;
Controller Manager:负责维护集群的状态,比如故障检测、自动扩展、滚动更新等;
- Replication Controller
- Node controller
- ResourceQuota Controller
- Namespace Controller
- ServiceAccount Controller
- Token Controller
- Service Controller
- Endpoints Controller
kubelet:运行在每个节点上的主要的“节点代理”,负责维护容器的
生命周期
,同时也负责Volume(CVI)和网络(CNI)的管理;脏活累活- pod 管理:kubelet 定期从所监听的数据源获取节点上 pod/container 的期望状态(运行什么容器、运行的副本数量、网络或者存储如何配置等等),并调用对应的容器平台接口达到这个状态。
- 容器健康检查:kubelet 创建了容器之后还要查看容器是否正常运行,如果容器运行出错,就要根据 pod 设置的重启策略进行处理.
- 容器监控:kubelet 会监控所在节点的资源使用情况,并定时向 master 报告,资源使用数据都是通过 cAdvisor 获取的。知道整个集群所有节点的资源情况,对于 pod 的调度和正常运行至关重要
kube-proxy:维护节点中的iptables或者ipvs规则,负责为Service提供cluster内部的服务发现和负载均衡;
kubectl: 命令行接口,用于对 Kubernetes 集群运行命令 https://kubernetes.io/zh/docs/reference/kubectl/
除了核心组件,还有一些推荐的Add-ons:
- kube-dns负责为整个集群提供DNS服务
- Ingress Controller为服务提供外网入口
- Heapster提供资源监控
- Dashboard提供GUI【给开发用】
- Federation提供跨可用区的集群
- Fluentd-elasticsearch提供集群日志采集、存储与查询
# 分层架构
Kubernetes设计理念和功能其实就是一个类似Linux的分层架构,如下图所示
- 核心层:Kubernetes最核心的功能,对外提供API构建高层的应用,对内提供插件式应用执行环境
- 应用层:部署(无状态应用、有状态应用、批处理任务、集群应用等)和路由(服务发现、DNS解析等)
- 管理层:系统度量(如基础设施、容器和网络的度量),自动化(如自动扩展、动态Provision等)以及策略管理(RBAC、Quota、PSP、NetworkPolicy等)
- 接口层:kubectl命令行工具、客户端SDK以及集群联邦
- 生态系统:在接口层之上的庞大容器集群管理调度的生态系统,可以划分为两个范畴
- Kubernetes外部:日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等
- Kubernetes内部:CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等
# 工作流程
Kubernetes基于list-watch机制的控制器架构,实现组件间交互的解耦。
其他组件监控自己负责的资源,当这些资源发生变化时,kube apiserver会通知这些组件,这个过程类似于发布与订阅
create pod -> apiserver -> etcd
scheduler -> apiserver -> etcd = 拿到新创建的pod,并根据调度算法将pod绑定到某个节点
kubelet -> apiserver ->etcd -> 只拿分配到这个节点的pod -> docker api 创建容器
# 架构设计的几点思考
- 系统各个组件分工明确(APIServer是所有请求入口,CM是控制中枢,Scheduler主管调度,而Kubelet负责运行),配合流畅,整个运行机制一气呵成。
- 除了配置管理和持久化组件ETCD,其他组件并不保存数据。意味
除ETCD外
其他组件都是无状态的。因此从架构设计上对kubernetes系统高可用部署提供了支撑。 - 同时因为组件无状态,组件的升级,重启,故障等并不影响集群最终状态,只要组件恢复后就可以从中断处继续运行。
- 各个组件和kube-apiserver之间的数据推送都是通过list-watch机制来实现。