共计 6816 个字符，预计需要花费 18 分钟才能阅读完成。
这篇文章将为大家详细讲解有关 kubernetes 设计理念是什么，丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
一、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 的操作就不是声明式的，运行多次结果就错了。
1.Pod
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，本文后面会一一介绍。
2. 复制控制器（Replication Controller，RC）
RC 是 K8s 集群中最早的保证 Pod 高可用的 API 对象。通过监控运行中的 Pod 来保证集群中运行指定数目的 Pod 副本。指定的数目可以是多个也可以是 1 个；少于指定数目，RC 就会启动运行新的 Pod 副本；多于指定数目，RC 就会杀死多余的 Pod 副本。即使在指定数目为 1 的情况下，通过 RC 运行 Pod 也比直接运行 Pod 更明智，因为 RC 也可以发挥它高可用的能力，保证永远有 1 个 Pod 在运行。RC 是 K8s 较早期的技术概念，只适用于长期伺服型的业务类型，比如控制小机器人提供高可用的 Web 服务。
3. 副本集（Replica Set，RS）
RS 是新一代 RC，提供同样的高可用能力，区别主要在于 RS 后来居上，能支持更多种类的匹配模式。副本集对象一般不单独使用，而是作为 Deployment 的理想状态参数使用。
4. 部署 (Deployment)
部署表示用户对 K8s 集群的一次更新操作。部署是一个比 RS 应用模式更广的 API 对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际是创建一个新的 RS，然后逐渐将新 RS 中副本数增加到理想状态，将旧 RS 中的副本数减小到 0 的复合操作；这样一个复合操作用一个 RS 是不太好描述的，所以用一个更通用的 Deployment 来描述。以 K8s 的发展方向，未来对所有长期伺服型的的业务的管理，都会通过 Deployment 来管理。
5. 服务（Service）
RC、RS 和 Deployment 只是保证了支撑服务的微服务 Pod 的数量，但是没有解决如何访问这些服务的问题。一个 Pod 只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的 IP 启动一个新的 Pod，因此不能以确定的 IP 和端口号提供服务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的的后端服务实例。
在 K8S 集群中，客户端需要访问的服务就是 Service 对象。每个 Service 会对应一个集群内部有效的虚拟 IP， 集群内部通过虚拟 IP 访问一个服务。在 K8S 集群中微服务的负载均衡是通过 kube-proxy 实现的。kube-proxy 是 K8S 集群内部的负载均衡器。它是一个分布式代理服务器，在 K8S 的每个节点上都有一个。这一特性体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的 kube-proxy 就越多，高可用节点也随之增多。
6. 任务（Job）
Job 是 K8S 用来控制批处理型任务的 API 对象。批处理业务与长期伺服 long-running 业务的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job 管理的 Pod 根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的 spec.completions 策略而不同：单 Pod 型任务有一个 Pod 成功就标志完成；定数成功型任务保证有 N 个任务全部成功；工作队列型任务根据应用确认的全局成功而标志成功。
7. 后台支撑服务集（DaemonSet）
后台支撑型服务的核心关注点在 K8S 集群中的节点（物理机或虚拟机），要保证每个节点上都有一个此类 Pod 运行。节点可能是所有集群节点也可能是通过 nodeSelector 选定的一些特定节点。典型的后台支撑服务包括存储、日志、监控等，在每个节点上支持 K8S 集群运行的服务。
8. 有状态服务集（PetSet）
RC 和 RS 主要是控制提供无状态服务的, 其所控制的 Pod 的名字是随机设置的，一个 Pod 出故障了就被丢弃，在另一个地方重启一个新 Pod， 名字变了、名字和启动在哪儿都不重要，重要的只是 Pod 总数; 而 PetSet 是用来控制有状态服务，PetSet 中的每个 Pod 的名字都是事先确定的，不能更改。PetSet 中 Pod 的名字是用来关联与该 Pod 的对应状态。
9. 集群联邦（Federation）
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 功能有任何变化。
10. 存储卷（Volume）
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 来配置。
11. 持久存储卷（Persistent Volume，PV）和持久存储卷声明（Persistent Volume Claim，PVC）
PV 和 PVC 使得 K8s 集群具备了存储的逻辑抽象能力，使得在配置 Pod 的逻辑里可以忽略对实际后台存储技术的配置，而把这项配置的工作交给 PV 的配置者，即集群的管理者。存储的 PV 和 PVC 的这种关系，跟计算的 Node 和 Pod 的关系是非常类似的；PV 和 Node 是资源的提供者，根据集群的基础设施变化而变化，由 K8s 集群管理员配置；而 PVC 和 Pod 是资源的使用者，根据业务服务的需求变化而变化，有 K8s 集群的使用者即服务的管理员来配置。
12. 节点（Node）
K8S 集群中的计算能力由 Node 提供，最初 Node 称为服务节点 Minion, 后来改名为 node。K8s 集群中的 Node 相当于 Mesos 集群中的 slave 节点，是所有 Pod 运行所在的工作主机，可以是物理机也可以是虚拟机，工作主机的统一特征是上面要运行 kubelet 管理节点上运行的容器。
13. 密钥对象（Secret）
Secret 是用来保存和传递密码、密钥、认证凭证这些敏感信息对象的。Secret 可以避免敏感信息明文写在配置文件里。
14. 用户帐户（User Account）和服务帐户（Service Account）
用户帐户为人提供账户标识，而服务账户为计算机进程和 K8s 集群中运行的 Pod 提供账户标识。用户帐户和服务帐户的一个区别是作用范围；用户帐户对应的是人的身份，人的身份与服务的 namespace 无关，所以用户账户是跨 namespace 的；而服务帐户对应的是一个运行中程序的身份，与特定 namespace 是相关的。
15. 名字空间（Namespace）
namespace 为 k8s 集群提供虚拟隔离作用，K8S 集群初始有两个 namespace, default 和 kube-system, 此外管理员可以创建新 namespace 以满足需求。
16.RBAC 访问授权（Role-based Access Control, RBAC）
k8s 在 1.3 版本中发布了基于角色的访问控制的授权模式。相对于基于属性的访问控制（Attribute-based Access Control, ABAC）, RBAC 主要引入了角色 Role 和角色绑定 RoleBinding 的概念。
17.Conclusion 总结
从 K8S 的系统架构、技术概念和设计理念上可以看到两个最核心的设计理念：容错性和易扩展性。容错性是保证 K8S 系统稳定性和安全生的基础，易扩展性是保证 K8S 对用户更加友好，是快速迭代增加新功能的基础。
关于“kubernetes 设计理念是什么”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
