物理单机→虚拟机虚拟化→容器虚拟化→云原生模式

这一演化观察出的规律：

新模式对需求变化的反应更敏捷，新模式下应用的部署与运行过程中的自动化程度应日益提升，在新模式下应用的执行应该更为有效率，以进一步提高计算资源的利用率，应用的伸缩和扩展也要更有效率，新模式下应用的部署和运行成本也应实时降低，开发人员应更聚焦于应用本身，更关系的是应用的设计和实现。

上图总结了应用部署运行模式变迁的过程：

物理单机时代：我们使用的所谓平台其实是操作系统；

传统基于虚拟机虚拟化的时代：平台指的是云操作系统，主流的是OpenStack；

容器虚拟化时代：局限于单体容器时期，并未出现平台的概念，直到云原生概念的提出。

元原生模式：Kubernetes成为了平台的标准，可以理解为新一代云平台，应用上云的主流之选。可以看出Kubernetes在云原生模式下的地位和角色的重要性了，相对于应用，它好比单机时代的操作系统，好比虚拟机时代的OpenStack。

CNCF，Kubernetes：2015年

2015年云原生计算组织CNCF成立，该组织旨在利用专家经验精心选择应用上云的解决方案和相关组件，包括容器管理编排调度引擎，分布式应用的网络存储、监控、跟踪、日志跟踪组件、微服务间的交互协议、微服务的服务治理、服务网格等，CNCF的成立为推动应用上云安全地采用云原生模式提供了更稳、更快、更安全的解决方案，其核心是Kubernetes。

CNCF的各个组件项目也都无缝适配Kubernetes，并围绕Kubernetes打造新功能并继续演进。

Kubernetes在2015年7月发布了1.0版本，经过2年多的开发和生态圈打造，终于在2017年战胜了两个强劲的对手成为了在容器调度编排的首选平台，为云原生模式下部署、运行和管理，提供了可移植的、云厂商无关的事实标准。

云原生：初期（2015-至今）

容器技术的出现让应用上云在传统的虚拟机之外又多了一种选择，但光有容器还不够，单纯的将应用从单机或虚拟机挪到容器中，并不能完全体现出容器的优势，给开发者带来的帮助也不大。

云原生模式

随着时代的发展和进步，应用所面临的外部环境也在变化，市场需求的需求变化要求应用给与足够快的响应速度，快速更新并部署上线，并且保持线上业务的平滑升级过度，同时还能在业务的峰谷之间自行伸缩适应，这些状况让越来越多的开发者不仅选择使用容器作为应用部署运行的载体，还积极采用了与容器这个应用载体天生匹配的微服务的架构，并依靠流程编排引擎帮助保持对外部响应的敏捷性，这种容器化的微服务结构需要结合容器管理调度编排引擎进行动态编排和资源占用优化的应用被赋予了一个新的名词叫云原生应用。云原生逐渐成为了一种应用云化开发、部署和运行的主流方式。

从上面的诠释也可以看出，云原生模式的基础前提是应用都是容器化的，结构上都是微服务化的，容器作为应用部署、运行和管理的基本单元。

而云原生模式的核心是需要借助容器管理编排调度平台对容器进行动态编排和资源利用优化。

云原生概念一出现便得到了广大开发者的认可，采用云原生模式实现应用上云的方案得到了快速的发展。

容器化：（2013年-至今）

随着基于虚拟机的云计算的成熟，越来越多的应用迁移到了云端，应用上云成为了一股不可逆转的趋势，但在这一过程中，我们也发现了传统虚拟机的一些不足之处。比如云服务商锁定：由于使用了某一个云服务商提供的服务，用户便难以将应用迁移到其它云服务商或者自己的私有数据中心，跨云做应用部署十分困难，虚拟机运行额外消耗过重，每个虚拟机都有一个GuestOS，导致镜像的size过大，传输不便，并且执行效率差，虚拟机的启动速度也很慢，导致扩展没有预想的那样轻量和方便。在传统虚拟化成熟的时候，另外一种虚拟化技术正在孕育发芽和崛起，它就是容器。

