# 项目说明
### YAMLFormatspecification  项目 K8S yaml 参数说明

### containerd K8S 容器运行时部署 ansible 模式部署

### dockerfile 一些常见的dockerfile 文件

### ipv4andipv6 K8S 双栈部署脚本 生成ansible 可部署脚本

### k8s-kernel-sysctl K8S 宿主机相关优化

### k8s-yaml K8S 一些常规yaml
 
### kata-containers kata-containers ansible 部署脚本

### podsecuritypolicy K8S 开启 psp 部署脚本

### k8s-install.sh 一键自动ansible 部署 K8S 集群支持1.15及以上的版本

### kubens 命名空间切换脚本

### 其它shell 文件根据版本生成ansible 可部署脚本

> API设计原则
对于云计算系统，系统API实际上处于系统设计的统领地位。Kubernetes集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的API对象，支持对该功能的管理操作。理解掌握的API，就好比抓住了K8s系统的牛鼻子。Kubernetes系统API的设计有以下几条原则：
所有API应该是声明式的。声明式的操作，相对于命令式操作，对于重复操作的效果是稳定的，这对于容易出现数据丢失或重复的分布式环境来说是很重要的。另外，声明式操作更容易被用户使用，可以使系统向用户隐藏实现的细节，同时也保留了系统未来持续优化的可能性。此外，声明式的API还隐含了所有的API对象都是名词性质的，例如Service、Volume这些API都是名词，这些名词描述了用户所期望得到的一个目标对象。 
API对象是彼此互补而且可组合的。这实际上鼓励API对象尽量实现面向对象设计时的要求，即“高内聚，松耦合”，对业务相关的概念有一个合适的分解，提高分解出来的对象的可重用性。 
高层API以操作意图为基础设计。如何能够设计好API，跟如何能用面向对象的方法设计好应用系统有相通的地方，高层设计一定是从业务出发，而不是过早的从技术实现出发。因此，针对Kubernetes的高层API设计，一定是以K8s的业务为基础出发，也就是以系统调度管理容器的操作意图为基础设计。 
低层API根据高层API的控制需要设计。设计实现低层API的目的，是为了被高层API使用，考虑减少冗余、提高重用性的目的，低层API的设计也要以需求为基础，要尽量抵抗受技术实现影响的诱惑。 
尽量避免简单封装，不要有在外部API无法显式知道的内部隐藏的机制。简单的封装，实际没有提供新的功能，反而增加了对所封装API的依赖性。内部隐藏的机制也是非常不利于系统维护的设计方式，例如StatefulSet和ReplicaSet，本来就是两种Pod集合，那么Kubernetes就用不同API对象来定义它们，而不会说只用同一个ReplicaSet，内部通过特殊的算法再来区分这个ReplicaSet是有状态的还是无状态。 
API操作复杂度与对象数量成正比。这一条主要是从系统性能角度考虑，要保证整个系统随着系统规模的扩大，性能不会迅速变慢到无法使用，那么最低的限定就是API的操作复杂度不能超过O(N)，N是对象的数量，否则系统就不具备水平伸缩性了。 
API对象状态不能依赖于网络连接状态。由于众所周知，在分布式环境下，网络连接断开是经常发生的事情，因此要保证API对象状态能应对网络的不稳定，API对象的状态就不能依赖于网络连接状态。 
尽量避免让操作机制依赖于全局状态，因为在分布式系统中要保证全局状态的同步是非常困难的。

> Kubernetes系统API的设原则

> 所有API应该是声明式的
API对象是彼此互补而且可组合的
高层API以操作意图为基础设计
低层API根据高层API的控制需要设计
尽量避免简单封装，不要有在外部API无法显式知道的内部隐藏的机制
API操作复杂度与对象数量成正比
API对象状态不能依赖于网络连接状态
尽量避免让操作机制依赖于全局状态，因为在分布式系统中要保证全局状态的同步是非常困难的

rangyang/ipv4-ipv6-k8s

简介

发行版

贡献者

近期动态

rangyang/ipv4-ipv6-k8s .gitee-modal { width: 500px !important; }

简介

发行版

贡献者

近期动态

搜索帮助

rangyang/ipv4-ipv6-k8s