使用容器嗎?來熟悉一下云原生計算基金會上的這些項目。
隨著使用容器開發應用程序的實踐越來越流行,云本地應用程序也在不斷增加。根據定義:
“云原生技術用于開發應用程序,這些應用程序使用封裝在容器中的服務構建,部署為微服務,并通過敏捷的 DevOps 流程和持續交付工作流在彈性基礎設施上進行管理。”
該描述包括四個元素,這些元素與云原生應用程序是一體的:
容器
微服務
DevOps
持續集成和持續交付(CI/CD)
盡管這些技術有著非常獨特的歷史,但它們相互補充得很好,并在短時間內導致云原生應用程序和工具集的指數級增長。這張云原生計算基金會(CNCF)的信息圖表顯示了云原生應用生態系統的大小和廣度。
云原生計算基金會項目圖
我是說,看看這個!這只是一個開始。正如 Node.JS 的創建引發了無休止的 JavaScript 工具的爆炸,容器技術的流行開始了云本地應用程序的指數級增長。
好消息是有幾個組織負責監督和連接這些點。一個是開放容器聯盟(OCI),它是一個輕量級的開放式治理結構(或項目),在 Linux 基金會的支持下形成的。OCI 目的是圍繞容器格式和運行時間創建開放的工業標準。另一個是 CNCF,“一個開源軟件基金會致力于使云原生計算普及和可持續。”
除了一般圍繞云本機應用程序構建社區之外,CNCF 還幫助項目圍繞其云本機應用程序建立結構化治理。CNCF 創建了成熟度級別“沙盒”、“孵化”或“畢業”的概念,與下圖中的創新者、早期采用者和早期多數層相對應。
CNCF 成熟度模型
1)沙盒階段
要在沙盒中被接受,一個項目必須至少有兩個 TOC 發起人。詳細流程請參見 CNCF Sandbox Guidelines v1.0。
2)孵化階段
注:孵化水平是我們希望對項目進行全面盡職調查的點。
要進入孵化階段,項目必須滿足沙盒階段的要求,并加上:
記錄至少三個獨立的最終用戶在生產中成功使用,根據 TOC 的判斷,這些用戶具有足夠的質量和范圍
有一個合理的提交者數量。提交者定義為具有 commit bit 的人,即可以通過對項目的部分或全部的代碼提交貢獻的人
顯示出持續不斷的代碼提交和代碼合并數據流
由于這些指標可能因項目的類型、范圍和規模而顯著不同,因此 TOC 對足以滿足這些標準的活動水平有最終判斷
3)畢業階段
能從“沙盒”或者“孵化”達到“畢業”階段的項目,或者一個直接就進入到“畢業”階段的項目,項目必須符合孵化階段標準,以及如下條件:
擁有來自至少兩個組織的代碼提交者
已經實現并維護了核心基礎設施計劃最佳實踐徽章
已完成獨立的第三方安全審計,其結果發布的范圍和質量與以下示例類似(包括已解決的列舉在https://github.com/envoyproxy/envoy#security-audit的關鍵漏洞)并且所有關鍵的問題都需要在“畢業”前解決
適應 CNCF 執行準則
明確定義項目治理和提交者流程。這最好在 governance.md 文件中列出,并參考 owners.md 文件,顯示當前和退休的提交者
至少有一個項目采用者的公開列表(例如,Adopters.md 或項目網站上的 logo)
獲得 TOC 的絕大多數選票,項目進入“畢業”階段。如果項目能夠顯示出足夠的成熟度,那么它們可以嘗試直接從“沙盒”直接跳躍到“畢業”。項目可以無限期地保持在“孵化”狀態,但通常預計在兩年內達到“畢業”階段
9 個值得考慮的項目
盡管不可能在一篇文章中涵蓋所有 CNCF 項目,我還是想要列舉 9 個有趣的處于“畢業”階段和“孵化”階段的開源項目。
項目 |
License |
簡介 |
Kubernetes |
Apache 2.0 |
容器編排平臺 |
Prometheus |
Apache 2.0 |
系統和服務監控工具 |
Envoy |
Apache 2.0 |
服務代理 |
rkt |
Apache 2.0 |
Pod 原生容器引擎 |
Jaeger |
Apache 2.0 |
分布式跟蹤系統 |
Linkerd |
Apache 2.0 |
透明的 service mesh |
Helm |
Apache 2.0 |
Kubernetes 包管理 |
Etcd |
Apache 2.0 |
分布式 key-value 存儲 |
CRI-O |
Apache 2.0 |
輕量級 Kubernetes 運行時間管理 |
一、畢業的項目
“畢業”階段項目被許多組織認為是成熟的,必須遵守 CNCF 的指導方針。以下是三個非常流行的開源 CNCF 畢業項目。(請注意,其中一些描述是從項目的網站上改編和重用的。)
1、Kubernetes
啊,Kubernetes。我們如何在不提到 Kubernetes 的情況下談論云原生應用程序?Kubernetes 無疑是 Google 發明的非常著名的基于容器的應用程序的容器編排平臺,也是一個開源工具。
什么是容器編排平臺?基本上,一個獨立的容器引擎可以管理幾個容器。然而,當您談論數千個容器和數百個服務時,管理這些容器變得非常復雜。這就是容器引擎的切入點。容器編排引擎通過自動化容器的部署、管理、聯網和可用性來幫助擴展容器。
Docker Swarm 和 Mesosphere Marathon 是另外兩種容器編排引擎,但是我們可以很放心地說 Kubernetes 在競爭中勝出。Kubernetes 還催生了 Container-as-a-Service (CaaS) 平臺,比如:OKD。最初的 Kubernetes 社區發布版,激發 RedHat 的 OpenShift。
可以從閱讀 Kubernetes 的 Github 倉庫開始,在 Kubernetes Documents 站點網頁訪問文檔學習資源。
2、Prometheus
Prometheus 是一個開源系統監控和警報工具包,于 2012 年在 SoundCloud 構建。從那時起,許多公司和組織都采用了 Prometheus,并且這個項目有一個非?;钴S的開發人員和用戶社區。它現在是一個獨立的開源項目,獨立于公司進行維護。
Prometheus 架構
了解 Prometheus 最簡單的方法是設想一個生產系統,它需要每天 24 小時,每年 365 天工作。沒有一個系統是完美的,也有一些技術可以減少故障(稱為容錯系統)。但是,如果出現問題,最重要的是盡快識別它。這就是 Prometheus 這樣的監控工具的用武之地。Prometheus 不僅僅是一個容器監控工具,它在云原生應用程序公司中很受歡迎。此外,其它開源監控工具,包括 Grafana,可以對接 Prometheus。
開始 Prometheus 最好的辦法是訪問它的 GitHub 代碼倉庫,本地運行 Prometheus 是很容易的,但是必須提前有一個容器引擎。用戶可以在 Prometheus 的官網獲取更詳細文檔。
3、Envoy
Envoy(或 Envoy Proxy)是一個開源的邊緣和服務代理。由 LyFT 創建的 Envoy 是一個由 C++ 編寫的,高性能,分布式代理,專為單一服務和應用而設計,以及為大型微服務網格體系結構設計的通信總線和通用數據平面。基于對 Nginx、HAProxy、硬件負載均衡器和云負載均衡器等解決方案的學習,Envoy 與每個應用程序一起運行,并通過以平臺無感知的方式提供公共特性來抽象網絡。
當一個基礎設施中的所有服務流量都通過一個 Envoy mesh 流動時,通過一致的可觀測性,調整整體性能,并在一個地方添加底層特性,就可以很容易地觀察問題區域?;旧?,Envoy Proxy 是一個 Service Mesh 工具,幫助組織為生產環境構建容錯系統。
ServiceMesh 應用程序有許多替代方案,例如 Uber 的 Linkerd(下面討論)和 Isito。Istio 通過部署為 Sidecar 并利用 Mixer 配置模型來擴展 Envoy Proxy。Envoy 的顯著特點是:
包含所有該支持的功能(當搭配控制平面,如 Istio 的時候)
在負載情況下消耗資源量很低
在其核心處充當 L3/L4 過濾,并且可以提供許多不可思議的 L7 過濾
支持 GRPC 和 HTTP/2(上游/下游)
它是 API 驅動的,支持動態配置和熱重加載
重點關注度量收集、跟蹤和整體可觀測性
想要了解 Envoy 更多,發揮它的能力,并實現其全部優勢,用戶需要在運行生產級環境方面有豐富的經驗。訪問 Envoy 的 GitHub 代碼倉庫,閱讀文檔,用戶可以了解更詳細信息。
二、“孵化”階段項目
下面是六個非常受歡迎的開源 CNCF 孵化項目
1、rkt
rkt,發音為“rocket”,是一種 pod-native 引擎。它有一個命令行界面(cli),用于在 Linux 上運行容器。在某種意義上,它類似于其他容器,如:Podman、Docker 和 CRI-O。
rkt 最初是由 CoreOS 開發的(后來被 Red Hat 收購),您可以在其網站上找到詳細的文檔并訪問 Github 上的源代碼。
2、Jaeger
Jaeger 是一個開源、端到端的分布式跟蹤系統,用于云原生應用程序。在某種程度上,它是 Prometheus 這樣的監控解決方案。但是它是不同的,因為它的用例擴展到:
分布式事務監視
性能和延遲優化
根本原因分析
服務依賴性分析
分布式上下文傳播
Jaeger 是一種由 Uber 構建的開源技術。您可以在其網站上找到詳細的文檔,并在 GitHub 上找到其源代碼。
3、Linkerd
與 Envoy Proxy 的 Lyft 一樣,Uber 將 Linkerd 開發為一個開源解決方案,以將其服務保持在生產級別。在某些方面,Linkerd 就像 Envoy 一樣,因為兩者都是 Service Mesh 工具,用以在不需要配置或代碼更改的情況下提供平臺范圍的可觀測性、可靠性和安全性。
然而,兩者之間有一些細微的差別。雖然 Envoy 和 Linkerd 作為代理,可以在連接的服務上報告,但 Envoy 并不像 Linkerd 那樣被設計成 Kubernetes 入口控制器。Linkerd 的顯著特點包括:
支持多種平臺(Docker、Kubernetes、DC/OS、Amazon ECS 或任何單機)
用于統一多個系統的內置服務發現抽象
支持 GRPC、HTTP/2 和 HTTP/1.x 請求以及所有 TCP 通信
您可以在 Linkerd 的網站上閱讀更多關于它的信息,并在 GitHub 上訪問它的源代碼。
4、Helm
Helm 基本上是 Kubernetes 的包管理器。如果您使用過 ApacheMaven、MavenNexus 或類似的服務,您將了解 Helm 的目的。Helm 幫助您管理 Kubernetes 應用程序。它使用“helm charts”定義、安裝和升級最復雜的 Kubernetes 應用程序。Helm 并不是實現這一點的唯一方法;另一個流行的概念是 KubernetesOperators,它由 RedHat Openshift4 使用。
您可以按照文檔中的快速入門指南(https://github.com/helm/helm)或 Github 指南來嘗試 Helm。
5、Etcd
Etcd 是一個分布式的、可靠的鍵值對數據存儲,用于存儲分布式系統中最關鍵的數據。其主要特點是:
定義明確、面向用戶的 API(gRPC)
具有可選客戶端證書身份驗證的自動 TLS
速度(以每秒 10000 次寫入為基準)
可靠性(采用 Raft 分布式)
Etcd 被用作 Kubernetes 和許多其他技術的內置默認數據存儲。也就是說,它很少獨立運行或作為單獨的服務運行;相反,它使用集成到 Kubernetes、OKD/OpenShift 或其他服務中的服務。還有一個 Etcd 運營商來管理其生命周期并解鎖其 API 管理功能:
您可以在 ETCD 的文檔中了解更多信息,并在 Github 上訪問其源代碼。
6、CRI-O
CRI-O 是一個開放容器聯盟(OCI)兼容的 Kubernetes 運行時接口的實現。CRI-O 用于各種功能,包括:
運行時使用 runc(或任何 OCI 運行時規范實現)和 OCI 運行時工具
使用容器/圖像進行圖像管理
使用容器/存儲器存儲和管理圖像層
通過容器網絡接口(CNI)提供網絡支持
CRI-O 提供了大量文檔,包括指南、教程、文章甚至播客,您還可以訪問其 Github 頁面(https://github.com/cri-o/cri-o)。
原文鏈接:
https://opensource.com/article/19/8/cloud-native-projects
譯者介紹:
ArthurGuo 職場老司機。21 世紀初開始擁抱開源,后轉型項目管理。現在某云計算公司擔任技術總監。掌握多門計算機語言,但更擅長人類語言。愛玩文字,不喜毒舌。