Dorker：2013年

2013年名不见经传的dotCloud公司发布了Docker系统，从此拉开了容器虚拟化的新时代。

以Docker为代表的内核容器技术并不是全新的技术，而是将已有技术（LXC（Linux Container）、cgroups、Union FS）进行了更好的整合和包装，提供了开发者体验良好的工具集，并形成了一种标准镜像格式。

与传统的虚拟机相比，容器技术具有许多优势，比如开发交付流程操作对象是同步的（即面对同一个容器镜像）、执行更为高效（可以实现秒级的启动）、资源占用更为集约（没有GuestOS、共享内核，镜像的大小也很小，一般在几M到几十M的级别，启动速度很快，使得扩展性良好）等优势。

容器的标准化规范几乎是同步制定的，使得容器的可移植性非常好。这些优势使得容器这种应用部署和运行模式在短短的几年间就广泛的流行应用开来。

这时在容器虚拟化技术下，计算的基本单元由虚拟机变为了容器，越来越多的应用的构建、部署与运行选择在容器中进行。

AWS、Azure、Aliyun、GCE：2015-2017

基于虚拟化技术点的公有云爆发式增长，形成公有云IaaS四巨头，亚马逊的AWS、微软的Azure、阿里的Aliyun、谷歌的GCE四大公有云提供商竞争的格局。

2017年底，全球企业的一半以上的计算资源放在了公有云上，半数企业在内部完成了私有云部署。

虚拟化：成熟期（2010~至今）

商家在尝到AWS和GCE等公有云提供的自助的按需租用的计算资源的甜头后，都在考虑将自己的数据中心改造为虚拟化平台，并以虚拟化的方式部署那些数据敏感、业务敏感的核心应用，一部分商家使用了商业的方案，比如VMWare的技术。另外一部分则寻找开源的方案。

OpenStack：2010年

2010年OpenStack开源项目生逢其时的发布，助推了这一趋势。建立在OpenStack这一云管理平台上的私有数据中心开始全面开花结果。虚拟化也逐步进入到成熟时期，同时云计算领域出现了私有云、公有云、混合云等多种应用部署形式，百花齐放的格局。

OpenStack诞生推动开源IaaS平台的快速发展。推动商家将数据中心改造为虚拟化平台，部署数据敏感、业务敏感的核心应用；

部署形式：公有云、私有云、混合云；

服务模式：IaaS、PaaS（Heroku 2009）、SaaS等

云计算领域还出现了多种服务模式，除了传统的IaaS，还有PaaS和SaaS服务。2009年HeroKu提出了平台即服务PaaS的概念，PaaS构建在IaaS之上。在基础架构之外，还提供了业务软件运行的环境，用户无需关心虚拟机的环境设置，并且一般通过一行命令即可完成应用的编译和部署，PaaS面向的用户是没有能力或者不愿意维护一个完整运行环境的开发人员或公司，通过使用PaaS服务，他能可以从繁琐的环境搭建中抽身出来，将更多的精力投入到业务软件的开发中。

软件即服务SaaS的目标是将一切业务运行的后台环境放入云端，通过一个瘦客户端，通常是web浏览器，向最终用户直接提供服务，最终用户按需向云端请求服务，而本地无需维护任何基础架构或软件运行环境，SaaS和PaaS还有一个不同点是SaaS面向的是软件最终用户而不是开发人员，PaaS和SaaS让基于虚拟化的云计算提供的服务形式更加多样性，可以满足各种人群对计算资源的不同需求。

从2010年OpenStack发布至今，基于虚拟机虚拟化技术的云计算进入了成熟期。

IaaS：AWS 2006年，GCE 2008年

基于虚拟机技术的Amazon Web Services（AWS）开启了Infrastructure-as-a-Service（基础设施即服务）的市场。

商家们发现获取计算资源不再需要购买昂贵的硬件设备了，只需在公有云AWS或者GCE上自助的按需租用以虚拟机（VM）为基本计算单元的计算资源即可。这样一来，商家的基本性支出变成了运营成本的支出，费用大幅降低。

