我们先从云计算说起。在云计算普及之前，一个应用想要发布到互联网，就需要企业自己先买几台服务器，找一个IDC机房，租几个机架，把服务器放进去。接下来就是装Linux系统，部署应用。我们就假定用Java写了Web应用，怎么部署上去呢？先配置Tomcat服务器，在把编译好的war包上传到服务器，有用FTP的，安全意识高一点的会选SCP，然后配置Nginx、MySQL这些服务，最后一通调试，把应用跑起来，就算齐活。
这种物理机配合自搭网络环境、自搭Linux、自配环境的方式，有很多缺点，但最主要的问题有这么几个：
- 扩容和维护难，因为是物理机，需要先采购后跑机房，遇到双十一业务量猛增是来不及扩容的，用行话讲就是计算资源缺乏弹性；
- 安全性太差，熟悉Linux的运维工程师本来就少，精通SELinux的更是凤毛麟角，而且，系统安全性仅仅是一个方面，应用部署的权限、流程造成的安全漏洞更大；
- 部署流程不规范，开发、测试和运维脱节，缺少自动化测试和部署，无法快速迭代业务。
解决方案是上云。上云不能解决所有问题，但部分解决了前两个问题：
- 云服务商提供的是虚拟机，比起物理机，虚拟机的创建、维护、销毁比物理机简单了太多，且随时可以扩容，很大程度上解决了“弹性计算”的问题，至于弹性程度有多大，还得看应用的架构和设计水平；
- 和绝大多数中小企业相比，云服务商在网络和服务器安全方面要强若干个数量级。只要选择合适的官方镜像，配合防火墙规则，系统级别的安全问题大大减少，可以将重点放到应用本身的安全性上。
但是如果仅仅满足上云，把物理机换成虚拟机，把物理网换成虚拟专用网（VPC），是远远不够的。这些是计算资源和网络资源层面的简化。应用方面，如果延续旧的一套开发、测试、部署流程，做不到快速迭代。
要做到快速迭代，敏捷开发，就需要DevOps，即开发运维由一个团队负责，开发阶段，就要把部署、运维的工作考虑进去，而不是发布一个war包或者jar包后扔给运维不管了。
重开发、轻部署，直接后果就是缺少自动化发布流程。想要把部署规范化，就需要整体考虑一系列问题。
还是以Java应用为例，如果是手动部署，那么就上传war包到服务器，覆盖原有的版本，重启Tomcat，再测试。如果发现有严重问题要回滚怎么办？把老版本再传一遍，然后重启Tomcat。
手动部署，每次部署都是一次生死考验，所以最好不要安排在半夜，以免手抖敲错了命令，本来中断10分钟的服务，变成了灾备恢复，中断3天。
稍微靠谱一点的是写脚本部署，但各家写出来的脚本都有各家特色，不通用，不易维护，所以更好的方式是用成熟的部署方案，比如Ansible，把脚本标准化，比如做成蓝绿发布，把服务器分组，比如A、B两组，先把流量切到B组，升级A组服务器，有问题就回滚，没问题了，再把流量切到A组，升级B组服务器，最后，恢复正常流量，整个部署完成。
但是回滚这个事情，远没有那么简单。做过开发的同学都知道，升级新版本，一般要加配置，改配置，如果回滚到旧版本，忘了把配置改回去，那旧版本可能也不能正常工作。
上云，除了物理变虚拟，简化运维外，最重要的特点——弹性计算，一定要充分利用。
理论指导实践，实践完善理论。如果我们分析大多数基于互联网的应用，可以看到，一个应用，通常用到的资源如下：
- 存储资源，通常对应着一个或多个数据库，例如MySQL、Oracle、PostgreSQL等；
- 计算资源，以Java应用为例，就是一个或多个Web应用，跑在Tomcat，或者通过SpringBoot自带嵌入式服务器；
- 网关，通常是Nginx之类的服务器，对外作为统一的服务入口，对内提供反向代理；
- 其他支撑业务的组件，例如，为提升应用性能采用的Redis集群作为缓存，应用内部各组件通信使用的消息系统如Kafka等，以及随着业务不断扩大增加的ES集群、日志分析和处理的集群等。
上云后，云服务商通常都提供托管的数据库，以及大规模存储系统（S3），可解决存储资源问题。通过云服务商提供的负载均衡（Load Balancer），也无需自行部署Nginx等网关，免去了运维的问题。各种标准的业务组件如Redis、Kafka等，均可直接租用云服务商提供的资源。
我们重点讨论计算资源，也就是云上的虚拟机资源。对于应用来说，可以设计成有状态和无状态两种。一个应用在一台虚拟机内跑着，如果有本地文件的修改，它就是有状态的。有状态的应用既不利于扩展，也不利于部署。反过来，如果一个应用在运行期数据总是存在数据库或者缓存集群，本地文件无任何修改，它就是无状态的。
无状态的应用对应的虚拟机实际上就是不变的计算资源。这里的“不变”非常重要，它是指，一台虚拟机通过一个固定的镜像（预先内置好必要的支持环境，如JRE等）启动后，部署一个应用（对应一个war包或者jar包），该虚拟机状态就不再变化了，直接运行到销毁。
有的同学会问：如果给这台虚拟机重新部署一个新的应用版本，它的状态不就发生了变化？
确实如此。为了确保虚拟机的不变性，一旦启动后部署了某个版本，就不允许再重新部署。这样一来，对虚拟机这种计算资源来说，就具有了不变性。不变性意味着某个虚拟机上的应用版本是确定的，与之打包的配置文件是确定的，不存在今天是版本1，明天变成版本2，后天回滚到版本1的情况。
计算资源不变，能确保启动一台虚拟机，对应发布的应用版本和配置是确定的且不变的，对于运维、排错非常重要。
那么如何在保持计算资源不变的前提下发布新版本？
我们以AWS的CodeDeploy服务为例，假设一组正在运行的某应用v1集群包含3台虚拟机：
┌─────────────────────────────────────┐
│ VPC │
│ ┌────────────────────────┐│
│ │ Target Group ││
┌──┴──┐ │┌──────┐┌──────┐┌──────┐││
│ ELB │───────▶││EC2:v1││EC2:v1││EC2:v1│││
└──┬──┘ │└──────┘└──────┘└──────┘││
│ └────────────────────────┘│
└─────────────────────────────────────┘
现在，我们要把应用从v1升级到v2，绝不能直接把现有的3台虚拟机的应用直接升级，而是由CodeDeploy服务启动3台新的一模一样的虚拟机，只是部署的应用是v2。现在，一共有6台虚拟机，其中3台运行v1版本，另外3台运行v2版本，但此刻负载均衡控制的网络流量仍然导向v1集群，用户感受不到任何变化：
┌─────────────────────────────────────┐
│ VPC │
│ ┌────────────────────────┐│
│ │ Target Group ││
┌──┴──┐ │┌──────┐┌──────┐┌──────┐││
│ ELB │───────▶││EC2:v1││EC2:v1││EC2:v1│││
└──┬──┘ │└──────┘└──────┘└──────┘││
│ └────────────────────────┘│
│ ┌────────────────────────┐│
│ │ Target Group ││
│ │┌──────┐┌──────┐┌──────┐││
│ ││EC2:v2││EC2:v2││EC2:v2│││
│ │└──────┘└──────┘└──────┘││
│ └────────────────────────┘│
└─────────────────────────────────────┘
v2集群部署成功后，做一些自动化冒烟测试和内网测试，如果有问题，直接销毁，相当于本次部署失败，但无需回滚。如果没有问题，通过负载均衡把流量从v1集群切到v2，用户可无感知地直接访问v2版本：
┌─────────────────────────────────────┐
│ VPC │
│ ┌────────────────────────┐│
│ │ Target Group ││
┌──┴──┐ │┌──────┐┌──────┐┌──────┐││
│ ELB │───┐ ││EC2:v1││EC2:v1││EC2:v1│││
└──┬──┘ │ │└──────┘└──────┘└──────┘││
│ │ └────────────────────────┘│
│ │ ┌────────────────────────┐│
│ │ │ Target Group ││
│ │ │┌──────┐┌──────┐┌──────┐││
│ └───▶││EC2:v2││EC2:v2││EC2:v2│││
│ │└──────┘└──────┘└──────┘││
│ └────────────────────────┘│
└─────────────────────────────────────┘
稳定一段时间（例如15分钟）后，销毁v1集群。至此，整个升级完成。
上述的蓝绿部署就是CodeDeploy的一种标准部署流程。CodeDeploy也支持灰度发布，适用于更大规模的应用。
把计算资源不可变应用到部署上，实际上是充分利用了弹性计算这个优势，短时间创建和销毁虚拟机，只有上云才能做到，并且针对云计算，把部署流程变得更加简单可靠，每天发几个版本甚至几十、几百个版本都变得可能，DevOps能落地，有点“云原生”的味道了。
说到AWS的CodeDeploy，最早我使用AWS时，对于它的计费采用Reserved Instance预付模型感到很不理解，租用一台虚拟机，按国内阿里云、腾讯云包年包月预付享折扣不是更直观吗？如果仅仅把上云变成租用虚拟机，那就完全丧失了弹性计算的优势，相当于租用了一台虚拟机在里面自己折腾。AWS的Reserved Instance计费并不绑定某一台虚拟机，而是一种规格的虚拟机。我们还是举例说明，如果我们有1台2v4G规格的虚拟机，并购买了1年的Reserved Instance，那么，我随时可以销毁这台虚拟机，并重新创建一台同样规格的新的虚拟机，Reserved Instance计费会自动匹配到新的虚拟机上，这样才能实现计算资源不变，频繁实施蓝绿部署，真正把部署变成一种云服务。最近阿里云终于推出了节省计划的付费模式，有点真正的云计算的付费味道了，但是腾讯云、华为云还停留在包年包月和按量付费这两种原始租赁模型。
讲了这么多自动化部署，实际上一个指导思想就是如何充分利用云的弹性计算资源。从充分利用云的弹性资源为出发点，设计一整套开发、部署、测试的流程，就是云原生。弹性资源利用得越充分，云原生的“浓度”就越高，就越容易实施小步快跑的快速迭代。
那么虚拟机是不是弹性最好的计算资源呢？从应用的角度看，显然容器是一种比虚拟机更具弹性，更加抽象，也更容易部署的计算资源。
容器和虚拟机相比，它实际上是一种资源隔离的进程，运行在容器中的应用比独占一个虚拟机消耗的资源更少，启动速度更快。此外，容器的镜像包含了完整的运行时环境，部署的时候，无需考虑任何额外的组件，比其他任何部署方式都简单。使用容器，开发部署流程就变成了开发，生成镜像，推送至Docker Hub或云服务商提供的Registry，直接启动容器，整个过程大大简化。
使用容器比使用CodeDeploy部署还要更加简单，因为CodeDeploy需要在虚拟机镜像中预置Agent，由于没有统一的发布标准，还需要配置CodeDeploy，告诉它去哪拉取最新版本，这又涉及到一系列权限配置。而容器作为标准的部署方案，连发布系统都以Registry对各个镜像版本进行了有效管理，所以部署非常简单。
容器作为一种弹性计算资源，也应遵循计算不变性，即不要给容器挂载可变的存储卷。一组不变的容器集群才能更容易地升级。容器的运行方式本身就遵循了不变性原则，因为通过一个镜像启动一个容器，在运行过程中，是不可能换一个镜像的。容器本身也强烈不建议应用写入数据到文件系统，因为重启后这些修改将全部丢失。
容器的启动和销毁非常容易，不过，容器的管理却并不简单。容器的管理涉及到创建、调度、弹性扩容、负载均衡、故障检测等等，Kubernetes作为事实上的容器编排标准平台，已经成为各个云服务商的标配。
如果要直接使用K8s，在云环境中首先要有一组虚拟机资源作为底层资源，然后搭建K8s环境，定义好容器编排并启动容器。云服务商几乎都提供托管的K8s服务，但直接管理K8s仍然需要非常熟悉K8s的工程师。
还有一种更简单的使用容器的方式，即完全将底层虚拟机和K8s托管给云服务商，企业客户只需关心如何部署容器，底层的K8s和虚拟机对企业不可见或者无需关心。AWS的Elastic Container和阿里云的弹性容器均为此类服务。对于中小规模的应用来说，计算资源直接使用容器，再配合云服务商提供的负载均衡，托管的数据库、消息系统、日志系统等组件服务，应该是目前最“云原生”的一种方案。
最后，我们总结一下云原生的特点：
所谓云原生，就是在上云的过程中，充分发挥云平台的弹性计算、弹性存储的优势，尽量把应用设计成适合云计算的架构，把部署设计成简单易用的流程，这样才能实现业务快速上线，快速迭代。
云原生是一个大方向，在上云的过程中，逐步改造应用架构和部署流程，从手动往自动转，逐步增加计算资源的弹性，就能把云原生一步步落地。
云原生之所以解释不清楚，是因为云原生没有确切的定义，云原生一直在发展变化之中，解释权不归某个人或组织所有。
何谓云原生？
技术的变革，一定是思想先行，云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。
Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念；2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、扛脆弱性；到了2017年，Matt Stine在接受InfoQ采访时又改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；而Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。
2015年云原生计算基金会（CNCF）成立，CNCF掺和进来后，最初把云原生定义为包括：容器化封装+自动化管理+面向微服务；到了2018年，CNCF又更新了云原生的定义，把服务网格(Service Mesh)和声明式API给加了进来。
可见，不同的人和组织对云原生有不同的定义，相同的人和组织在不同时间点对云原生也有不同的定义，真是乱的一匹，搞得鄙人非常晕菜，我的应对很简单，选一个我最容易记住和理解的定义：DevOps+持续交付+微服务+容器。
总而言之，符合云原生架构的应用程序应该是：采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。
容器入门：Docker、Pod初探
01容器是什么？
– 容器是一种计算单元
作为一种计算单元，容器与线程、进程、虚拟机、物理机一样（如下图所示）。在连续尺度上，越往左隔离性、安全性和开销越低，越往右则越高。而容器则恰恰是介于进程和虚拟机之间的一种计算单元。
但并非所有的应用都适合选择容器，开发者可以根据自己应用的特点和需求选择最适合的计算单元。例如，你的应用是高性能、互信的，且处于同一个管理区域，那么用线程或者进程就可以满足；但如果你的应用是多租户的，并且和其他应用运行在同一个空间，那么你就需要考虑如何将这些应用安全地隔离开，使得数据不会被泄露或性能受到影响。那么这时，容器也许就是一个不错的选择了。
因为容器是一个「高度隔离的进程」，它在一般进程的隔离基础上又增加了新的隔离机制，这些隔离机制是使用Linux的内核提供的，它包括一些命名空间（Name Spaces）和CGroup。命名空间可以分为网络、存储和计算三大类。其中，最为重要的是网络命名空间。它保证了容器的网络是独立于其他容器网络的。每个容器自己看到的文件系统和其他容器的是不共享的，每个容器只能看到自己的进程ID，而进程编号也是连续的。
而说到容器与虚拟机最大的区别，刘俊辉认为，相对于虚拟机，容器最大的特征是它没有自己独立的操作系统，而是共享其宿主机上的一个操作系统；而虚拟机则运行在「一台独立的服务器上」。因此，容器相比于虚拟机的成本会小，但隔离性却有所欠缺。
– 容器是一种应用的包装形式
有过应用开发经验的人都知道，应用并不是一个单一的可执行文件，一个稍微复杂一点的应用包括多个部分，包括：代码、可执行文件、配置依赖、外部依赖（动态链接库）等。
所以在应用发行包装的时候，需要考虑目标操作系统的版本、系统架构以及它所依赖的模块等因素。否则应用安装时会改动系统的不同部分。
而容器作为一个应用的包装，它最大的特点就是实现了应用的独立和便携，容器本身包含了应用所有的依赖，这使得它可以再任意的基础设施上运行，不会因为系统版本、架构的问题，而导致各种意外。
02Docker是什么？
简单来说，Docker可以看作是一个非常成功的容器管理平台。Docker最重要的部分就是它的运行管理环境
正如上面所说，容器是一个计算单元，那么Docker的运行环境就是用来创建、管理和销毁这些计算单元的。在创建和管理这些计算单元的时候，需要用到计算单元的包装（也就是它的软件发行包），这些包装以容器镜像的方式存放在它的运行环境中，所有的容器计算单元都是通过这些镜像来创建的。
但镜像本身会有版本的发布、升级等需求，这就涉及到Docker的另一个重要组成部分DockerHub了。DockerHub有点像苹果的App Store，它是一个非常大的「容器市场」，所有常用的软件都可以在DockerHub上找到。
最后一个Docker的重要模块，就是用户界面和管理工具，它们用来向容器的运行环境发布命令或查看状态。只需要用一个Docker的命令加上一些参数，就可以实现创建、删除、查看容器的运行情况等操作。
接下来我们就来看看Docker的实际操作情况，我们会以运行一个Hello World的容器为例，讲讲Docker的使用情况。其实，只需要安装好Docker就可以尝试运行这个Hello World的容器了。
通过下面代码，我们来看看Docker做了些什么：
首先我们看到Docker在本地要去找Hello World最新版本的镜像，它发现本地并没有这个镜像后去DockerHub上把这个镜像给下载了下来。然后，这个镜像就被运行了，之后Docker后台就创建了这样一个容器。
Docker的出现，让容器应用管理变得非常轻松，运行容器只需要一个命令就可以实现。而从DockerHub上下载镜像、创建各种各样的隔离环境、创建容器与外部的网络通信环境都可以由Docker来完成。可以说Docker可以管理容器的整个生命周期。
Pod，一种增强型容器
Pod是一种组合的多容器运行单元，也是Kubernetes里的一个基础单元。你可以把它看作是一种容器的扩展或者增强型的容器。Pod里面包括一个主容器和数个辅助容器，它们共同完成一个特定的功能。把多个进程（容器也是一种隔离的进程）打包在一个Name Space里的时候，就构成了一个Pod。Pod里面不同进程的应用包装仍然是独立的（每个容器都会有自己的镜像）。
Pod的意义在于，它可以既保持主容器和辅助容器的的密切关系，又保持主容器的独立性。由于主容器和辅助容器的生命周期相同，可以同时被创建和销毁，因此把它们放在一个Pod中，可以使他们的交互更加高效。
而另一方面，主容器需要完成一些主要的工作，而另一些工作可能是有共性的，就可以单独打包由辅助容器来运行。
在K8S里，编排调度的最小单位并不是容器，而是Pod。有了Docker容器，为什么还需要一个Pod? 前面我们说Docker容器就好比云计算操作系统中的应用，K8S相当于操作系统，那Pod就是进程组：即Pod是对一组容器（一个或多个）的抽象。之所以做这样一层抽象，是因为在 Borg 项目的开发和实践过程中，Google 公司的工程师们发现，他们部署的应用，往往都存在着类似于“进程和进程组”的关系。在同一个Pod中，可以直接通过localhost通信，并且可以共享网络栈和Volume
非常推荐大家去一个叫Katacoda的网站，它上面有大量免费的在线实验，包括Docker及Docker Image等动手操作项目，而且现在是完全免费的。大家不妨去这里动手实操起来。
docker-compose
Dockerfile可以让用户管理一个单独的应用容器，而compose则允许用户在一个模板（yaml格式）中定义一组相关联的应用容器（被称为一个project，即项目）
例如一个web服务再加上后端的数据库服务容器等
为什么要使用docker-compose
使用一个Dockerfile模板文件，可以让用户很方便的定义一个单独应用容器。在工作中，经常会碰到需要多个容器相互配合来完成某项任务的情况，例如要实现一个web项目，除了web服务容器本身，往往还需要再加上后端的数据库服务容器，甚至还包括负载均衡容器等。
compose允许用户通过一个单独docker-compose.yml模板文件（YAML格式）来定义一组相关联的应用容器为一个项目（project）
docker-compose项目由python编写，调用docker服务提供的API来对容器进行管理，因此， 只要所操作的平台支持docker-API，就可以在其上利用conpose来进行编排管理。
简单来说：就是来管理多个容器的，定义启动顺序的，合理编排，方便管理。
docker-compose和k8s的区别
Docker Compose是一个基于Docker的单主机容器编排工具.适合开发、测试和暂存环境
而k8s是一个跨主机的集群部署工具,是大型生产级部署的更好选择
