定义
其实云原生可以拆分成"云"+"原生"两个概念来理解
云原生有很多的相关定义，这里我们按照比较权威的CNCF （云原生计算基金会 Cloud Native Computing Foundation）来介绍，即：云原生是一类技术的统称 ，通过云原生技术我们可以构建出更易于弹性扩展的应用程序，其包括容器、服务网格、微服务、不可变基础设施和声明式API等相关技术，这些技术能够构建出容错性好 、易于管理 、便于观察 的松耦合 系统，结合可靠的自动化手段，相关工程师能够轻松地对系统做出频繁和可预测的重大变更。
那"云"和"原生"的关系是？
"云"即云计算技术或者云计算平台
"原生"即"土生土长"，从云的基础上发展而来的
"云原生"即表示业务的原生化（可以简单理解为按照适用于上面介绍的云原生技术，即容器、服务网格、微服务、不可变基础设施和声明式API等方式来开发应用程序）
为什么要使用"云原生"？
使用云原生的优点主要在于：
- 业务应用被设计为在云上以最佳的方式运行
- 充分发挥云的优势（主要包括资源的无限化、扩容/缩容便利化等），云原生技术有利于各组织在公有云、私有云、混合云等新型动态环境中，构建和运行可弹性化扩展的应用
"云原生"概念的由来
- 2013年，Pivotal公司的Matt Stine首次提出"云原生"的概念
- 2015年，CNCF成立，最初把"云原生"定义为：容器化封装+自动化管理+面向微服务
- 2018年，CNCF将在"云原生"的概念中添加了服务网格和声明式API
"云原生"最佳实践的三个层面
- 服务编排要实现计算资源弹性化
- 服务构建和部署要实现高度自动化
- 事件驱动基础设施标准化
"云原生"代表技术
微服务
指将原有的单体应用拆分为多个独立自治的组件，每个组件都可以独立设计、开发、测试和运维（各组件之间可通过轻量级的Restful风格进行交互和协同），这个组件可以对外单独提供服务，即微服务。
容器化
Docker容器
容器属于IT基础设施层概念（类似虚拟机，但更加轻量级，是微服务的最佳载体）
我们可以看下容器和虚拟机的区别
Kubernetes
Kubernetes负责资源调度和容器编排，使用Kubernetes可以对Docker容器进行更优化的管理，进一步实现其PAAS层的能力
服务网格（Service Mesh）
服务网格（Service Mesh）是一个去中心化的服务治理框架，专门用于服务间通信的基础设施层（独立的运行单元），实现形式为轻量级的网络代理（这些代理是和应用程序代码部署在同一个容器内并将网络通信从应用程序逻辑中抽象出来），服务网格主要提供了如下功能：
- 服务发现：自动地检测服务间的相互依赖关系。
- 负载均衡：实现不同服务之间的流量分发。
- 故障恢复：自动处理服务失败，以提高系统的整体可靠性。
- 持续验证和安全：提供预置加密机制，确保服务间通信的安全。
- 指标和监控：提供跟踪和监控，帮助用户识别和解决问题，优化服务性能。
- 流量控制：服务网格可以将API请求按照特定规则进行路由。
典型的服务网格设计是一个"数据平面"和一个"控制平面"。
- 数据平面负责处理服务间的网络请求
- 控制平面负责为数据平面提供策略和配置信息。
简单理解下服务网格就像是一个管理和控制交通的系统，只不过这里的交通，不是汽车一类的交通工具，而是大量在互联网中传输的信息。我们把一个大型网站或云服务比作一个大城市，那么这个服务的各大功能（例如登录验权、数据存储、内容推荐等）就像是城市里的各个区域。这些区域之间需要通过交通进行通信，需要遵循交通管理规则，以确保找到正确的路去到正确的地方。服务网格就起到类似这个城市的交通管理系统的作用，它负责确保所有的信息都能快速准确地从一个服务传到另一个服务（比如为信息寻找合理的路线、避开拥堵，或者在某条路线出问题时及时更换新的路线），同时服务网格还要负责记录每次信息传递的情况（交警记录路况等信息），以便在出现问题时可以方便地查找和解决。通过服务网格，可以让我们的服务（城市）的"交通"更加顺畅，同时在出现问题的时候，也能更快速地找到解决办法。
更多内容还可参考如下文章（感觉总结的不错，感谢作者(*≧ω≦)）
zhuanlan.zhihu.com/p/648288423
不可变基础设施
传统开发过程中，当一个程序部署到生产环境后，如果想要做变更（不管是程序的变更还是配置的变更）都需要在原来的生产环境中重新部署或对某一个配置直接进行修改，但是在云原生技术中任何一个应用部署到生产环境，形成一个容器实例以后，这个实例都不应该再做任何变更，如果需要程序的变更或者配置的变更，则需要利用基础容器镜像，重新生成一个新的容器实例，同时把旧的销毁，这就是"云原生"技术中要求的不可变技术点。
声明式API
应用部署的执行方式主要分为：命令式 和声明式
命令式
通过在命令行中执行命令来完成操作（如构建容器等）
声明式
使用yaml资源清单文件（在资源清单文件中声明要做的操作、需要配置的信息、用户的期望状态等）
当基础设施获取到声明文件后，首先会解析文件中的内容，再去后端做响应的操作，操作完成后，把各个底层技术组件协调到应用需要的状态。使用声明式API时，任何对生产环境、配置相关的操作都不是操作一条命令来完成，都需要先编写声明/配置文件，这部分操作可以纳入到配置管理中去进行集中管理，这就有利于在生产环境中出现问题时，了解前置各种操作对环境造成的影响，进而迅速进行定位排查，易于版本的回退/回滚等操作。
Devops
- 实现开发、运维、测试协同合作
- 构建自动化发布管道，实现代码的快速部署（测试/预发布/生产环境等）
- 频繁发布、快速交付、快速迭代、降低风险