应用的部署也多以虚拟机（VM）为单元并且结合IaaS厂商提供的控制台实现了高效的计算资源管理。硬件、存储、网络等专业性维护人员也可以省去了。与此同时，公有云的高可扩展性也使得商家在应对业务需求快速变动的情况下，可以迅速获得需要的计算、存储和网络资源。

虚拟化：初期（2001~2009）

至到20世纪初，即2001-2009年这段时间，虽然单机模式依然是主流，但一种新的模式在快速发展，那就是新出现的虚拟化模式。

提到IT行业的虚拟化概念，最早追溯到20世纪的60年代，当时虚拟化技术的研究主要用来对稀有昂贵的计算资源大型机硬件进行分区，以提高硬件的使用效率，但随着时间的推移，微型计算机和PC等廉价硬件的出现，能够提供更为有效精细的方法来对计算资源进行分配和处理，所以到20世纪80年代之后，虚拟化技术在应用方面陷入到了停滞。

VMware：2001年，Xen：2003年，KVM：2007年

虚拟化技术再次转向前台的标志性事件之一是VMware公司在2001年发布了针对服务器市场的虚拟化解决方案：其目标依旧是两个方面，其一是提高计算资源的使用效率，大型数据中心富裕的计算资源无法得到充分利用，通过拆分的方式将计算资源充足的单机划分为若干个虚拟机，以虚拟机作为基本计算资源提供给客户；其二是降低成本，虚拟化通过聚合的方式将分散的廉价的计算资源实化，廉价的搭载开放系统的高性能的计算设备，尤其是X86服务器逐步替代了昂贵的Unix小型机，在保持计算能力不降低的情况下，大幅降低了成本。

随后Xen和KVM相继在2003年和2007年发布了自己的首个虚拟化技术方案版本，从此三大解决方案VMware、Xen和KVM形成了三足鼎立之势，并且一同促进了虚拟机虚拟化技术概念的普及，拉开了虚拟化云计算时代的大幕。

在这种模式下，基础计算单元逐步变成了虚拟机，服务端应用的构建、部署和运行逐步迁移到了虚拟机上了。

同样是在这一时期，当有了虚拟化技术解决方案之后，虚拟化技术的应用也逐渐跟上，标志性的事件就是亚马逊和谷歌公司相继推出了AWS和GCE的虚拟化主机租用服务，开启了技术设施即服务的IaaS的市场。

物理单机（~2000）

2000年：IBM、Sun公司

自计算机科学诞生以来数十年间，在商用服务计算领域几乎都是以单机为基础计算单元对计算资源进行管理和协调控制的，典型的代表就是IBM和Sun公司，IBM是大型机的代表，Sun是小型机和工作站的代表。

在这个阶段你想部署和推出一个新的应用，首先必须购买或租用硬件，一台物理服务器或者服务器阵列，并招聘专门的人进行维护。

在这个阶段，应用程序是直接在物理机上构建、部署和运行的，而且大多数情况下，一台服务器上只安装和运行一种应用，成本很高，资源的利用率却不高。并且由于需要采购硬件，针对业务需求响应的周期非常的长，这种模式就好比商家要用电，需要自己购买发电机，买燃料，专人维护，成本很高，效率很低。

K8s的出现归根结底是应用部署运行模式在外界需求变化下演化变迁的结果。

与pod建立连接

Service

Service :与云原生应用中“微服务”概念——对应

Kubernetes集群为每一个Service分配一个集群唯一的IP地址，在service的生命周期内，该IP地址不变﹔在内部DNS的支持下，轻松实现服务发现机制

Service通过label selector关联到实际支撑业务运行的Pod上，并通过集群内置的服务负载均衡将服务请求分发到后端Pod

通过nodeport或设置loadbalancer机制实现集群外部对service的访问

Controllers

Controller是Kubernetes核心对象之一

Controller用于保证集群内一组Pod能始终按照某种期望的状态(desired state)正常运行

状态包括:Pod副本数量、节点选择、资源约束、持久化数据维持等

Kubernetes支持多种Controller，常用的Deployment

、replicaset、statefulset、daemonset等

ReplicaSet

