标签：

 Kubernetes的方针是让部署容器化的应用简单并且高效（powerful）,Kubernetes供给了应用部署，规划，更新，维护的一种机制  架构

 API设计原则

K8s集群系统每撑持一项新成果，引入一项新技术，必然会新引入对应的API东西，撑持对该成果的打点操纵，理解掌握的API，就比如抓住了K8s系统的牛鼻子

所有API应该是声明式的

API东西是相互互补而且可组合的

高层API以操纵意图为根本设计

低层API按照高层API的控制需要设计。

尽量制止简单封装，不要有在外部API无法显式知道的内部隐藏的机制。

API操纵庞大度与东西数量成正比。

API东西状态不能依赖于网络连接状态

尽量制止让操纵机制依赖于全局状态

控制机制设计原则

控制逻辑应该只依赖于当前状态

假设任何错误的可能，并做容错措置惩罚惩罚

尽量制止庞大状态机，控制逻辑不要依赖无法监控的内部状态

假设任何操纵都可能被任何操纵东西拒绝，甚至被错误解析

每个模块都可以在堕掉队自动恢复

每个模块都可以在须要时优雅地降级处事

Service

在K8s集群中，客户端需要访谒的处事就是Service东西。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访谒一个处事。

在K8s集群中微处事的负载均衡是由Kube-proxy实现的。

Kube-proxy是K8s集群内部的负载均衡器。它是一个漫衍式代办代理处事器，在K8s的每个节点上都有一个；这一设计浮现了它的伸缩性优势，需要访谒处事的节点越多，供给负载均衡能力的Kube-proxy就越多，高可用节点也随之增多。

与之对比，我们平时在处事器端做个反向代办代理做负载均衡，还要进一步解决反向代办代理的负载均衡和高可用问题

 Pod

Pod的设计理念是撑持多个容器在一个Pod中共享网络地点和文件系统，可以通过进程间通信和文件共享这种简单高效的方法组合完成处事

PetSet

在云原生应用的体系里，有下面两组近义词

第一组是无状态（stateless）、牲畜（cattle）、无名（nameless）、可抛弃（disposable）

第二组是有状态（stateful）、宠物（pet）、有名（having name）、不成抛弃（non-disposable）

对付RC和RS中的Pod，一般不挂载存储或者挂载共享存储，如何破解qq空间访问权限2017 ，生存的是所有Pod共享的状态，Pod像牲畜一样没有分袂（这似乎也确实意味着掉去了人性特征）；对付PetSet中的Pod，每个Pod挂载本身独立的存储，如果一个Pod呈现故障，从其他节点启动一个同样名字的Pod，要挂载上本来Pod的存储继续以它的状态供给处事

适合于PetSet的业务包孕数据库处事MySQL和PostgreSQL，集群化打点处事Zookeeper、etcd等有状态处事。

PetSet的另一种范例应用场景是作为一种比普通容器更不变可靠的模拟虚拟机的机制。

传统的虚拟机正是一种有状态的宠物，运维人员需要不停地维护它，容器刚开始风行时，我们用容器来模拟虚拟机使用，所有状态都生存在容器里，而这已被证明长短常不安适、不成靠的。使用PetSet，Pod仍然可以通过漂移到差别节点供给高可用，而存储也可以通过外挂的存储来供给高可靠性，PetSet做的只是将确定的Pod与确定的存储关联起来保证状态的持续性

初探kubernetes--什么是kubernetes

标签：

原文地点：https://www.cnblogs.com/YC-L/p/12568527.html