3. 云原生概念的发展

 

在Docker和k8s不断发展时，“云原生应用”的理念被逐步提出。2014年，Pivotal公司提出了“CloudNative”一词，并且提出了一系列概念，凡是符合这些概念的应用都叫云原生应用。Pivotal 公司也在不断修改云原生应用的特征定义，2014年，该公司提出Twelve-Factor应用、Microservices等；2017 年，提出模块化、可观测性、可部署性、可测试性、可处理性、可替换性，2019年，将云原生应用的特征定义修改为DevOps、持续交付、容器化、微服务化。同时，CNCF基金会是云原生理念的重要推手，它不断改变云原生应用的定义：2015 年，将云原生应用定义为容器化、微服务化、动态编排，2018 年，将云原生应用定义为容器、服务网格、微服务、不可变基础设施、声明式AP。

总之，“云原生”虽然像“中台”概念一样也在不断被炒作，但云上的应用的确在向“云原生应用化”发展。云原生只是一种理念，指的是软件“生于云上、长于云上”，能够最大化地利用云的能力实现商业价值。很多人认为云原生就是容器、k8s，其实不太准确。没有容器、k8s，一样可以实现云原生，但有了容器和k8s，再配合其他技术、产品，能够更好地组织团队，利用云提供的各种能力，如DevOps，以敏捷的方式开发、交付、管理复杂应用，更快地响应市场，实现商业价值。云原生也是“云的本源需求”。云计算的初衷就是要像水、电一样为人们提供按需、随处可得、易用、弹性的服务和能力。用户不需要考虑水和电是如何产生的，只需要考虑如何利用水和电。云原生也一样：用户只需要专注业务、考虑如何实现业务，而不需要考虑业务必需的硬件、操作系统、数据库、MQ（消息队列）、缓存、开发框架、微服务框架等。这些都交给云服务商来考虑。

所以，云原生对开发者来说，就是要利用好云的能力，构建满足容器化、微服务化、可以敏捷迭代、更具备弹性化等特征的云原生应用；对云服务商来说，就是要在设计云产品和服务时，考虑如何更好地支撑和承载云原生应用。

1.1.2      Kubernetes：云原生基础设施

 

2014年，Google公司开源了 Kubernetes 项目。此时，在容器编排领域主要有两个竞争对手，即 Docker公司的 DockerSwarm和 Apache基金会的 Mesos。虽然 Kubernetes诞生得较晚，但实际上其设计思想来源于 Google公司内部的 Borg和 Omega系统特性，这些特性放到Kubernetes项目上，就是 Pod、Sidecar等功能和设计模式。这些特性并不是几个工程师突发奇想的结果，而是Google公司在容器化基础设施领域多年来实践经验的沉淀与升华。为了推广Kubernetes项目，同时与 Docker公司竞争，Google 和RedHat联合发起 CNCF基金会。有了这两家公司的背书，CNCF和 Kubernetes迅速发展，该基金会下的项目和围绕Kubernetes的二次创新项目大量涌现，包括容器监控的实施标准 Prometheus、微服务治理项目 Istio、有状态应用部署框架 Operator等。2017年，Docker公司宣布将在自己的主打产品 Docker企业版中内置 Kubernetes，这标志着容器编排之争落下了帷幕，Kubernetes成为容器编排的事实标准。

从技术角度来讨论 Kubernetes 为何能获胜也是个有意思的话题。

Kubernetes从应用的角度定义了多种资源，用来描述不同的应用类型以及相关能力（见代码清单1-1）。

 

（1）  Pod：最小的调度单元，一个 Pod包含一组容器，容器之间通常存在密切关系，例如，使用localhost（本地主机）进行本地通信会直接发生文件交换、需要共享LinuxNamespace。 

（2）  Deployment：通常用来部署多副本的 Pod，可以看到 Pod 的状态，在 Pod 异常时能够及时处理故障，使其恢复正常。

（3）  Statefulset：描述有状态应用，可以控制 Pod的启动顺序，为Pod绑定不同的存储等。

（4）  Job、CronJob：这两种类型资源分别对应一次性任务和周期性任务。

（5）  Daemonset：通常用来部署后台常驻任务，如在每个节点上的日志程序。

除了以上描述应用的资源，还有其他资源。

（1）  Service：描述了一个应用的访问入口，通过 Labe（l务（Pod）的关联，也就实现了服务发现功能。

（2）  Ingress：支持 Kubernetes 集群以外的客户端访问应用。

（3）  Configmap、Secret：描述应用所需的配置参数或加密的密钥等。

（4）  PV、PVC、HostPath、EmptyDir：描述应用所需的各类存储，支持持久化存储、临时存储。有了这些资源对象，使用者可以很方便地描述应用程序。通常使用 Yaml文件表示，

一个 kubectlapply-fmyapp.yaml命令就可以等待 Kubernetes完成应用部署，达到期望状态，其背后重要的设计理念就是声明式 API和控制器模式。简单理解，用户通过Yaml文件描述了期望的最终状态，比如“我需要用 Nginx镜像启动 3 个 Pod，然后通过名为 Myapp的 Service暴露这个应用”。Kubernetes接收到这个请求时，会将其保存到 ETCD数据库中，由控制器创建 3个 Pod和 1个 Service。由于创建资源需要一定时间，控制器会不断检查这些资源的状态，并且和期望的状态比较，如果不一致，持    续处理（例如调度到其他节点），直到最终达成一致。

此外，Kubernetes具备可扩展性。其实优秀的开源项目都支持扩展， 例如 OpenStack在网络层面定义了Neutron 网络插件（NetworkPlugin），用于支持开源的Open vSwitch（OVS）、商业化的SDN产品；在存储层面，通过CinderVolumeDriver，支持逻辑卷管理（LVM，LogicalVolumeManager）以及各种商业化的存储；在调度器层面，支持自定义Scheduler。类似地，Kubernetes通过CR（I容器运行时接口）、CS（I容器存储接口）、CN（I  容器网络接口），也支持计算、存储、网络的扩展性。更重要的是，Kubernetes在 API 资源层面也支持扩展，使用者可以通过自定义资源定义（CRD，CustomResourceDefinition）自定义资源，而且这些资源和 Pod、Deployment 等原生资源有同样的使用方式，同时对已有代码没有侵入性。这就大大激发了开发者的潜能。再加上     Sidecar、Operator等机制，一系列优秀的开源项目如雨后春笋般涌现，大大加速了 Kubernetes的发展。可以说，“占领开发者心智”是Kubernetes的重磅武器。

从 Kubernetes 诞生至今，它已经成为云原生基础设施的代名词。越来越多的开源项目都支持 Kubernetes部署， 如数据库领域的 MySQL、MongoDB、Redis、TiDB，大数据领域的 Spark、Splunk，监控领域的 Prometheus、DynatraceOneAgent、SysdigAgentOperator，安全领域的 Falco， 微服务领域的 Istio、Linkerd等。Kubernetes在新兴领域也有很多项目，如人工智能领域的Kubeflow，边缘计算领域的 KubeEdge、k3s等。在云服务商的产品目录中，Kubernetes早已成为标配。AmazonElasticKubernetesService、AzureKubernetesService、GoogleKubernetesEngine、AlibabaCloudContainerServiceforKubernetes、TencentKubernetesEngine、China Mobile eCloudKubernetesContainerService，从名字就可以看出，国内外云服务商的容器产品都围绕Kubernetes设计开发。