参考链接：
https://blog.csdn.net/zkkzpp258/article/details/86541362
https://blog.csdn.net/Bubbler_726/article/details/85596418
https://blog.csdn.net/wx_15323880413/article/details/100516698
比如：
区别：
请设想你是一个餐饮业者，打算做披萨生意。
方案1：IaaS：
他人提供厨房、炉子、煤气，你使用这些基础设施，来烤你的披萨。
IaaS 是云服务的最底层，主要提供一些基础资源。它与 PaaS 的区别是，用户需要自己控制底层，实现基础设施的使用逻辑。
方案2：PaaS
除了基础设施，他人还提供披萨饼皮。
你只要把自己的配料洒在饼皮上，让他帮你烤出来就行了。也就是说，你要做的就是设计披萨的味道（海鲜披萨或者鸡肉披萨），他人提供平台服务，让你把自己的设计实现。
PaaS 提供软件部署平台（runtime），抽象掉了硬件和操作系统细节，可以无缝地扩展（scaling）。开发者只需要关注自己的业务逻辑，不需要关注底层。
方案3：SaaS
他人直接做好了披萨，不用你的介入，到手的就是一个成品。你要做的就是把它卖出去，最多再包装一下，印上你自己的 Logo。
SaaS 是软件的开发、管理、部署都交给第三方，不需要关心技术问题，可以拿来即用。
所以，对于自己的工作量(下图蓝色)：IaaS>PaaS>SaaS
公有云：
什么是公有云呢？设想一个场面，如果你制作了一个网站（代理+应用服务器+数据库），一般来说，都是只可以在本机装个tomcat,mysql等等进行调试，你使用的ip就是localhost，这种Web，一般称之为单机的服务。如果你想让别人也访问你的网页，当然是要把机器接入到Internet上。但是目前你完全不具备购买一台Web服务器的能力，这时候怎么办呢？没关系，你可以购买一台虚拟的云服务器。这台云服务器本身已经具备了一个公网的ip，如果你把服务部署在这台服务器上，那么它的localhost就是这个公网的ip了，你和你的朋友可以在随时随地访问了。因此，公有云的概念简单理解就是申请一台接入Internet的云主机，你可以对其随便搞（装系统、装应用、开关机），你只需要购买一个使用的类似租赁的费用，而并不需要购买它。
这里，你申请的“机器”，可能是一台虚拟机，也可能是一些容器，对于这些容器，一般称它们为“实例”。当代的互联网公司，在进行服务部署的时候，往往会选择部署实例而非虚拟机，至于为什么，可以参考虚拟机和容器的区别的文章。选用实例，是因为实例的部署是秒级的（虚拟机是分钟级别的），而且实例是APP层面的封装，更小更轻便，是对硬件的更有效地利用。
私有云：
私有云是为了解决安全问题的一种云计算方案。虽然公有云很方便，但是毕竟是把数据和资源都交给其它人了，这对于企业管理来说，是一个很大的隐患。毕竟，很多数据是无价的，很多企业把用户数据作为他们的灵魂支柱。因此，当今的企业常常不希望把数据和资源部署到公有云上，他们往往会自己出资搭建机房，这时的解决方案，就是私有云方案。私有云比起公有云，更加安全，但是，成本也更高。
混合云：
混合云是在成本和安全方面的一种折中方案。顾名思义，就是公有云和私有云的结合。数据依然是存到本地的机器上，但是一旦出现大规模的访问或者计算时，就会把这部分计算的需求转移到公有云平台上，实现不同场景的切换。与此同时，在混合云方案中，私有云还常常把公有云作为灾难恢复和灾难转移的平台。混合云在使用起来具有更高的灵活性，是企业在考虑成本效益下的首选方案。
如前文所述，混合云客户一般已经具备了私有云，希望通过对接公有云解决几方面的典型需求：
跨国：某大型公司在美国销售电子类产品，需要在美国连接该企业的销售系统，通过本地私有云加AWS公有云实现；
灾备：将一部分系统或者数据定期备份到公有云上；
性能和高可用：利用公有云的CDN、全局负载均衡等能力提供更好可用性和性能；
爆发：客户业务需要短时爆发（bursting），满足业务需求同时节省成本。
混合云供应商主要包含：公有云提供商提供混合云能力、私有云供应商提供混合云能力、混合云创新企业等。
MESOS Apache下的分布式资源管理框架 在2019.5，最大使用者Twitter放弃MESOS，转型Kubernetes。
Docker Swarm Docker母公司为Docker开发的分布式资源管理框架 在2019.7，阿里云宣布，将Docker Swarm从阿里云的选择列表中剔除。
Kubernetes Google公司 10年容器化基础架构 采用Go语言对自己的borg系统进程翻写 ----> Kubernetes
K8S官网： https://kubernetes.io/zh-cn/docs/home/
K8S是Kubernetes的全称，源于希腊语，意为“舵手”或“飞行员”，官方称其是： 用于自动部署、扩展和管理“容器化(containerized) 应用程序”的开源系统。
总结来说： K8S是负责自动化运维管理多个Docker程序的集群
核心特性：
K8S是属于主从设备模型(Master-Slave架构)，即有Master节点负责核心的调度、管理和运维，Slave节点则执行用户的程序。但是在K8S中，主节点一般被称为Master Node 或者 Head Node，而从节点则被称为Worker Node 或者 Node
注意： Master Node和Worker Node是分别安装了K8S的 Master和Worker组件的实体服务器，每个Node都对应了一台实体服务器（虽然Master Node可以和其中一个Worker Node安装在同一台服务器，但是建议Master Node单独部署），所有Master Node和Worker Node组成了K8S集群，同一个集群可能存在多个Master Node和Worker Node。
例如：我们在master节点执行命令，要master部署一个nignx应用
kubectl create deployment nginx --image=nginx
Kubernetes有很多核心概念，我们先看下几个核心的概念。
Deployment负责创建和更新应用程序的实例。 创建Deployment后，Kubernetes Master 将应用程序实例调度到集群中的各个节点上。如果托管实例的节点关闭或被删除，Deployment控制器会将该实例替换为群集中另一个节点上的实例。这提供了一种自我修复机制来解决机器故障维护问题。
Pod相当于逻辑主机的概念，负责托管应用实例。包括一个或多个应用程序容器（如 Docker），以及这些容器的一些共享资源（共享存储、网络、运行信息等）。
Service是一个抽象层，它定义了一组Pod的逻辑集，并为这些Pod支持外部流量暴露、负载均衡和服务发现。
尽管每个Pod 都有一个唯一的IP地址，但是如果没有Service，这些IP不会暴露在群集外部。Service允许您的应用程序接收流量。Service也可以用在ServiceSpec标记type的方式暴露，type类型如下：
k8s中所有的内容都抽象为资源， 资源实例化之后，叫做对象，上面说的那些核心概念都是k8s中的资源。
k8s中有哪些资源:
以上这些资源都是配置在名称空间级别
Kubernetes 的网络模型假定了所有Pod都在一个可以直接连接的扁平的网络空间中，这在GCE（Google Compute Engine）里是现成的网络模型。Kubernetes 假定这个网络已经存在。而在私有云里搭建Kubernetes 集群，就不能假定这个网络已经存在了。 我们需要自己实现这个网络假设，将不同节点的Docker 容器之间的相互访问先打通，然后运行Kubernetes。
Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个网络规划服务，简单的说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟Ip地址。而且它还能在这些IP地址直接建立一个覆盖网络(Overlay Network) ，通过这个覆盖网络，将数据包原封不动地传递到目标容器内。
