Kubetnetes之（一）基础介绍
Kubetnetes之（一）基础介绍
Kubernetes是谷歌开源的容器集群管理系统，是Google多年大规模容器管理技术Borg的开源版本，主要功能有：
- 基于容器的应用部署、维护和滚动升级
- 负载均衡和服务发现
- 跨机器和跨地区的集群调度
- 自动伸缩
- 无状态服务和有状态服务
- 广泛的Volume支持
- 插件机制保证扩展性
Kubernetes发展非常迅速，已经成为容器编排领域的领导者。
Kubernetes架构
Kubernetes最初源于⾕歌内部的Borg， 提供了⾯向应⽤的容器集群部署和管理系统。 Kubernetes的⽬标旨在消除编排物理/虚拟计算， ⽹络和存储基础设施的负担， 并使应⽤程序运营商和开发⼈员完全将重点放在以容器为中⼼的原语上进⾏⾃助运营。 Kubernetes 也提供稳定、 兼容的基础（平台） ， ⽤于构建定制化的workflows 和更⾼级的⾃动化任务。Kubernetes 具备完善的集群管理能⼒， 包括多层次的安全防护和准⼊机制、 多租户应⽤⽀撑能⼒、 透明的服务注册和服务发现机制、 内建负载均衡器、 故障发现和⾃我修复能⼒、 服务滚动升级和在线扩容、 可扩展的资源⾃动调度机制、多粒度的资源配额管理能⼒。 Kubernetes 还提供完善的管理⼯具， 涵盖开发、 部署测试、 运维监控等各个环节。
Borg简介
Borg是⾕歌内部的⼤规模集群管理系统， 负责对⾕歌内部很多核⼼服务的调度和管理。 Borg的⽬的是让⽤户能够不必操
⼼资源管理的问题， 让他们专注于⾃⼰的核⼼业务， 并且做到跨多个数据中⼼的资源利⽤率最⼤化。
Borg主要由BorgMaster、 Borglet、 borgcfg和Scheduler组成， 如下图所示：
（图片来源于网络）
- BorgMaster是整个集群的大脑，负责维护整个集群的状态，并将数据持久化到Paxos存储中；
- scheduler负责任务的调度，根据应用的特点将其调度到具体的机器上；
- Borglet负责真正运行任务（容器内）;
- borgcfg是Borg的命令行工具，用于跟Borg系统交互，一般通过一个配置文件来提交任务。
Kubernetes架构
Kubernetes借鉴了Borg的设计理念，比如Pod、Service、Label和单Pod单IP等.
Kubernetes主要由一下几个核心组建组成：
- etcd保存了整个集群的状态；
- apiserver提供资源操作的唯一入口，并提供认证、授权、访问、API注册和发现等机制；
- controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
- scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
- kubelet负责维护容器的生命周期，同事也负责Volume（CVI）和网络（CNI）的管理；
- Contaner runtime负责镜像管理以及Pod和容器的真正运行(CRI);
- kube-proxy负责位Service提供cluster内部的服务发现和负载均衡。
除了核心组建，还有一些推荐的插件，其中有的已经成为CNCF的托管项目： - CoreDNS负责位整个集群提供DNS服务
- Ingress Controller为服务提供外网入口
- Prometheus提供资源监控
- Dashboard提供GUI
- Federation提供可用去的集群
Kubernetes的设计理念
Kubernetes的设计理念与分布式系统
分层架构
Kubernetes设计理念和功能类似Linux的分层架构，如下图：
- 核心层：kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境
- 应用层：部署（有状态应用、无状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）
- 管理层：系统度量（如基础设置、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）
- 接口层： kubectl命令行工具、客户端SDK以及集群联邦
- 生态系统： 在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴：
-
- 1）Kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、Faas、OTS应用、ChatOps等
-
- 2）Kubernetes内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等
API设计原则
Kubernetes系统API的设计有以下⼏条原则：
1、所有API应该是声明式的，声明式的操作， 相对于命令式操作，对于重复操作的效果是稳定的，这对于容易出现数据丢失或重复的分布式环境来说是很重要的。另外，声明式操作更容易被⽤户使⽤，可以使系统向⽤户隐藏实现的细节，隐藏实现的细节的同时，也就保留了系统未来持续优化的可能性。此外，声明式的API，同时隐含了所有的API对象都是名词性质的，例如Service、Volume这些API都是名词，这些名词描述了⽤户所期望得到的⼀个⽬标分布式对象。
2、API对象是彼此互补⽽且可组合的。 这⾥⾯实际是⿎励API对象尽量实现⾯向对象设计时的要求， 即“⾼内聚， 松耦合”， 对业务相关的概念有⼀个合适的分解， 提⾼分解出来的对象的可重⽤性。 事实上， Kubernetes这种分布式系统管理平台， 也是⼀种业务系统， 只不过它的业务就是调度和管理容器服务。
3、⾼层API以操作意图为基础设计。 如何能够设计好API， 跟如何能⽤⾯向对象的⽅法设计好应⽤系统有相通的地⽅，⾼层设计⼀定是从业务出发， ⽽不是过早的从技术实现出发。 因此， 针对Kubernetes的⾼层API设计， ⼀定是以Kubernetes的业务为基础出发， 也就是以系统调度管理容器的操作意图为基础设计。
4、低层API根据⾼层API的控制需要设计。 设计实现低层API的⽬的， 是为了被⾼层API使⽤， 考虑减少冗余、 提⾼重⽤性的⽬的， 低层API的设计也要以需求为基础， 要尽量抵抗受技术实现影响的诱惑。
5、尽量避免简单封装， 不要有在外部API⽆法显式知道的内部隐藏的机制。 简单的封装， 实际没有提供新的功能， 反⽽增加了对所封装API的依赖性。 内部隐藏的机制也是⾮常不利于系统维护的设计⽅式， 例如StatefulSet和ReplicaSet， 本来就是两种Pod集合， 那么Kubernetes就⽤不同API对象来定义它们， ⽽不会说只⽤同⼀个ReplicaSet， 内部通过特殊的算法再来区分这个ReplicaSet是有状态的还是⽆状态。
6、API操作复杂度与对象数量成正⽐。 这⼀条主要是从系统性能⻆度考虑， 要保证整个系统随着系统规模的扩⼤， 性能不会迅速变慢到⽆法使⽤， 那么最低的限定就是API的操作复杂度不能超过O(N)， N是对象的数量， 否则系统就
设计理念不具备⽔平伸缩性了。
7、API对象状态不能依赖于⽹络连接状态。 由于众所周知， 在分布式环境下， ⽹络连接断开是经常发⽣的事情， 因此要保证API对象状态能应对⽹络的不稳定， API对象的状态就不能依赖于⽹络连接状态。
8、尽量避免让操作机制依赖于全局状态， 因为在分布式系统中要保证全局状态的同步是⾮常困难的。
控制机制设计原则
- 控制逻辑应该只依赖于当前状态。 这是为了保证分布式系统的稳定可靠， 对于经常出现局部错误的分布式系统， 如果控制逻辑只依赖当前状态， 那么就⾮常容易将⼀个暂时出现故障的系统恢复到正常状态， 因为你只要将该系统重置到某个稳定状态， 就可以⾃信的知道系统的所有控制逻辑会开始按照正常⽅式运⾏。
- 假设任何错误的可能， 并做容错处理。 在⼀个分布式系统中出现局部和临时错误是⼤概率事件。 错误可能来⾃于物理系统故障， 外部系统故障也可能来⾃于系统⾃身的代码错误， 依靠⾃⼰实现的代码不会出错来保证系统稳定其实也是难以实现的， 因此要设计对任何可能错误的容错处理。
- 尽量避免复杂状态机， 控制逻辑不要依赖⽆法监控的内部状态。 因为分布式系统各个⼦系统都是不能严格通过程序内部保持同步的， 所以如果两个⼦系统的控制逻辑如果互相有影响， 那么⼦系统就⼀定要能互相访问到影响控制逻辑的状态， 否则， 就等同于系统⾥存在不确定的控制逻辑。
- 假设任何操作都可能被任何操作对象拒绝， 甚⾄被错误解析。 由于分布式系统的复杂性以及各⼦系统的相对独⽴性， 不同⼦系统经常来⾃不同的开发团队， 所以不能奢望任何操作被另⼀个⼦系统以正确的⽅式处理， 要保证出现错误的时候， 操作级别的错误不会影响到系统稳定性。
- 每个模块都可以在出错后⾃动恢复。 由于分布式系统中⽆法保证系统各个模块是始终连接的， 因此每个模块要有⾃我修复的能⼒， 保证不会因为连接不到其他模块⽽⾃我崩溃。
- 每个模块都可以在必要时优雅地降级服务。 所谓优雅地降级服务， 是对系统鲁棒性的要求， 即要求在设计实现模块时划分清楚基本功能和⾼级功能， 保证基本功能不会依赖⾼级功能， 这样同时就保证了不会因为⾼级功能出现故障⽽导致整个模块崩溃。 根据这种理念实现的系统， 也更容易快速地增加新的⾼级功能， 因为不必担⼼引⼊⾼级功能影响原有的基本功能。
参考文档
Kubernetes指南-倪朋飞
Kubernetes-handbook-jimmysong-20181218