ReplicaSet:确保健康Pod的副本数始终满足用户定义的数量

前身是ReplicationController(rc)

相比rc，增加集合式label selector的支持

支持单独使用，但更多隐藏在Deployment控制器后面，由deployment自动管理

Deployment

Deployment :为Pod和ReplicaSet提供了声明式的定义(declarative)

用户在deployment文件中描述期望状态，Deployment controller就会自动将Pod和Replica Set的实际状态改变到期望状态

Deployment支持Pod的RollingUpdate，并自动管理背后的ReplicaSet

Deployment支持将pod Rollback到之前的任意revision(仅限于pod-template模板改动)

StatefulSet

StatefulSet:提供对有状态的应用的部署和控制的支持，1.9版本GA

适用场景︰稳定的持久化存储、稳定的网络标志、有序部署有序扩展、有序收缩有序删除、有序自动滚动升级等

Pod的存储必须由PersistentVolume Provisioner 根据请求的Storage Class进行配置，或由管理员预先配置好。

考虑数据安全性，伸缩或删除StatefulSet不会删除关联的存储﹔另外StatefulSet目前要求Headless Service负责Pod的网络身份，用户有责任创建此服务

DaemonSet

DaemonSet:保证在每个Node上都运行一个Pod副本

适用场景∶系统Daemon程序、监控跟踪、日志收集等

Kubernetes 1.6之后，可设置更新策略:支持滚动更新

可指定Node: nodeSelector、nodeAffinity.podAffinity

ConfigMap

ConfigMap:常用来向Pod提供非敏感的配置信息

ConfigMap 用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件

ConfigMap可以使用命令行基于字面值、文件或目录来创建或通过configmap对象定义文件创建

ConfigMap可以通过三种方式在Pod中使用:环境变量、容器命令行参数或以文件形式通过数据卷插件挂载到Pod中

Secret

Secret解决的是集群内密码、token、密钥等敏感数据的配置问题

常用于与ServiceAccount关联，存储在tmpfs 文件系统中，Pod删除后Secret文件也会对应的删除

支持Opaque , kubernetes.io/Service Account , kubernetes.io/dockerconfigjson三种类型

Secret可以以Volume或者环境变量的方式使用

Pod:集群调度基本单元

Pod :一个有特定关系的容器集合

Pod是集群中可以创建和部署的最小且最简的kubernetes对象单元

Pod也是一种封装。它封装了应用容器，存储资源、独立的网络IP以及决定容器如何运行的策略选项

每个Pod中预置一个Pause容器，其名字空间、IPC资源、网络和存储资源被Pod内其他容器共享。Pod中的所有容器紧密协作，并且作为一个整体被管理、调度和运行

Pod生命周期

Pod :一个非持久性实体

Namespace(名字空间)

Namespace，不仅仅是一个属性，本身也是一个object

Namespace :用于将物理集群划分为多个虚拟集群

Namespace间完全隔离，因此也常被用来隔离不同的用户（及权限)

内置三个Namespaces: default、kube-system和kube-public,Node和PersistentVolume不属于任何namespace

Label(标签)

Label用于建立集群对象之间的灵活的、松耦合的多维关联关系

一个label是一个键-值对，其中的key、value均由用户自己定义

label可以附着在任何对象上，每个对象也可以有任意个标签。标签可在对象定义时附加上，也可以通过命令动态管理标签

Label可以将有组织目的的结构映射到集群对象上，从而形成一个与现实世界管理结构同步对应松耦合的、多维的对象管理结构

Annotations(注解)

Annotations :可以将任意非标识性元数据附加到对象上

Annotations也是以键值对形式呈现

◆工具和库可以检索到并使用这些Annotations元数据

将数据作为Annotation附着在对象上，有利于创建一些用于部署、管理和做内部检查的共享工具或客户端

Kubernetes对象

Kubernetes对象∶是一种持久化的、用于表示集群状态的实体

—种声明式的意图的记录，一般使用yaml文件描述对象

Kubernetes集群使用Kubernetes对象来表示集群的状态

通过API/kubectl管理Kubernetes对象