1.3 CNCF與云原生平臺

CNCF（Cloud-Native Compute Foundation，云原生計算基金會）由Google等大公司牽頭于2015年正式成立，目前有100多家企業成員，其目的是在容器、微服務及DevOps領域里，通過一系列的規范和標準幫助企業和組織，在現代的云化環境中構建架構一致的應用。

CNCF的Landscape定義了關于Provisioning、Runtime、容器編排、PaaS平臺、微服務治理等多個容器和微服務相關子領域的開源組件和技術標準。

1.3.1 CNCF社區

CNCF Landscape定義了各領域中優秀的云原生組件。Landscape的發展速度很快，近幾年不斷地納入新的應用和組件，外表紛繁復雜。CNCF中定義的邏輯是很清晰的，關鍵的組件也很有限。在圖1-4中，1～9是CNCF Landscape中的關鍵部分。

1）第一部分是內存數據庫和關系數據庫部分。核心和常用的組件有：關系型數據庫MySQL和PostgreSQL、內存數據庫Redis、分布式事務組件Seata、文件存儲數據庫MongoDB。這是第一部分的幾個核心組件，其他組件并不是沒有用，只是這幾個組件占據了云原生社區，特別是國內云原生社區的大部分關注。再就是云原生主推的數據庫Vitness發展速度也很快，它是基于MySQL的主從復制數據庫。

2）第二部分的重點是Spark、Flink這兩個流式數據分析技術，以及Kafka和RabbitMQ這兩個消息中間件。

3）第三部分的重點是Helm。這是一個將批量的Kubernetes pod資源聲明文件合并成一個整體，形成一個包括多個應用組件的完整應用定義包，并支持部署運行的一套組件。

4）第四部分的重點是GitLab。這是一個開源的代碼倉庫實現，并支持流水線。另外Jenkins是傳統主流的流水線調度引擎。

5）第五部分的重點是Kubernetes。

6）第六部分的重點是Istio。Istio是主流的Service Mesh框架。

7）第七部分是容器領域的三大標準，分別是計算部分的CRI標準，存儲部分的CSI標準，網絡部分的CNI標準。CRI標準的權威實現是Containerd，在2020年年底，Kubernetes原生不支持Docker容器引擎，原因是Docker底層不是CRI標準（但是Docker有dockersim，通過dockersim實現了CRI-O標準的接口轉換）。CSI標準的主流實現是Ceph，這是最為主流的分布式存儲技術。CNI作為網絡標準，有多個主流的網絡實現，包括Calico、OVS、Flannel等。

8）第八部分是邊緣云、部署服務、容器安全和密鑰管理相關的云原生組件。這里面最為常用的是Harbor，是一個分布式鏡像倉庫組件。

9）第九部分是監控和日志部分，最為主流的監控組件就是Prometheus，日志組件最為主流的是ELK日志套件。

上面簡單介紹了一下CNCF社區的全局概貌。云原生社區集合了幾乎所有主流云服務供應商和所有跟云相關的技術，同時涉及了很多的商業競爭，把云原生社區完整地了解透徹需要大量的學習和研究，需要投入大量的時間和精力。不過好在云原生有它主流的一些技術體系和技術組件，把握了主流的這部分內容，相當于80%的云原生內容都已經掌握了。

為了能夠充分地理解和掌握云原生下的安全體系，在后面的章節中，會有一些案例和實際操作。本章的介紹比較簡短，不可能讓大家通過這么一點信息建立起對云原生技術的支撐，但是讀者可以通過一定的學習迅速掌握前述9點當中的重要組件，從而能夠在云原生技術大浪中暢游而不會感到不適。這些基礎的組件和技術包括Kubernetes、ELK、Helm、Redis、RabbitMQ、Jenkins、GitLab、Harbor、Ceph、MySQL，以及容器領域三大接口標準CRI、CSI、CNI。

1.3.2 云服務商與云原生

隨著云原生技術的推廣普及，國內外主流云服務提供商都投入了大量的精力在云原生的推廣上。在云服務提供商的服務目錄里，普遍都有較為完善的云原生支持。

國內廠商比如阿里云、華為云等在容器相關產品、微服務產品，以及云原生中間件及數據庫產品、DevOps產品等方面都有對應的服務能力，詳見表1-2。

Google在2019年發布的Anthos融合了GKE、私有化Kubernetes服務、Kubernetes集群納管能力、容器應用部署能力和應用配置管理能力，是一個完整的云原生混合云平臺。

從表面上看，在云原生技術領域，從基礎容器技術到Kubernetes平臺，到中間件直至DevOps工具鏈，基本上都是以國外的技術為主，鮮有由國內發起的原創技術。實際上，國內的云原生技術發展也有很多優秀的產品，除了一些表現搶眼的中間件和微服務框架之外，由阿里云聯合微軟提出的OAM（Open Application Model）更是其中的翹楚。

OAM將應用軟件運行的基礎設施、應用的配置和運維策略以及應用本身的定義綜合起來，形成了一整套圍繞應用的完整定義規范。這套定義規范支持異構平臺、容器運行時、調度系統、云供應商、硬件配置等信息。基于這套規范定義的應用Yaml配置，能夠自底向上從資源層到應用層直至應用運維策略，在云原生平臺上把應用完整地建立起來。目前OAM也處在迅速的進步當中，未來會有更進一步的發展。

1.3.3 利用開源技術搭建云原生平臺

云原生社區秉承開放原則，集合了大部分云計算行業的主流公司和大量的開源社區力量。在這些力量下，圍繞容器和Kubernetes的技術體系迅速地迭代，利用開源技術搭建一套完整的云原生平臺是可行的。

此外，云原生技術本身就代表著統一，使用開源技術搭建的私有化云原生平臺以及在上面開發的云原生應用，理論上可以輕松地遷移到任何其他云原生平臺上，而不需要做調整適配。

采用主流開源技術搭建云原生平臺，并運行一個簡單的云原生應用，其最終形態大體上如圖1-5所示。

搭建上面的云原生平臺在硬件資源上需要三臺服務器，這三臺服務器至少需要4核CPU、8GB內存，并且通過千兆網卡連接。搭建步驟如下。

1）使用Kubernetes安全工具，按照Kubernetes集群推薦使用Kubeadm（https://kubernetes.io/zh/docs/reference/setup-tools/kubeadm/）。

2）在部署好的Kubernetes集群中安裝Helm，通過Helm來安裝后續的其他服務。

3）通過Helm來安裝部署分布式存儲GlusterFS、Redis服務、MySQL服務、GitLab或Jenkins。

4）創建代碼庫，配置Jenkins流水線。

5）通過流水線將代碼打包構建成容器鏡像，并存放到鏡像倉庫中。

6）通過容器鏡像來啟動微服務。微服務使用ETCD作為注冊中心，同樣也使用ETCD作為配置中心。

7）Kubernetes集群中運行的微服務對外通過集群Ingress提供服務，外部請求通過Ingress訪問運行在集群中的微服務。