俯瞰云原生,这便是供应层
來源 | K8sMeetup社區
作者 |?Catherine Paganini,Jason Morgan
頭圖?|?下載于視覺中國
在都在說云原生,它的技術圖譜你真的了解嗎?中,我們對 CNCF 的云原生技術生態做了整體的介紹。從本篇開始,將詳細介紹云原生全景圖的每一層。
云原生全景圖的最底層是供應層(provisioning)。這一層包含構建云原生基礎設施的工具,如基礎設施的創建、管理、配置流程的自動化,以及容器鏡像的掃描、簽名和存儲等。供應層也跟安全相關,該層中的一些工具可用于設置和實施策略,將身份驗證和授權內置到應用程序和平臺中,以及處理 secret 分發等。
接下來讓我們看一下供應層的每個類別,它所扮演的角色以及這些技術如何幫助應用程序適應新的云原生環境。
自動化和配置
是什么
自動化和配置工具可加快計算資源(虛擬機、網絡、防火墻規則、負載均衡器等)的創建和配置過程。這些工具可以處理基礎設施構建過程中不同部分的內容,大多數工具都可與該空間中其他項目和產品集成。
解決的問題
傳統上,IT 流程依賴高強度的手動發布過程,周期冗長,通常可達 3-6 個月。這些周期伴隨著許多人工流程和管控,讓生產環境的變更非常緩慢。這種緩慢的發布周期和靜態的環境與云原生開發不匹配。為了縮短開發周期,必須動態配置基礎設施且無需人工干預。
如何解決問題
供應層的這些工具使工程師無需人工干預即可構建計算環境。通過代碼化環境設置,只需點擊按鈕即可實現環境配置。手動設置容易出錯,但是一旦進行了編碼,環境創建就會與所需的確切狀態相匹配,這是一個巨大的優勢。
盡管不同工具實現的方法不同,但它們都是通過自動化來簡化配置資源過程中的人工操作。
對應工具
當我們從老式的人工驅動構建方式過渡到云環境所需的按需擴展模式時,會發現以前的模式和工具已經無法滿足需求,組織也無法維持一個需要創建、配置和管理服務器的 7×24 員工隊伍。Terraform 之類的自動化工具減少了擴展數服務器和相關網絡以及防火墻規則所需的工作量。Puppet,Chef 和 Ansible 之類的工具可以在服務器和應用程序啟動時以編程方式配置它們,并允許開發人員使用它們。
一些工具直接與 AWS 或 vSphere 等平臺提供的基礎設施 API 進行交互,還有一些工具則側重于配置單個計算機以使其成為 Kubernetes 集群的一部分。Chef 和 Terraform 這類的工具可以進行互操作以配置環境。OpenStack 這類工具可提供 IaaS 環境讓其他工具使用。
從根本上講,在這一層,你需要一個或多個工具來為 Kubernetes 集群搭建計算環境、CPU、內存、存儲和網絡。此外,你還需要其中的一些工具來創建和管理 Kubernetes 集群本身。
在撰寫本文時,該領域中有三個 CNCF 項目:KubeEdge(一個沙盒項目)以及 Kubespray 和 Kops(后兩個是 Kubernetes 子項目,雖然未在全景圖中列出,但它們也屬于 CNCF)。此類別中的大多數工具都提供開源和付費版本。
Container Registry
是什么
在定義 Container Registry 之前,我們首先討論三個緊密相關的概念:
容器是執行流程的一組技術約束。容器內啟動的進程會相信它們正在自己的專用計算機上運行,而不是在與其他進程(類似于虛擬機)共享的計算機上運行。簡而言之,容器可以使你在任何環境中都能控制自己的代碼運行。
鏡像是運行容器及其過程所需的一組存檔文件。你可以將其視為模板的一種形式,可以在其上創建無限數量的容器。
倉庫是存儲鏡像的空間。
回到 Container Registry,這是分類和存儲倉庫的專用 Web 應用程序。
鏡像包含執行程序(在容器內)所需的信息,并存儲在倉庫中,倉庫被分類和分組。構建、運行和管理容器的工具需要訪問(通過引用倉庫)這些鏡像。
解決的問題
云原生應用程序被打包后以容器的方式運行。Container Registry 負責存儲和提供這些容器鏡像。
如何解決
通過在一個地方集中存儲所有容器鏡像,這些容器鏡像可以很容易地被應用程序的開發者訪問。
對應工具
Container Registry 要么存儲和分發鏡像,要么以某種方式增強現有倉庫。本質上,它是一種 Web API,允許容器引擎存儲和檢索鏡像。許多 Container Registry 提供接口,使容器掃描/簽名工具來增強所存儲鏡像的安全性。有些 Container Registry 能以特別有效的方式分發或復制圖像。任何使用容器的環境都需要使用一個或多個倉庫。
該空間中的工具可以提供集成功能,以掃描,簽名和檢查它們存儲的鏡像。在撰寫本文時,Dragonfly 和 Harbor 是該領域中的 CNCF 項目,而 Harbor 最近成為了第一個遵循 OCI 的倉庫。主要的云提供商都提供自己的托管倉庫,其他倉庫可以獨立部署,也可以通過 Helm 之類的工具直接部署到 Kubernetes 集群中。
安全和合規
是什么
云原生應用程序的目標是快速迭代。為了定期發布代碼,必須確保代碼和操作環境是安全的,并且只能由獲得授權的工程師訪問。這一部分的工具和項目可以用安全的方式創建和運行現代應用程序。
解決什么問題
這些工具和項目可為平臺和應用程序加強、監控和實施安全性。它們使你能在容器和 Kubernetes 環境中設置策略(用于合規性),深入了解存在的漏洞,捕獲錯誤配置,并加固容器和集群。
如何解決
為了安全地運行容器,必須對其進行掃描以查找已知漏洞,并對其進行簽名以確保它們未被篡改。Kubernetes 默認的訪問控制比較寬松,對于想攻擊系統的人來說, Kubernetes 集群很容易成為目標。該空間中的工具和項目有助于增強群集,并在系統運行異常時提供工具來檢測。
對應工具
為了在動態、快速發展的環境中安全運行,我們必須將安全性視為平臺和應用程序開發生命周期的一部分。這部分的工具種類繁多,可解決安全領域不同方面的問題。大多數工具屬于以下類別:
審計和合規;
生產環境強化工具的路徑:
代碼掃描
漏洞掃描
鏡像簽名
策略制定和執行
網絡層安全
其中的一些工具和項目很少會被直接使用。例如 Trivy、Claire 和 Notary,它們會被 Registry 或其他掃描工具所利用。還有一些工具是現代應用程序平臺的關鍵強化組件,例如 Falco 或 Open Policy Agent(OPA)。
該領域有許多成熟的供應商提供解決方案,也有很多創業公司的業務是把 Kubernetes 原生框架推向市場。在撰寫本文時,Falco、Notary/TUF 和 OPA 是該領域中僅有的 CNCF 項目。
密鑰和身份管理
是什么
在進入到密鑰管理之前,我們首先定義一下密鑰。密鑰是用于加密或簽名數據的字符串。和現實中的鑰匙一樣,密鑰鎖定(加密)數據,只有擁有正確密鑰的人才能解鎖(解密)數據。
隨著應用程序和操作開始適應新的云原生環境,安全工具也在不斷發展以滿足新的需求。此類別中的工具和項目可用于安全地存儲密碼和其他 secrets(例如 API 密鑰,加密密鑰等敏感數據)、從微服務環境中安全刪除密碼和 secret 等。
解決的問題
云原生環境是高度動態的,需要完全編程(無人參與)和自動化的按需 secret 分發。應用程序還必須知道給定的請求是否來自有效來源(身份驗證),以及該請求是否有權執行操作(授權)。通常將其稱為 AuthN 和 AuthZ。
如何解決
每個工具或項目實施的方法不同,但他們都提供:
安全分發 secret 或密鑰的方法。
身份認證或(和)授權的服務或規范。
對應的工具
此類別中的工具可以分為兩組:
一些工具專注于密鑰生成、存儲、管理和輪轉。
另一些專注于單點登錄和身份管理。
拿 Vault 來說,它是一個通用的密鑰管理工具,可管理不同類型的密鑰。而 Keycloak 則是一個身份代理工具,可用于管理不同服務的訪問密鑰。
在撰寫本文時,SPIFFE/SPIRE 是該領域中唯一的 CNCF 項目。
供應層專注于構建云原生平臺和應用程序的基礎,其中的工具涉及基礎設施供應、容器注冊表以及安全性。本文是詳細介紹了云原生全景圖的最底層。在下一篇文章中,我們將重點介紹運行時層,探索云原生存儲、容器運行時和網絡的相關內容。
原文鏈接:https://thenewstack.io/the-cloud-native-landscape-the-provisioning-layer-explained/
更多閱讀推薦
都在說云原生,它的技術圖譜你真的了解嗎?
SRE 是如何保障穩定性的
如何寫出讓 CPU 跑得更快的代碼?
Serverless 在 SaaS 領域的最佳實踐
云原生人物志|Pulsar翟佳:社區的信任最重要
一目了然的 Docker 環境配置指南
總結
以上是生活随笔為你收集整理的俯瞰云原生,这便是供应层的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 乱中有变,云原生从“大爆发”说起 | C
- 下一篇: 抢先看!Kubernetes v1.21