这篇文章将为大家详细讲解有关kubernetes设计理念是什么，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
一、kubernetes设计理念与分布式系统
API设计原则：
对于云计算系统，系统API实际上处于系统设计的统领地位，K8S集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的API对象，支持对该功能的管理操作。
1.所有API应该是声明式的。声明式操作相对于命令式操作，对于重复操作的效果更加稳定，这对于容易出现数据丢失或重复的分布式环境而言很重要。另外声明式操作更容易被用户使用，对用户隐藏细节，同时保留系统未来持续优化的可能性。
2.API对象是彼此互补而且可组合的。提倡API对象尽量实现面向对象的设计要求，达到“高内聚，低耦合”，对业务模块有个合适的分解。本质上K8S这种分布式系统管理平台，也是一种业务系统，只不过它的业务就是调度和管理容器服务。
3.高层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.尽量避免让操作机制依赖于全局状态，因为在分布式系统中要保证全局状态的同步是比较困难的。
控制机制设计原则：
1.控制逻辑应该只依赖于当前状态。
为了保证分布式系统的稳定可靠，对于经常出现局部错误的分布式系统，如果控制逻辑只依赖当前状态，那么就非常容易将一个暂时出现故障的系统恢复到正常状态，因为你只要将该系统重置到某个稳定状态，就可以自信的知道系统的所有控制逻辑会开始按照正常方式运行。
2.假设任何错误的可能，并做容错处理。
在一个分布式系统中出现局部和临时错误是大概率事件。错误可能来自于物理系统故障，外部系统故障也可能来自于系统自身的代码错误，依靠自己实现的代码不会出错来保证系统稳定其实也是难以实现的，因此要设计对任何可能错误的容错处理。
3.尽量避免复杂状态机，控制逻辑不要依赖于无法监控的内部状态。
因为分布式系统各个子系统都是不能严格通过程序内部保持同步的，所以如果两个子系统的控制逻辑如果互相有影响，那么子系统就一定要能互相访问到影响控制逻辑的状态，否则，就等同于系统里存在不确定的控制逻辑。
4.假设任何操作都可能被任何操作对象拒绝，甚至被错误解析。
由于分布式系统的复杂性以及各子系统的相对独立性，不同子系统经常来自不同的开发团队，所以不能奢望任何操作被另一个子系统以正确的方式处理，要保证出现错误的时候，操作级别的错误不会影响到系统稳定性。
5.每个模块都可以在出错后自动恢复。
由于分布式系统中无法保证系统各个模块是始终连接的，因此每个模块要有自我修复的能力，保证不会因为连接不到其他模块而自我崩溃。
6.每个模块都可以在必要时优雅地降级服务。
即要求在设计实现模块时划分清楚基本功能和高级功能，保证基本功能不会依赖高级功能，这样同时就保证了不会因为高级功能出现故障而导致整个模块崩溃。根据这种理念实现的系统，也更容易快速地增加新的高级功能，以为不必担心引入高级功能影响原有的基本功能。
二、kubernetes核心技术概念和API对象
API对象是K8s集群中的管理操作单元。K8s集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的API对象，支持对该功能的管理操作。例如副本集Replica Set对应的API对象是RS。
每个API对象都有3大类属性：元数据metadata、规范spec和状态status。元数据是用来标识API对象的，每个对象都至少有3个元数据：namespace，name和uid；除此以外还有各种各样的标签labels用来标识和匹配不同的对象，例如用户可以用标签env来标识区分不同的服务部署环境，分别用env=dev、env=testing、env=production来标识开发、测试、生产的不同服务。规范描述了用户期望K8s集群中的分布式系统达到的理想状态（Desired State），例如用户可以通过复制控制器Replication Controller设置期望的Pod副本数为3；status描述了系统实际当前达到的状态（Status），例如系统当前实际的Pod副本数为2；那么复制控制器当前的程序逻辑就是自动启动新的Pod，争取达到副本数为3。
K8s中所有的配置都是通过API对象的spec去设置的，也就是用户通过配置系统的理想状态来改变系统，这是k8s重要设计理念之一，即所有的操作都是声明式（Declarative）的而不是命令式（Imperative）的。声明式操作在分布式系统中的好处是稳定，不怕丢操作或运行多次，例如设置副本数为3的操作运行多次也还是一个结果，而给副本数加1的操作就不是声明式的，运行多次结果就错了。
K8s有很多技术概念，同时对应很多API对象，最重要的也是最基础的是微服务Pod。Pod是在K8s集群中运行部署应用或服务的最小单元，它是可以支持多容器的。Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。Pod对多容器的支持是K8s最基础的设计理念。比如你运行一个操作系统发行版的软件仓库，一个Nginx容器用来发布软件，另一个容器专门用来从源仓库做同步，这两个容器的镜像不太可能是一个团队开发的，但是他们一块儿工作才能提供一个微服务；这种情况下，不同的团队各自开发构建自己的容器镜像，在部署的时候组合成一个微服务对外提供服务。
Pod是K8s集群中所有业务类型的基础，可以看作运行在K8s集群中的小机器人，不同类型的业务就需要不同类型的小机器人去执行。目前K8s中的业务主要可以分为长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有状态应用型（stateful application）；分别对应的小机器人控制器为Deployment、Job、DaemonSet和PetSet，本文后面会一一介绍。
RC是K8s集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个；少于指定数目，RC就会启动运行新的Pod副本；多于指定数目，RC就会杀死多余的Pod副本。即使在指定数目为1的情况下，通过RC运行Pod也比直接运行Pod更明智，因为RC也可以发挥它高可用的能力，保证永远有1个Pod在运行。RC是K8s较早期的技术概念，只适用于长期伺服型的业务类型，比如控制小机器人提供高可用的Web服务。
RS是新一代RC，提供同样的高可用能力，区别主要在于RS后来居上，能支持更多种类的匹配模式。副本集对象一般不单独使用，而是作为Deployment的理想状态参数使用。
部署表示用户对K8s集群的一次更新操作。部署是一个比RS应用模式更广的API对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际是创建一个新的RS，然后逐渐将新RS中副本数增加到理想状态，将旧RS中的副本数减小到0的复合操作；这样一个复合操作用一个RS是不太好描述的，所以用一个更通用的Deployment来描述。以K8s的发展方向，未来对所有长期伺服型的的业务的管理，都会通过Deployment来管理。
RC、RS和Deployment只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的的后端服务实例。
在K8S集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP， 集群内部通过虚拟IP访问一个服务。在K8S集群中微服务的负载均衡是通过kube-proxy实现的。kube-proxy是K8S集群内部的负载均衡器。它是一个分布式代理服务器，在K8S的每个节点上都有一个。这一特性体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的kube-proxy就越多，高可用节点也随之增多。
Job是K8S用来控制批处理型任务的API对象。批处理业务与长期伺服long-running业务的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的spec.completions策略而不同：单Pod型任务有一个Pod成功就标志完成；定数成功型任务保证有N个任务全部成功；工作队列型任务根据应用确认的全局成功而标志成功。
后台支撑型服务的核心关注点在K8S集群中的节点（物理机或虚拟机），要保证每个节点上都有一个此类Pod运行。节点可能是所有集群节点也可能是通过nodeSelector选定的一些特定节点。典型的后台支撑服务包括存储、日志、监控等，在每个节点上支持K8S集群运行的服务。
RC和RS主要是控制提供无状态服务的,其所控制的Pod的名字是随机设置的，一个Pod出故障了就被丢弃，在另一个地方重启一个新Pod， 名字变了、名字和启动在哪儿都不重要，重要的只是Pod总数;而PetSet是用来控制有状态服务，PetSet中的每个Pod的名字都是事先确定的，不能更改。PetSet中Pod的名字是用来关联与该Pod的对应状态。
K8s在1.3版本里发布了beta版的Federation功能。在云计算环境中，服务的作用距离范围从近到远一般可以有：同主机（Host，Node）、跨主机同可用区（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功能有任何变化。
K8s集群中的存储卷跟Docker的存储卷有些类似，只不过Docker的存储卷作用范围为一个容器，而K8s的存储卷的生命周期和作用范围是一个Pod。每个Pod中声明的存储卷由Pod中所有的容器共享。K8S支持非常多的存储卷类型。支持多种公有云平台的存储，包括AWS， Google， Azure云;支持多种分布式存储包括GlusterFS和Ceph;也支持较容易使用的主机本地目录hostPath和NFS.
K8s还支持使用Persistent Volume Claim即PVC这种逻辑存储，使用这种存储，使得存储的使用者可以忽略后台的实际存储技术（例如AWS，Google或GlusterFS和Ceph），而将有关存储实际技术的配置交给存储管理员通过Persistent Volume来配置。
PV和PVC使得K8s集群具备了存储的逻辑抽象能力，使得在配置Pod的逻辑里可以忽略对实际后台存储技术的配置，而把这项配置的工作交给PV的配置者，即集群的管理者。存储的PV和PVC的这种关系，跟计算的Node和Pod的关系是非常类似的；PV和Node是资源的提供者，根据集群的基础设施变化而变化，由K8s集群管理员配置；而PVC和Pod是资源的使用者，根据业务服务的需求变化而变化，有K8s集群的使用者即服务的管理员来配置。
K8S集群中的计算能力由Node提供，最初Node称为服务节点Minion, 后来改名为node。K8s集群中的Node相当于Mesos集群中的slave节点，是所有Pod运行所在的工作主机，可以是物理机也可以是虚拟机，工作主机的统一特征是上面要运行kubelet管理节点上运行的容器。
Secret是用来保存和传递密码、密钥、认证凭证这些敏感信息对象的。Secret可以避免敏感信息明文写在配置文件里。
用户帐户为人提供账户标识，而服务账户为计算机进程和K8s集群中运行的Pod提供账户标识。用户帐户和服务帐户的一个区别是作用范围；用户帐户对应的是人的身份，人的身份与服务的namespace无关，所以用户账户是跨namespace的；而服务帐户对应的是一个运行中程序的身份，与特定namespace是相关的。
namespace为k8s集群提供虚拟隔离作用，K8S集群初始有两个namespace, default和kube-system, 此外管理员可以创建新namespace以满足需求。
k8s在1.3版本中发布了基于角色的访问控制的授权模式。相对于基于属性的访问控制（Attribute-based Access Control, ABAC）, RBAC主要引入了角色Role和角色绑定RoleBinding的概念。
从K8S的系统架构、技术概念和设计理念上可以看到两个最核心的设计理念：容错性和易扩展性。容错性是保证K8S系统稳定性和安全生的基础，易扩展性是保证K8S对用户更加友好，是快速迭代增加新功能的基础。
关于“kubernetes设计理念是什么”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
