Cloud Native的设计哲学理念，kubernetes云生态操作系统
2015年的时候google就提出了云原生计算基金会（CNCF），最开始的时候我对于云原生的定义于以下几个方面：应用容器化，面向微服务架构，应用支持容器的调度。但是这种想法和定义在未来几年后，技术的不断提升，需求的不断更改，定义也被重新定义。2018年的时候，几乎所有的云计算提供商都加入了CNCF，这个时候，云原生生态在不断的壮大，我们来看一段英文定义：
Cloud native technologies empower organizations to build and runscalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices,immutable infrastructure, and declarative APIs exemplify this approach.
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
云原生一词已经被过度的采用，很多软件都号称是云原生，很多打着云原生旗号的会议也如雨后春笋般涌现。
云原生本身甚至不能称为是一种架构，它首先是一种基础设施，运行在其上的应用称作云原生应用，只有符合云原生设计哲学的应用架构才叫云原生应用架构。
Distribution：容器、微服务、API 驱动的开发；
Configuration：一个镜像，多个环境配置；
Resistancy：故障容忍和自愈；
Elasticity：弹性扩展和对环境变化（负载）做出响应；
Delivery：自动拉起，缩短交付时间；
Performance：响应式，并发和资源高效利用；
Automation：自动化的 DevOps；
Diagnosability：集群级别的日志、metric 和追踪；
Security：安全端点、API Gateway、端到端加密；什么不是云原生基础设施： 云原生基础设施不等于在公有云上运行的基础设施。光是租用服务器并不会使您的基础设施云原生化。管理IaaS的流程与运维物理数据中心没什么两样，将现有架构迁移到云上也未必能获得回报。
云原生不是指在容器中运行应用程序。Netflix率先推出云原生基础设施时，几乎所有应用程序部署在虚拟机中，而不是在容器中。改变应用程序的打包方式并不意味着就会增加自治系统的可扩展性和优势。即使应用程序是通过CI/CD渠道自动构建和部署的，也不意味着您就可以从增强API驱动部署的基础设施中受益。
这也并不意味着您只能运行容器编排器（例如Kubernetes和Mesos）。容器编排器提供了云原生基础设施所需的许多平台功能，但并未按预期方式使用这些功能，这意味着您的应用程序会在一组服务器上运行，被动态调度。这是一个非常好的起步，但仍有许多工作要做。 调度器是编排平台的一个子集，仅负责选择运行在每台服务器上的进程和服务。
云原生不是微服务或基础设施即代码。微服务意味着更快的开发周期和更小的独特功能，但是单片应用程序可以具有相同的功能，使其能够通过软件有效管理，并且还可以从云原生基础设施中受益。
基础设施即代码以机器可解析语言或领域特定语言（DSL）定义、自动化您的基础设施。将代码应用于基础架构的传统工具包括配置管理工具（例如Chef和Puppet）。这些工具在自动执行任务和提供一致性方面有很大帮助，但是它们在提供必要的抽象来描述超出单个服务器的基础设施方面存在缺陷。
配置管理工具一次自动化一台服务器，并依靠人员将服务器提供的功能绑定在一起。这将人类定位为基础设施规模的潜在瓶颈。这些工具也不会使构建完整系统所需的云基础设施（例如存储和网络）的额外部分自动化。
尽管配置管理工具为操作系统的资源（例如软件包管理器）提供了一些抽象，但它们并没有抽象出足够的底层操作系统来轻松管理它。如果一位工程师想要管理系统中的每个软件包和文件，这将是一个非常艰苦的过程，并且对于每个配置变体都是独一无二的。同样，定义不存在或不正确的资源的配置管理仅消耗系统资源并且不能提供任何价值。
虽然配置管理工具可以帮助自动化部分基础设施，但它们无法更好地管理应用程序。我们将在后面的章节中通过查看部署，管理，测试和操作基础架构的流程，探讨云原生基础设施的不同之处，但首先，我们将了解哪些应用程序是成功的以及应该何时与原生基础设施一起使用。
云原生的未来： 要想搞明云原生的未来，首先我们要弄明白云原生是什么。CNCF给出的定义是： 容器化 微服务 容器可以动态调度 我认为云原生实际上是一种理念或者说是方法论，它包括如下四个方面：
容器化：作为应用包装的载体 持续交付：利用容器的轻便的特性，构建持续集成和持续发布的流水线 DevOps：开发与运维之间的协同，上升到一种文化的层次，能够让应用快速的部署和发布 微服务：这是应用开发的一种理念，将单体应用拆分为微服务才能更好的实现云原生，才能独立的部署、扩展和更新
一句话解释什么是云原生应用：云原生应用就是为了在云上运行而开发的应用。
Kubernetes：云原生操作系统
要运行这样的应用必须有一个操作系统，就像我们运行PC或手机应用一样，而Kubernetes就是一个这样的操作系统。
