kubernetes-handbook/concepts/concepts.md

133 lines
22 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

# Kubernetes的设计理念
### Kubernetes设计理念与分布式系统
分析和理解Kubernetes的设计理念可以使我们更深入地了解Kubernetes系统更好地利用它管理分布式部署的云原生应用另一方面也可以让我们借鉴其在分布式系统设计方面的经验。
### 分层架构
Kubernetes设计理念和功能其实就是一个类似Linux的分层架构如下图所示
![分层架构示意图](../images/kubernetes-layers-arch.jpg)
* 核心层Kubernetes最核心的功能对外提供API构建高层的应用最内提供插件式应用执行环境
* 应用层部署无状态应用、有状态应用、批处理任务、集群应用等和路由服务发现、DNS解析等
* 管理层系统度量如基础设施、容器和网络的度量自动化如自动扩展、动态Provision等以及策略管理RBAC、Quota、PSP、NetworkPolicy等
* 接口层kubectl命令行工具、客户端SDK以及集群联邦
* 生态系统:在接口层之上的庞大容器集群管理调度的生态系统,可以划分为两个范畴
* Kubernetes外部日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等
* Kubernetes内部CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等
### API设计原则
对于云计算系统系统API实际上处于系统设计的统领地位正如本文前面所说kubernetes集群系统每支持一项新功能引入一项新技术一定会新引入对应的API对象支持对该功能的管理操作理解掌握的API就好比抓住了kubernetes系统的牛鼻子。Kubernetes系统API的设计有以下几条原则
1. **所有API应该是声明式的**。正如前文所说声明式的操作相对于命令式操作对于重复操作的效果是稳定的这对于容易出现数据丢失或重复的分布式环境来说是很重要的。另外声明式操作更容易被用户使用可以使系统向用户隐藏实现的细节隐藏实现的细节的同时也就保留了系统未来持续优化的可能性。此外声明式的API同时隐含了所有的API对象都是名词性质的例如Service、Volume这些API都是名词这些名词描述了用户所期望得到的一个目标分布式对象。
2. **API对象是彼此互补而且可组合的**。这里面实际是鼓励API对象尽量实现面向对象设计时的要求即“高内聚松耦合”对业务相关的概念有一个合适的分解提高分解出来的对象的可重用性。事实上K8s这种分布式系统管理平台也是一种业务系统只不过它的业务就是调度和管理容器服务。
3. **高层API以操作意图为基础设计**。如何能够设计好API跟如何能用面向对象的方法设计好应用系统有相通的地方高层设计一定是从业务出发而不是过早的从技术实现出发。因此针对K8s的高层API设计一定是以K8s的业务为基础出发也就是以系统调度管理容器的操作意图为基础设计。
4. **低层API根据高层API的控制需要设计**。设计实现低层API的目的是为了被高层API使用考虑减少冗余、提高重用性的目的低层API的设计也要以需求为基础要尽量抵抗受技术实现影响的诱惑。
5. **尽量避免简单封装不要有在外部API无法显式知道的内部隐藏的机制**。简单的封装实际没有提供新的功能反而增加了对所封装API的依赖性。内部隐藏的机制也是非常不利于系统维护的设计方式例如PetSet和ReplicaSet本来就是两种Pod集合那么K8s就用不同API对象来定义它们而不会说只用同一个ReplicaSet内部通过特殊的算法再来区分这个ReplicaSet是有状态的还是无状态。
6. **API操作复杂度与对象数量成正比**。这一条主要是从系统性能角度考虑要保证整个系统随着系统规模的扩大性能不会迅速变慢到无法使用那么最低的限定就是API的操作复杂度不能超过O\(N\)N是对象的数量否则系统就不具备水平伸缩性了。
7. **API对象状态不能依赖于网络连接状态**。由于众所周知在分布式环境下网络连接断开是经常发生的事情因此要保证API对象状态能应对网络的不稳定API对象的状态就不能依赖于网络连接状态。
8. **尽量避免让操作机制依赖于全局状态,因为在分布式系统中要保证全局状态的同步是非常困难的**。
### 控制机制设计原则
* **控制逻辑应该只依赖于当前状态**。这是为了保证分布式系统的稳定可靠,对于经常出现局部错误的分布式系统,如果控制逻辑只依赖当前状态,那么就非常容易将一个暂时出现故障的系统恢复到正常状态,因为你只要将该系统重置到某个稳定状态,就可以自信的知道系统的所有控制逻辑会开始按照正常方式运行。
* **假设任何错误的可能,并做容错处理**。在一个分布式系统中出现局部和临时错误是大概率事件。错误可能来自于物理系统故障,外部系统故障也可能来自于系统自身的代码错误,依靠自己实现的代码不会出错来保证系统稳定其实也是难以实现的,因此要设计对任何可能错误的容错处理。
* **尽量避免复杂状态机,控制逻辑不要依赖无法监控的内部状态**。因为分布式系统各个子系统都是不能严格通过程序内部保持同步的,所以如果两个子系统的控制逻辑如果互相有影响,那么子系统就一定要能互相访问到影响控制逻辑的状态,否则,就等同于系统里存在不确定的控制逻辑。
* **假设任何操作都可能被任何操作对象拒绝,甚至被错误解析**。由于分布式系统的复杂性以及各子系统的相对独立性,不同子系统经常来自不同的开发团队,所以不能奢望任何操作被另一个子系统以正确的方式处理,要保证出现错误的时候,操作级别的错误不会影响到系统稳定性。
* **每个模块都可以在出错后自动恢复**。由于分布式系统中无法保证系统各个模块是始终连接的,因此每个模块要有自我修复的能力,保证不会因为连接不到其他模块而自我崩溃。
* **每个模块都可以在必要时优雅地降级服务**。所谓优雅地降级服务,是对系统鲁棒性的要求,即要求在设计实现模块时划分清楚基本功能和高级功能,保证基本功能不会依赖高级功能,这样同时就保证了不会因为高级功能出现故障而导致整个模块崩溃。根据这种理念实现的系统,也更容易快速地增加新的高级功能,以为不必担心引入高级功能影响原有的基本功能。
## Kubernetes的核心技术概念和API对象
API对象是K8s集群中的管理操作单元。K8s集群系统每支持一项新功能引入一项新技术一定会新引入对应的API对象支持对该功能的管理操作。例如副本集Replica Set对应的API对象是RS。
每个API对象都有3大类属性元数据metadata、规范spec和状态status。元数据是用来标识API对象的每个对象都至少有3个元数据namespacename和uid除此以外还有各种各样的标签labels用来标识和匹配不同的对象例如用户可以用标签env来标识区分不同的服务部署环境分别用env=dev、env=testing、env=production来标识开发、测试、生产的不同服务。规范描述了用户期望K8s集群中的分布式系统达到的理想状态Desired State例如用户可以通过复制控制器Replication Controller设置期望的Pod副本数为3status描述了系统实际当前达到的状态Status例如系统当前实际的Pod副本数为2那么复制控制器当前的程序逻辑就是自动启动新的Pod争取达到副本数为3。
K8s中所有的配置都是通过API对象的spec去设置的也就是用户通过配置系统的理想状态来改变系统这是k8s重要设计理念之一即所有的操作都是声明式Declarative的而不是命令式Imperative的。声明式操作在分布式系统中的好处是稳定不怕丢操作或运行多次例如设置副本数为3的操作运行多次也还是一个结果而给副本数加1的操作就不是声明式的运行多次结果就错了。
### Pod
K8s有很多技术概念同时对应很多API对象最重要的也是最基础的是微服务豆荚Pod。Pod是在K8s集群中运行部署应用或服务的最小单元它是可以支持多容器的。Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。Pod对多容器的支持是K8最基础的设计理念。比如你运行一个操作系统发行版的软件仓库一个Nginx容器用来发布软件另一个容器专门用来从源仓库做同步这两个容器的镜像不太可能是一个团队开发的但是他们一块儿工作才能提供一个微服务这种情况下不同的团队各自开发构建自己的容器镜像在部署的时候组合成一个微服务对外提供服务。
Pod是K8s集群中所有业务类型的基础可以看作运行在K8集群中的小机器人不同类型的业务就需要不同类型的小机器人去执行。目前K8s中的业务主要可以分为长期伺服型long-running、批处理型batch、节点后台支撑型node-daemon和有状态应用型stateful application分别对应的小机器人控制器为Deployment、Job、DaemonSet和PetSet本文后面会一一介绍。
### 复制控制器Replication ControllerRC
RC是K8s集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个少于指定数目RC就会启动运行新的Pod副本多于指定数目RC就会杀死多余的Pod副本。即使在指定数目为1的情况下通过RC运行Pod也比直接运行Pod更明智因为RC也可以发挥它高可用的能力保证永远有1个Pod在运行。RC是K8s较早期的技术概念只适用于长期伺服型的业务类型比如控制小机器人提供高可用的Web服务。
### 副本集Replica SetRS
RS是新一代RC提供同样的高可用能力区别主要在于RS后来居上能支持更多种类的匹配模式。副本集对象一般不单独使用而是作为Deployment的理想状态参数使用。
### 部署\(Deployment\)
部署表示用户对K8s集群的一次更新操作。部署是一个比RS应用模式更广的API对象可以是创建一个新的服务更新一个新的服务也可以是滚动升级一个服务。滚动升级一个服务实际是创建一个新的RS然后逐渐将新RS中副本数增加到理想状态将旧RS中的副本数减小到0的复合操作这样一个复合操作用一个RS是不太好描述的所以用一个更通用的Deployment来描述。以K8s的发展方向未来对所有长期伺服型的的业务的管理都会通过Deployment来管理。
### 服务Service
RC、RS和Deployment只是保证了支撑服务的微服务豆荚的数量但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例随时可能在一个节点上停止在另一个节点以一个新的IP启动一个新的Pod因此不能以确定的IP和端口号提供服务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作是针对客户端访问的服务找到对应的的后端服务实例。在K8集群中客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP集群内部通过虚拟IP访问一个服务。在K8s集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是K8s集群内部的负载均衡器。它是一个分布式代理服务器在K8s的每个节点上都有一个这一设计体现了它的伸缩性优势需要访问服务的节点越多提供负载均衡能力的Kube-proxy就越多高可用节点也随之增多。与之相比我们平时在服务器端做个反向代理做负载均衡还要进一步解决反向代理的负载均衡和高可用问题。
### 任务Job
Job是K8s用来控制批处理型任务的API对象。批处理业务与长期伺服业务的主要区别是批处理业务的运行有头有尾而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的spec.completions策略而不同单Pod型任务有一个Pod成功就标志完成定数成功型任务保证有N个任务全部成功工作队列型任务根据应用确认的全局成功而标志成功。
### 后台支撑服务集DaemonSet
长期伺服型和批处理型服务的核心在业务应用可能有些节点运行多个同类业务的Pod有些节点上又没有这类Pod运行而后台支撑型服务的核心关注点在K8s集群中的节点物理机或虚拟机要保证每个节点上都有一个此类Pod运行。节点可能是所有集群节点也可能是通过nodeSelector选定的一些特定节点。典型的后台支撑型服务包括存储日志和监控等在每个节点上支持K8s集群运行的服务。
### 有状态服务集PetSet
K8s在1.3版本里发布了Alpha版的PetSet功能。在云原生应用的体系里有下面两组近义词第一组是无状态stateless、牲畜cattle、无名nameless、可丢弃disposable第二组是有状态stateful、宠物pet、有名having name、不可丢弃non-disposable。RC和RS主要是控制提供无状态服务的其所控制的Pod的名字是随机设置的一个Pod出故障了就被丢弃掉在另一个地方重启一个新的Pod名字变了、名字和启动在哪儿都不重要重要的只是Pod总数而PetSet是用来控制有状态服务PetSet中的每个Pod的名字都是事先确定的不能更改。PetSet中Pod的名字的作用并不是《千与千寻》的人性原因而是关联与该Pod对应的状态。
对于RC和RS中的Pod一般不挂载存储或者挂载共享存储保存的是所有Pod共享的状态Pod像牲畜一样没有分别这似乎也确实意味着失去了人性特征对于PetSet中的Pod每个Pod挂载自己独立的存储如果一个Pod出现故障从其他节点启动一个同样名字的Pod要挂在上原来Pod的存储继续以它的状态提供服务。
适合于PetSet的业务包括数据库服务MySQL和PostgreSQL集群化管理服务Zookeeper、etcd等有状态服务。PetSet的另一种典型应用场景是作为一种比普通容器更稳定可靠的模拟虚拟机的机制。传统的虚拟机正是一种有状态的宠物运维人员需要不断地维护它容器刚开始流行时我们用容器来模拟虚拟机使用所有状态都保存在容器里而这已被证明是非常不安全、不可靠的。使用PetSetPod仍然可以通过漂移到不同节点提供高可用而存储也可以通过外挂的存储来提供高可靠性PetSet做的只是将确定的Pod与确定的存储关联起来保证状态的连续性。PetSet还只在Alpha阶段后面的设计如何演变我们还要继续观察。
### 集群联邦Federation
K8s在1.3版本里发布了beta版的Federation功能。在云计算环境中服务的作用距离范围从近到远一般可以有同主机HostNode、跨主机同可用区Available Zone、跨可用区同地区Region、跨地区同服务商Cloud Service Provider、跨云平台。K8s的设计定位是单一集群在同一个地域内因为同一个地区的网络性能才能满足K8s的调度和计算存储连接要求。而联合集群服务就是为提供跨Region跨服务商K8s集群服务而设计的。
每个K8s Federation有自己的分布式存储、API Server和Controller Manager。用户可以通过Federation的API Server注册该Federation的成员K8s Cluster。当用户通过Federation的API Server创建、更改API对象时Federation API Server会在自己所有注册的子K8s Cluster都创建一份对应的API对象。在提供业务请求服务时K8s Federation会先在自己的各个子Cluster之间做负载均衡而对于发送到某个具体K8s Cluster的业务请求会依照这个K8s Cluster独立提供服务时一样的调度模式去做K8s Cluster内部的负载均衡。而Cluster之间的负载均衡是通过域名服务的负载均衡来实现的。
所有的设计都尽量不影响K8s Cluster现有的工作机制这样对于每个子K8s集群来说并不需要更外层的有一个K8s Federation也就是意味着所有现有的K8s代码和机制不需要因为Federation功能有任何变化。
### 存储卷Volume
K8s集群中的存储卷跟Docker的存储卷有些类似只不过Docker的存储卷作用范围为一个容器而K8s的存储卷的生命周期和作用范围是一个Pod。每个Pod中声明的存储卷由Pod中的所有容器共享。K8s支持非常多的存储卷类型特别的支持多种公有云平台的存储包括AWSGoogle和Azure云支持多种分布式存储包括GlusterFS和Ceph也支持较容易使用的主机本地目录hostPath和NFS。K8s还支持使用Persistent Volume Claim即PVC这种逻辑存储使用这种存储使得存储的使用者可以忽略后台的实际存储技术例如AWSGoogle或GlusterFS和Ceph而将有关存储实际技术的配置交给存储管理员通过Persistent Volume来配置。
### 持久存储卷Persistent VolumePV和持久存储卷声明Persistent Volume ClaimPVC
PV和PVC使得K8s集群具备了存储的逻辑抽象能力使得在配置Pod的逻辑里可以忽略对实际后台存储技术的配置而把这项配置的工作交给PV的配置者即集群的管理者。存储的PV和PVC的这种关系跟计算的Node和Pod的关系是非常类似的PV和Node是资源的提供者根据集群的基础设施变化而变化由K8s集群管理员配置而PVC和Pod是资源的使用者根据业务服务的需求变化而变化有K8s集群的使用者即服务的管理员来配置。
### 节点Node
K8s集群中的计算能力由Node提供最初Node称为服务节点Minion后来改名为Node。K8s集群中的Node也就等同于Mesos集群中的Slave节点是所有Pod运行所在的工作主机可以是物理机也可以是虚拟机。不论是物理机还是虚拟机工作主机的统一特征是上面要运行kubelet管理节点上运行的容器。
### 密钥对象Secret
Secret是用来保存和传递密码、密钥、认证凭证这些敏感信息的对象。使用Secret的好处是可以避免把敏感信息明文写在配置文件里。在K8s集群中配置和使用服务不可避免的要用到各种敏感信息实现登录、认证等功能例如访问AWS存储的用户名密码。为了避免将类似的敏感信息明文写在所有需要使用的配置文件中可以将这些信息存入一个Secret对象而在配置文件中通过Secret对象引用这些敏感信息。这种方式的好处包括意图明确避免重复减少暴漏机会。
### 用户帐户User Account和服务帐户Service Account
顾名思义用户帐户为人提供账户标识而服务账户为计算机进程和K8s集群中运行的Pod提供账户标识。用户帐户和服务帐户的一个区别是作用范围用户帐户对应的是人的身份人的身份与服务的namespace无关所以用户账户是跨namespace的而服务帐户对应的是一个运行中程序的身份与特定namespace是相关的。
### 名字空间Namespace
名字空间为K8s集群提供虚拟的隔离作用K8s集群初始有两个名字空间分别是默认名字空间default和系统名字空间kube-system除此以外管理员可以可以创建新的名字空间满足需要。
### RBAC访问授权
K8s在1.3版本中发布了alpha版的基于角色的访问控制Role-based Access ControlRBAC的授权模式。相对于基于属性的访问控制Attribute-based Access ControlABACRBAC主要是引入了角色Role和角色绑定RoleBinding的抽象概念。在ABAC中K8s集群中的访问策略只能跟用户直接关联而在RBAC中访问策略可以跟某个角色关联具体的用户在跟一个或多个角色相关联。显然RBAC像其他新功能一样每次引入新功能都会引入新的API对象从而引入新的概念抽象而这一新的概念抽象一定会使集群服务管理和使用更容易扩展和重用。
## 总结
从K8s的系统架构、技术概念和设计理念我们可以看到K8s系统最核心的两个设计理念一个是**容错性**,一个是**易扩展性**。容错性实际是保证K8s系统稳定性和安全性的基础易扩展性是保证K8s对变更友好可以快速迭代增加新功能的基础。
按照分布式系统一致性算法Paxos发明人计算机科学家[Leslie Lamport](http://research.microsoft.com/users/lamport/pubs/pubs.html)的理念一个分布式系统有两类特性安全性Safety和活性Liveness。安全性保证系统的稳定保证系统不会崩溃不会出现业务错误不会做坏事是严格约束的活性使得系统可以提供功能提高性能增加易用性让系统可以在用户“看到的时间内”做些好事是尽力而为的。K8s系统的设计理念正好与Lamport安全性与活性的理念不谋而合也正是因为K8s在引入功能和技术的时候非常好地划分了安全性和活性才可以让K8s能有这么快版本迭代快速引入像RBAC、Federation和PetSet这种新功能。
\[1\] [http://www.infoq.com/cn/articles/kubernetes-and-cloud-native-applications-part01](http://www.infoq.com/cn/articles/kubernetes-and-cloud-native-applications-part01)