容器化技術生態系統正在快速發展和變化,因此該領域缺乏良好的工作實務。 然而,Kubernetes 和容器的使用越來越多,既用於現代化遺留應用程序,也用於開發現代雲端應用程式。
團隊
如何知道您的公司是否準備好在生產環境中部署容器
根據
В
儘管人們對容器的興趣和採用不斷增長,但由於技術不成熟和缺乏專業知識,將其投入生產需要一個學習曲線。 組織必須現實地對待需要應用程式容器化的業務流程。 IT 領導者應該評估他們是否具備滿足快速學習需求的技能。
在生產中使用容器時最常見的錯誤
組織經常低估在生產中操作容器所需的工作量。
如何確保容器安全
安全問題不能「稍後」處理。 它必須內建在 DevOps 流程中,這就是為什麼有一個特殊術語 - DevSecOps。 組織需要製定計劃
- 將掃描應用程式映像漏洞的過程整合到持續整合/持續交付 (CI/CD) 管道中。 應用程式在軟體建置和啟動階段進行掃描。 強調需要掃描和識別開源元件、函式庫和框架。 開發人員使用舊的、易受攻擊的版本是容器漏洞的主要原因之一。
- 透過網路安全中心測試改進您的配置(
CIS ),適用於 Docker 和 Kubernetes。 - 確保執行存取控制、確保職責分離並實施秘密管理政策。 安全通訊端層 (SSL) 金鑰或資料庫憑證等敏感資訊由協調器或第三方管理服務加密並在執行時公開
- 透過管理安全策略來避免升高容器,以減少潛在的違規風險。
- 使用提供白名單、行為監控和異常檢測的安全工具來防止惡意活動。
- 利用 Kubernetes 的內建功能。 使用角色為使用者設定存取權限。 確保不向單一實體授予不必要的權限,即使可能需要一些時間來考慮所需的最低權限。 授予叢集管理員廣泛的權限可能很誘人,因為這最初可以節省時間。 然而,帳戶中的任何妥協或錯誤都可能導致以後的災難性後果。
- 避免重複的存取權限。 有時,不同的角色重疊可能很有用,但這可能會導致操作問題,並且在刪除權限時也會產生盲點。 刪除未使用和不活動的角色也很重要。
- 設定網路策略:隔離模組以限制對其的存取; 使用標籤明確允許網路存取那些需要它的模組; 明確允許那些需要相互通訊的模組之間進行通訊。
如何組織對容器及其中的服務的監控
安全和監控 -
- 嘗試結合監視主機系統來監視容器或其中的服務的狀態。
- 尋找與容器編排深度整合的供應商和工具,尤其是 Kubernetes。
- 選擇使用分析和/或機器學習提供詳細日誌記錄、自動服務發現和即時建議的工具。
- 使用工具自動發現和追蹤容器指標,關聯 CPU、記憶體和正常運行時間等效能指標。
- 根據容器監控指標預測容量耗盡日期,確保最佳容量規劃。
- 監控容器化應用程式的可用性和效能,這對於容量規劃和效能問題故障排除非常有用。
- 透過為容器及其託管環境提供管理和擴展支援來實現工作流程自動化。
- 自動執行存取控制以監控您的使用者群組、停用過時的帳戶和來賓帳戶,並刪除不必要的權限。
- 確保您的工具集可以跨多個環境(雲端、本地或混合)監控這些容器和應用程序,以視覺化和基準化跨基礎設施、網路、系統和應用程式的效能。
如何儲存資料並確保其安全
隨著有狀態工作容器的興起,客戶端需要考慮主機外部資料的存在以及保護該資料的需要。
根據
資料加密是主要的安全策略(64%),但受訪者也使用執行時間監控
(49%)、掃描登錄中的漏洞 (49%)、掃描 CI/CD 管道中的漏洞 (49%) 以及透過執行時間保護來阻止異常 (48%)。
- 選擇基於原則的儲存解決方案
微服務架構 。 最好專注於那些滿足容器服務的資料儲存需求、硬體獨立、API驅動、具有分散式架構、支援本地部署和公有雲部署的。 - 避免專有插件和接口。 選擇提供 Kubernetes 整合並支援 CSI(容器儲存介面)等標準介面的供應商。
如何使用網絡
在傳統的企業網路模型中,IT 團隊為每個專案創建網路化的開發、測試、品質保證和生產環境,但並非總是能很好地適應持續開發工作流程。 此外,容器網路跨越多個層。
В
- 調度在同一節點上的 Pod 必須能夠在不使用 NAT(網路位址轉換)的情況下與其他 Pod 進行通訊。
- 在特定節點上運行的所有系統守護程序(kubelet 等後台程序)都可以與在同一節點上運行的 pod 進行通訊。
- Pod 使用
主機網絡, 必須能夠在不使用 NAT 的情況下與所有其他節點上的所有其他 Pod 進行通訊。 請注意,主機網路僅在 Linux 主機上支援。
網路解決方案必須與 Kubernetes 原語和策略緊密整合。 IT領導者應該努力實現高度的網路自動化,並為開發人員提供合適的工具和足夠的靈活性。
- 了解您的 CaaS(容器即服務)或 SDN(軟體定義網路)是否支援 Kubernetes 網路。 如果沒有或支援不足,請為容器使用 CNI(容器網路介面)網路接口,它支援必要的功能和策略。
- 確保您的 CaaS 或 PaaS(平台即服務)支援建立入口控制器和/或負載平衡器,以在叢集節點之間分配傳入流量。 如果這不是一個選項,請探索使用第三方代理或服務網格。
- 對您的網路工程師進行有關 Linux 網路和網路自動化工具的培訓,以縮小技能差距並提高敏捷性。
如何管理應用程式生命週期
為了實現自動化、無縫的應用程式交付,您需要使用其他自動化工具(例如基礎設施即程式碼 (IaC) 產品)來補充容器編排。 其中包括 Chef、Puppet、Ansible 和 Terraform。
還需要用於建立和推出應用程式的自動化工具(請參閱“
- 根據大小、許可和開發人員添加組件的靈活性為基礎容器映像設定標準。
- 使用組態管理系統來管理基於公用或私人儲存庫中的基礎映像分層配置的容器的生命週期。
- 將您的 CaaS 平台與自動化工具集成,以自動化您的整個應用程式工作流程。
如何使用協調器管理容器
部署容器的核心功能是在編排和規劃層提供的。 在調度期間,根據編排層要求,容器被放置在叢集中最優化的主機上。
Kubernetes 已成為事實上的容器編排標準,擁有活躍的社區,並得到大多數領先商業供應商的支持。
- 定義安全控制、監控、策略管理、資料持久性、網路和容器生命週期管理的基本要求。
- 根據這些要求,選擇最適合您的要求和用例的工具。
- 使用 Gartner 研究(參見“
如何選擇 Kubernetes 部署模型 」)了解不同 Kubernetes 部署模型的優缺點,並選擇最適合您的應用程式的模型。 - 選擇一個能夠為跨多個環境的工作容器提供混合編排、緊密的後端整合、通用管理計劃和一致的定價模型的供應商。
如何利用雲端提供者的能力
IaaS 雲端提供隨選資源消耗、快速可擴充性和
主要雲端託管服務提供者如下表所示:
雲端提供者
服務類型
產品/服務
阿里巴巴
原生雲端服務
阿里雲容器服務、阿里雲Kubernetes容器服務
亞馬遜網絡服務(AWS)
原生雲端服務
Amazon Elastic Container Services (ECS)、Amazon ECS for Kubernetes (EKS)、AWS Fargate
巨型蜂群
MSP
Giant Swarm 管理的 Kubernetes 基礎設施
谷歌
原生雲端服務
Google容器引擎(GKE)
IBM
原生雲端服務
IBM 雲 Kubernetes 服務
Microsoft微軟
原生雲端服務
Azure Kubernetes 服務、Azure Service Fabric
神諭
原生雲端服務
適用於 Kubernetes 的 OCI 容器引擎
Platform9
MSP
託管 Kubernetes
紅帽
託管服務
OpenShift 專用和在線
VMware的
託管服務
雲端 PKS(測試版)
Mail.ru 雲端解決方案*
原生雲端服務
Mail.ru 雲端容器
* 我們不會隱藏它,我們在翻譯過程中將自己添加到這裡:)
公有雲供應商也在新增功能並發布本地產品。 在不久的將來,雲端供應商將開發對混合雲和多雲環境的支援。
- 客觀評估您的組織部署和管理適當工具的能力,並考慮替代雲端容器管理服務。
- 仔細選擇軟體,盡可能使用開源軟體。
- 選擇在混合環境中具有通用操作模型、提供聯合叢集單一管理平台管理的供應商,以及可以輕鬆自架 IaaS 的提供者。
- 尋找支援開箱即用的高可用性的發行版是值得的。 這包括對多種主要架構、高可用 etcd 元件以及備份和復原的支援。
- 為了確保 Kubernetes 環境中的行動性,最好選擇支援多種部署模式(從本地到混合雲再到多雲)的雲端供應商。
- 還應根據設定、安裝和叢集創建以及更新、監控和故障排除的難易程度來評估提供者的產品。 基本要求是支援零停機的全自動叢集更新。 您選擇的解決方案還應該允許您手動執行更新。
- 從安全和治理的角度來看,身分和存取管理都很重要。 確保您選擇的 Kubernetes 發行版支援與您內部使用的身份驗證和授權工具整合。 RBAC 和細粒度存取控制也是重要的功能集。
- 您選擇的發行版必須具有涵蓋各種不同應用程式或基礎設施要求的本機軟體定義網路解決方案,或支援一種流行的基於 CNI 的網路實現,包括 Flannel、Calico、kube-router 或 OVN。
一項調查結果表明,容器引入生產正在成為主要方向。
正如您所看到的,27% 的受訪者已經在工作中使用容器,63% 的受訪者正在計劃這樣做。
В
文章由雲端平台團隊撰寫
關於該主題還可以閱讀什麼:
來源: www.habr.com