通常有三种云服务模型：SaaS（软件即服务），PaaS（平台即服务）和IaaS（基础架构即服务）。每个都有自己的好处和差异。为了您的组织能作出最佳选择，您有必要了解SaaS，PaaS和IaaS之间的差异。
下图总结了三种模型的主要差别：
SaaS的优势
SaaS通过大大减少安装，管理和升级软件等繁琐任务所花费的时间和金钱，为员工和公司提供了许多好处。这让技术人员可以花更多时间来处理组织内更紧迫的事情和问题。
何时使用SaaS
SaaS在许多场景情中是最有利的，包括：
- 如果您是一家初创公司或小公司，需要快速启动电子商务，没有时间处理服务器问题或软件
- 适用于需要协作的短期项目
- 如果您需要不常用的应用程序，例如税务软件
- 适用于需要通过Web和移动访问的应用程序
SaaS的例子
Google Apps、Dropbox、Salesforce、Cisco WebEx、Concur和GoToMeeting等
PaaS优势
无论您的公司规模如何，使用PaaS都有很多优势：
- 使应用程序的开发和部署变得简单且经济高效
- 可扩展
- 高度可用
- 使开发人员能够创建自定义应用程序，而无需维护软件
- 大大减少了编码量
- 自动化业务策略
- 允许轻松迁移到混合模型
何时使用PaaS
在许多情况下，使用PaaS是有益的甚至是必要的。如果有多个开发人员在同一个开发项目上工作，或者必须包含其他供应商，PaaS可以为整个过程提供极大的速度和灵活性。如果您希望能够创建自己的自定义应用程序，PaaS也是有益的。云服务还可以大大降低成本，并且可以简化您在快速开发或部署应用程序时出现的一些挑战。
PaaS的例子
AWS Elastic Beanstalk、Windows Azure、Heroku、Force.com、Google App Engine，Apache Stratos，OpenShift。
IaaS的优势
选择IaaS有很多好处，例如：
- 是最灵活的云计算模型
- 轻松实现存储、网络，服务器和处理能力的自动部署
- 可以根据消耗量购买硬件
- 使客户能够完全控制其基础架构
- 可以根据需要购买资源
- 高度可扩展
何时使用IaaS
与SaaS和PaaS一样，有些特定场景使用IaaS是最好的。如果您是初创公司或小公司，IaaS是一个很好的选择，因此您不必花费时间或金钱来创建硬件和软件。有些大型组织希望完全控制其应用程序和基础架构，同时又想仅购买实际消耗或需要的硬，IaaS对他们也是有益的。对于快速发展的公司而言，IaaS可能是一个不错的选择，因为您不必在需求变化和发展时承诺使用特定的硬件或软件。如果您不确定新应用程序需要什么，这也会有所帮助，因为根据需要可以根据需要进行扩展或缩小。
IaaS的例子
DigitalOcean，Linode，Rackspace，AWS，Cisco Metapod，Microsoft Azure，Google Compute Engine（GCE）
mesos（分布式资源管理器）
Mesos是一个开源的资源管理系统，可以对集群中的资源做弹性管理。
2019年5月份左右，
Twitter 宣布抛弃 Mesos，全面转向Kubernetes
swarm和k8s的区别
目前来看，k8s目前已经成为事实上的标准。
从borg到k8s
在Docker 作为高级容器引擎快速发展的同时，Google也开始将自身在容器技术及集群方面的积累贡献出来。在Google内部，容器技术已经应用了很多年，Borg系统运行管理着成千上万的容器应用，在它的支持下，无论是谷歌搜索、Gmail还是谷歌地图，可以轻而易举地从庞大的数据中心中获取技术资源来支撑服务运行。
Borg是集群的管理器，在它的系统中，运行着众多集群，而每个集群可由成千上万的服务器联接组成，Borg每时每刻都在处理来自众多应用程序所提交的成百上千的Job, 对这些Job进行接收、调度、启动、停止、重启和监控。正如Borg论文中所说，Borg提供了3大好处:
- 隐藏资源管理和错误处理，用户仅需要关注应用的开发。
- 服务高可用、高可靠。
- 可将负载运行在由成千上万的机器联合而成的集群中。
作为Google的竞争技术优势，Borg理所当然的被视为商业秘密隐藏起来，但当Tiwtter的工程师精心打造出属于自己的Borg系统（Mesos）时， Google也审时度势地推出了来源于自身技术理论的新的开源工具。
2014年6月，谷歌云计算专家埃里克·布鲁尔（Eric Brewer）在旧金山的发布会为这款新的开源工具揭牌，它的名字Kubernetes在希腊语中意思是船长或领航员，这也恰好与它在容器集群管理中的作用吻合，即作为装载了集装箱（Container）的众多货船的指挥者，负担着全局调度和运行监控的职责。
虽然Google推出Kubernetes的目的之一是推广其周边的计算引擎（Google Compute Engine）和谷歌应用引擎（Google App Engine）。但Kubernetes的出现能让更多的互联网企业可以享受到连接众多计算机成为集群资源池的好处。
Kubernetes对计算资源进行了更高层次的抽象，通过将容器进行细致的组合，将最终的应用服务交给用户。Kubernetes在模型建立之初就考虑了容器跨机连接的要求，支持多种网络解决方案，同时在Service层次构建集群范围的SDN网络。其目的是将服务发现和负载均衡放置到容器可达的范围，这种透明的方式便利了各个服务间的通信，并为微服务架构的实践提供了平台基础。而在Pod层次上，作为Kubernetes可操作的最小对象，其特征更是对微服务架构的原生支持。
Kubernetes项目来源于Borg，可以说是集结了Borg设计思想的精华，并且吸收了Borg系统中的经验和教训。
Kubernetes作为容器集群管理工具，于2015年7月22日迭代到 v 1.0并正式对外公布，这意味着这个开源容器编排系统可以正式在生产环境使用。与此同时，谷歌联合Linux基金会及其他合作伙伴共同成立了CNCF基金会( Cloud Native Computing Foundation)，并将Kuberentes 作为首个编入CNCF管理体系的开源项目，助力容器技术生态的发展进步。Kubernetes项目凝结了Google过去十年间在生产环境的经验和教训，从Borg的多任务Alloc资源块到Kubernetes的多副本Pod，从Borg的Cell集群管理，到Kubernetes设计理念中的联邦集群，在Docker等高级引擎带动容器技术兴起和大众化的同时，为容器集群管理提供独了到见解和新思路。
k8s设计架构
Kubernetes集群包含有节点代理kubelet和Master组件(APIs, scheduler, etc)，一切都基于分布式的存储系统。下面这张图是Kubernetes的架构图。
Kubernetes节点有运行应用容器必备的服务，而这些都是受Master的控制。
每次个节点上当然都要运行Docker。Docker来负责所有具体的映像下载和容器运行。
Kubernetes主要由以下几个核心组件组成：
· etcd保存了整个集群的状态；
· apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
· controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
· scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
· kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
· Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
· kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；
除了核心组件，还有一些推荐的Add-ons：
· kube-dns负责为整个集群提供DNS服务
· Ingress Controller为服务提供外网入口
· Heapster提供资源监控
· Dashboard提供GUI
· Federation提供跨可用区的集群
· Fluentd-elasticsearch提供集群日志采集、存储与查询
分层架构
Kubernetes设计理念和功能其实就是一个类似Linux的分层架构，如下图所示
· 核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境
· 应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）
· 管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）
· 接口层：kubectl命令行工具、客户端SDK以及集群联邦
· 生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴
§ Kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等
§ Kubernetes内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等
核心概念
第一个概念：Pod
Pod 是 Kubernetes 的一个最小调度以及资源单元。用户可以通过Kubernetes 的 Pod API 生产一个 Pod，让 Kubernetes 对这个 Pod 进行调度，也就是把它放在某一个 Kubernetes 管理的节点上运行起来。一个 Pod 简单来说是对一组容器的抽象，它里面会包含一个或多个容器。
比如像下面的这幅图里面，它包含了两个容器，每个容器可以指定它所需要资源大小。比如说，一个核一个 G，或者说 0.5 个核，0.5 个 G。
当然在这个 Pod 中也可以包含一些其他所需要的资源：比如说我们所看到的 Volume 卷这个存储资源；比如说我们需要 100 个 GB 的存储或者 20GB 的另外一个存储。
在 Pod 里面，我们也可以去定义容器所需要运行的方式。比如说运行容器的 Command，以及运行容器的环境变量等等。Pod 这个抽象也给这些容器提供了一个共享的运行环境，它们会共享同一个网络环境，这些容器可以用 localhost 来进行直接的连接。而 Pod 与 Pod 之间，是互相有 isolation 隔离的。
第二个概念：Volume
Volume 就是卷的概念，它是用来管理 Kubernetes 存储的，是用来声明在 Pod 中的容器可以访问文件目录的，一个卷可以被挂载在 Pod 中一个或者多个容器的指定路径下面。
而 Volume 本身是一个抽象的概念，一个 Volume 可以去支持多种的后端的存储。比如说 Kubernetes 的 Volume 就支持了很多存储插件，它可以支持本地的存储，可以支持分布式的存储，比如说像 ceph，GlusterFS ；它也可以支持云存储，比如说阿里云上的云盘、AWS 上的云盘、Google 上的云盘等等。
第三个概念：Deployment
Deployment 是在 Pod 这个抽象上更为上层的一个抽象，它可以定义一组 Pod 的副本数目、以及这个 Pod 的版本。一般大家用 Deployment 这个抽象来做应用的真正的管理，而 Pod 是组成 Deployment 最小的单元。
Kubernetes 是通过 Controller，也就是我们刚才提到的控制器去维护 Deployment 中 Pod 的数目，它也会去帮助 Deployment 自动恢复失败的 Pod。
比如说我可以定义一个 Deployment，这个Deployment 里面需要两个 Pod，当一个 Pod 失败的时候，控制器就会监测到，它重新把 Deployment 中的 Pod 数目从一个恢复到两个，通过再去新生成一个 Pod。通过控制器，我们也会帮助完成发布的策略。比如说进行滚动升级，进行重新生成的升级，或者进行版本的回滚。
第四个概念：Service
Service 提供了一个或者多个 Pod 实例的稳定访问地址。
比如在上面的例子中，我们看到：一个 Deployment 可能有两个甚至更多个完全相同的 Pod。对于一个外部的用户来讲，访问哪个 Pod 其实都是一样的，所以它希望做一次负载均衡，在做负载均衡的同时，我只想访问某一个固定的 VIP，也就是 Virtual IP 地址，而不希望得知每一个具体的 Pod 的 IP 地址。
我们刚才提到，这个 pod 本身可能 terminal go（终止），如果一个 Pod 失败了，可能会换成另外一个新的。
对一个外部用户来讲，提供了多个具体的 Pod 地址，这个用户要不停地去更新 Pod 地址，当这个 Pod 再失败重启之后，我们希望有一个抽象，把所有 Pod 的访问能力抽象成一个第三方的一个 IP 地址，实现这个的 Kubernetes 的抽象就叫 Service。
实现 Service 有多种方式，Kubernetes 支持 Cluster IP，上面我们讲过的 kuber-proxy 的组网，它也支持 nodePort、 LoadBalancer 等其他的一些访问的能力。
第五个概念：Namespace
Namespace 是用来做一个集群内部的逻辑隔离的，它包括鉴权、资源管理等。Kubernetes 的每个资源，比如刚才讲的 Pod、Deployment、Service都属于一个 Namespace，同一个 Namespace 中的资源需要命名的唯一性，不同的 Namespace 中的资源可以重名。
Namespace 一个用例，我们内部会有很多个 business units，在每一个 business units 之间，希望有一个视图上的隔离，并且在鉴权上也不一样，在cuda 上面也不一样，我们就会用 Namespace 来去给每一个 BU 提供一个他所看到的这么一个看到的隔离的机制。
Kubernetes 的 API
下面我们介绍一下 Kubernetes 的 API 的基础知识。从 high-level 上看，Kubernetes API 是由 HTTP+JSON 组成的：用户访问的方式是 HTTP，访问的 API 中 content 的内容是JSON 格式的。
Kubernetes 的 kubectl 也就是 command tool，Kubernetes UI，或者有时候用 curl，直接与 Kubernetes 进行沟通，都是使用 HTTP + JSON 这种形式。
下面有个例子：比如说，对于这个 Pod 类型的资源，它的 HTTP访问的路径，就是 API，然后是 apiVesion: V1,之后是相应的 Namespaces，以及 Pods 资源，最终是 Podname，也就是 Pod 的名字。
如果我们去提交一个 Pod，或者 get 一个 Pod 的时候，它的 content 内容都是用 JSON 或者是 YAML 表达的。上图中有个 yaml 的例子，在这个 yaml file 中，对 Pod 资源的描述也分为几个部分。
第一个部分，一般来讲会是 API 的 version。比如在这个例子中是 V1，它也会描述我在操作哪个资源；比如说我的 kind 如果是 pod，在 Metadata 中，就写上这个 Pod 的名字；比如说 nginx，我们也会给它打一些 label，我们等下会讲到 label 的概念。在 Metadata 中，有时候也会去写 annotation，也就是对资源的额外的一些用户层次的描述。
比较重要的一个部分叫做 Spec，Spec 也就是我们希望 Pod 达到的一个预期的状态。比如说它内部需要有哪些 container 被运行；比如说这里面有一个 nginx 的 container，它的 image 是什么？它暴露的 port 是什么？
当我们从 Kubernetes API 中去获取这个资源的时候，一般来讲在 Spec 下面会有一个项目叫 status，它表达了这个资源当前的状态；比如说一个 Pod 的状态可能是正在被调度、或者是已经 running、或者是已经被terminates，就是被执行完毕了。
刚刚在 API 之中，我们讲了一个比较有意思的 metadata 叫做“label”，这个 label 可以是一组 KeyValuePair。
比如下图的第一个 pod 中，label 就可能是一个 color 等于 red，即它的颜色是红颜色。当然你也可以加其他 label，比如说 size: big 就是大小，定义为大的，它可以是一组 label。
这些 label 是可以被 selector，也就是选择器所查询的。这个能力实际上跟我们的 sql 类型的 select 语句是非常相似的，比如下图中的三个 Pod 资源中，我们就可以进行 select。name color 等于 red，就是它的颜色是红色的，我们也可以看到，只有两个被选中了，因为只有他们的 label 是红色的，另外一个 label 中写的 color 等于 yellow，也就是它的颜色是黄色，是不会被选中的。
通过 label，kubernetes 的 API 层就可以对这些资源进行一个筛选，那这些筛选也是 kubernetes 对资源的集合所表达默认的一种方式。
例如说，我们刚刚介绍的 Deployment，它可能是代表一组的Pod，它是一组 Pod 的抽象，一组 Pod 就是通过 label selector 来表达的。当然我们刚才讲到说 service 对应的一组 Pod，就是一个 service 要对应一个或者多个的 Pod，来对它们进行统一的访问，这个描述也是通过 label selector 来进行 select 选取的一组 Pod。
所以可以看到 label 是一个非常核心的 kubernetesAPI 的概念，我们在接下来的课程中也会着重地去讲解和介绍 label 这个概念，以及如何更好地去使用它。
helm
helm是k8s的另外一个项目,相当于linux的yum,在yum仓库中,yum不光要解决包之间的依赖关系,还要提供具体的程序包,helm仓库里面只有配置清单文件,而没有镜像,镜像还是由镜像仓库来提供,比如hub.docker.com、私有仓库.
helm提供了一个应用所需要的所有清单文件.比如对于一个nginx,我们需要一个deployment的清单文件、一个service的清单文件、一个hpa的清单文件,把这三个文件打包到一起,就是一个应用程序的程序包,称之为Chart.
Chart是一个helm程序包,其实质只是一个模板,我们可以对这个模板进行赋值(value),形成我们自定义的清单文件,也就实现我们生产个性化的需求,这样的仓库叫Chart仓库,一个https/http服务器.
Helm把Kubernetes资源打包到一个chart中,而chart被保存到chart仓库,通过chart仓库可用来存储和分享chart.helm工作在k8s集群之外,helm不直接操作apiserver,而是和Tiller交互,Tlller再和apiserver交互,最后由Apiserver把chart使用config赋值,最后部署成为release.helm是tiller的客户端,管理本地的chart仓库,作用:发送chart、实例安装、查询、卸载等.
helm先去检查chart是否存在,如果存在就把chart下载到helm本机当前用户的家目录下,然后helm把Chart和Config交给tiller,tiller和api server交互,api server把chart部署在k8s集群上,就不再叫chart了,而叫release;一个chart赋值不同,完全可以部署出多个release出来,所以可以把chart看做是一个安装包的模板,如果发现chart更新了,helm会自动滚动更新,还支持一键回滚的操作.
helm默认使用的charts源地址是https://kubernetes-charts.storage.googleapis.com,需要替换为阿里的helm源:
helm常用命令
关注公众号 soft张三丰
