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机制来实现。