Kubernetes设计的原则是什么

本篇内容介绍了“Kubernetes设计的原则是什么”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

引言：

• 用户：提供一系列的指令来驱动系统达到制定状态。

• 系统：执行指令

• 用户：监控系统，根据系统状态，提供进一步的指令

• 用户：定义期望的状态

• 系统：向着指定的状态工作

下图是一个声明式API的例子：

用户创建一个API对象

所用的组件并行工作来达到该状态。

声明式的API支持自动恢复。例如：

系统自主地把Pod移动到健康的节点A上

• 主节点：提供一系列的指令来驱动节点达到制定状态。

• 节点：执行主节点发来的指令

• 主节点：监控每一个节点，根据节点状态，提供进一步的指令

• 主节点：定义想要达到的状态

• 节点：独立工作以达到主节点定义的状态

Scheduler通过API观察到Pod A的定义，通过调度运算，决定要在Node B上创建Pod A，并通过API更新主节点上的Pod A的定义。

• 应用程序必须被修改为知道K8s的存在，调用KubeAPI

• 应用程序可以从环境变量加载配置文件或者密匙文件，所以不需要修改

我们可以举一个例子，是关于远程存储的。

如上图所示，Pod可以直接引用一个远程的存储卷（GCE PD，AWS EBS，NFS等），kubernetes会自动使得该卷被用于Pod。但是这样做的话，有一个问题，如果你要迁移到一个新的基础架构上，那么它就不工作了。于是这就引入了kubernetes设计的第四个原则：

持久卷（PersistentVolumn，PV）和持久卷声明（PersistenVolumnClaim， PVC）就是这样一个例子。

如上图所示，通过PVC的抽象，用户Pod并不直接引用GCE PD或者EBS，这样就使得该Pod可以在不同的基础架构中互相迁移，做到可移植。就像操作系统一样，该设计使得系统应用和底层的硬件或者架构实现分离解耦。

1. Kubernetes APIs 是声明性的而非命令性的

2. Kubernetes控制平面是透明的，没有隐藏的内部API

3. 满足用户的需求

4. 可移植的工作负载

• 对象要对自己负责。在设计对象的时候，对象应该尽可能的封装内部的状态，对自己负责，我们设计一辆可行驶的车。一种设计是两个对象，driver和car，然后diver.run(car)。而更好的设计是 不需要driver，或者把dirver看成Car的一个属性，这样就是Car.run()。第二种设计更符合面向对象的设计原则。这正是声明式API背后的原则，组件对自己负责

• Kube API类似对象的接口，对象对修改封闭，对扩展开放。通过开放的API，用户可以很容易的实现功能扩展，但是你无法修改已有的组件，你可以开发自定义的组件来替换已有的组件

• 可移植性的设计利用了类似面向对象的多态，同多定义抽象接口PVC，隐藏具体的实现细节。

“Kubernetes设计的原则是什么”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注编程网网站，小编将为大家输出更多高质量的实用文章！