帶你讀《雲原生應用開發 Operator原理與實踐》第一章引言1.1雲原生介紹（二）

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）。

NAME	READY	UP-TO-DATE	AVAILABLE    AGE
nginx	0/3	3	0           0s
	1/3		1           3s
	2/3		2           3s

（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設計開發。