企業的效益與挑戰 — 多雲端平台Part2

在多雲基礎架構中的容器編排(Orchestration)與管理

在一個理想的世界中，IT 團隊將擁有一個完全異質的環境來部署他們的整個基礎架構。但現實可能完全不同。一個企業可能有一個難以維護或不符合當前資安或稽核標準的古老系統。

在多雲環境中部署新應用程式可能會產生基礎架構管理問題，因為每個CSP都有不同的管理界面，需要不同的訪問機制。減緩這一種問題的一個方法是在所有CSP中使用容器。但那些具有資安全背景的人看到這個，然後就會想，“等等，容器只是虛擬機 (VM) 的一種說法，對吧？”

不完全是。儘管 VM 和容器有許多相似之處，但也存在一些關鍵差異。容器是設計為與作業系統(OS)無關的隔離系統。但與 VM 不同的是， Container image不是一個完整的OS。相反的，它運用了 OS Kernel的extensions來運作特定的應用程式或功能。因此，Container 調和了應用程式對OS所做的事情。

這意味著Container image比 VM 更小，更是目的性的使用(也就是使用單一種的功能或作業)。一個Container image可能運行 MySQL 或 Apache，並且多個Container image可以存在於一個OS中。這讓一個應用程式與另一個應用程式是隔離的，並使企業能夠很容易的將應用程式從一個CSP重新部署到另一個CSP，但也同時需要考慮到資料是否需要在所有 CSP 之間同步的問題。

容器也有額外的資安優勢。從容器中刪除不必要的東西，只留下應用程式及其需要的library，駭客就只能有更小的攻擊面積。即使駭客確實設法利用容器上未修補的漏洞，他們也會遇到困難。這是因為駭客通常用來在OS中移動的native tool將不存在。如果偵測到容器的異常後，也只需刪除容器並使用新修補的版本替換它即可，因為問題通常只會存在於容器內部。

儘管容器帶來了額外的效益，但它們也帶來了挑戰，包括我們在本文中討論的管理、安全和複雜性問題。

強大的Orchestration介面將非常重要

雲端市場不斷變化，每個CSP都不斷添加新功能並定期強化其服務。 雲端市場是動態的，這意味著我們的架構必須能夠快速適應新功能。 我們三年前部署的 Web application看起來與今天部署的 Web application完全不同，兩年後它們將再次被徹底改造。

IT基礎設施的遷移一直都很痛苦，今天仍然存在大量古老系統就證明了這一點，當然還有老闆想省錢的問題。 但遷移是新常態。 容器幫助企業適應快速變化的基礎設施需求，但這只是第一步。 除了使用容器之外，企業還需要使用管理工具和編排工具來有效地管理所有CSP的容器。 使用這些工具，企業將能夠快速利用新功能和服務。

上一篇討論過的容器部署的好處之一是它不依賴於底層硬體。 由於容器在平台中內建了應用程式和所有必需的library，因此我們可以將其部署在任一種環境中，並在所有已部署平台上以相同的方式運行。 然而，在多雲環境中，容器之間會有相依性。 因此，我們的管理系統不僅需要能夠管理容器本身，還需要能夠管理與其關聯的所有相依性的容器或集群容器。 它需要了解容器之間的關係，並能夠在多雲架構中部署這些容器及其相依的容器。

一般來說，容器管理平台需要能做到以下的事情:

• 盡可能跟CSP沒有關係，因為使用某一個家CSP的管理平台也同時可能有Vendor lock-in與 CSP單點故障的問題。
• 自動化部署和退役過程。
• 管理搭載容器的OS。
• 監控容器內運行的應用程序的健康狀況。
• 隨應用程序的附載而擴展。
• 允許所有通訊和管理的安全連接。

我們的公司可能還有其他特定需求。 與任何其他技術選項一樣，最好在開始測試過程之前列出要求。 這將為我們提供一個正式的清單來驗證容器管理平台的測試。

簡單的管理平台非常適合小型的多雲運作。 在 20 個容器中運行的五個應用程式易於手動管理。 但隨著多雲架構的發展，手動管理將是不足的。 這就是容器編排(container orchestration)發揮作用的地方。

Orchestration使我們能夠使用腳本來管理數千個容器中的數十個應用程式，以自動化許多流程，例如provision新容器的流程、監控這些容器上的服務或停用退役的容器。

容器編排工具使用 JSON 或 YAML 檔案來定義特定容器。 該檔案包含編排工具部署容器所需的資訊，例如 host name、IP address、open port、已安裝的應用程式、日誌記錄工具等。 更詳細的文件內容可以參考 Docker 的 JSON 容器檔案的部分示例。

以這種方式完全定義容器可以更容易的進行跨CSP的部署和重新部署容器。 對特定容器進行變更也更容易，而無需直接log in到容器中。 例如，如果我們需要將更多容器部署到流量大幅增加的CSP，我們可以快速完成。 我們還可以對orchestration進行編寫，使其在網路流量或CPU使用率達到某個閾值時自動擴展。

編排工具功能強大，它們為我們在部署多雲架構方面提供了很大的靈活性。 但是我們需要知道如何正確使用它們。 企業（尤其是剛接觸多雲架構的）面臨的一項挑戰是"學習編排工具的全部功能。 第二個是將過多的控制權交給自動化"。 由於這些原因，通常需要時間來完全理解這些功能並充分利用編排工具中的可用功能。

在多雲環境中建立容器基礎架構

儘管容器具有高度可移植性，所以非常適合多雲部署，但它們的可移植性也存在侷限性。 在規劃多雲架構時需要牢記這一事實。

鑑於多雲部署的複雜性，規劃過程需要幾個步驟。 最重要的事情是記錄一切。 該文件對於團隊中的其他人參考至關重要。 三年後，當我們回過頭來試著記住為什麼做出某些決定時，文件會派上用場。 良好的文件使開發人員、IT 人員、資安團隊和管理人員更容易根據一組通用標準一起作業。 它還確保每個人都了解多雲部署專案的功能和目標。

接下來，我們需要決定一個container engine。 大多數開發人員使用 Linux 作為運行容器的engine。 但是有一些容器服務運行在 Windows 服務上。 無論我們決定在哪個平台上運行，重要的是要確保我們計劃使用的所有CSP都支援它。

我們還需要選擇管理工具。 確保工具能夠支援我們正在使用的CSP，並且它足夠靈活以支援預期的成長。 確保它支援 HA 和redundancy，因為我們可不希望我們的編排工具意外掛掉。

Stroage也是規劃過程的重要部分。 我們要記住，這些容器系統被設計為ephemeral，並且可以根據需求進行調整。 存儲需求是永久性的，具有full redundancy 和backups。 提前計劃資料的存儲位置，並了解每個CSP中的容器將如何access這些資料。

最後，了解網路將如何在所使用的CSP內部和各CSP之間工作。 容器會直接連接到host system，還是只會在內部網段上運行？ 不同的CSP將如何相互連接或peering？ 我們是否可以在管理VPC的不同CSP之間建立site-to-site VPN，或者我們是否必須找到另一種方式來連接(例如使用CSP的網路專線)？

在多雲中的K8S(Kubernetes)

K8S是最廣泛採用的容器管理和編排工具，尤其是在多雲環境中。 K8S最初由 Google 開發，目前得到 GCP的GKE、AWS的 EKS、 Azure的AKS、OpenStack 和許多其他CSP的支援。

K8S的關鍵是它的靈活性。 它允許我們跨多雲架構中的所有CSP部署完全配置的系統。 我們首先構建運行 Web Application所需的各種組件。 然後，我們可以將這些組件cluster在一起。 接下來，我們可以跨不同的工作負載reuse 這些clustered components並根據需求部署它們。

使用 K8S的API，可以將新系統快速部署到不同的CSP。處理security patch也更容易。當漏洞被修補時，我們可以在整個架構中構建並自動部署新容器。這使得易受攻擊的系統不太可能長時間暴露在網路上(如果漏洞發現得夠快的話)。

K8S 在管理已經部署容器方面非常聰明。它保持對每個容器狀態的感知，並監控每個容器上正在使用的系統資源。如前面所述，我們可以將 K8S 配置為在 CPU 資源達到一定閾值時自動部署新容器。K8S 還可以使用 Helm(package manager)和 Kubespray 等多個專案進行延伸，用於跨多個環境建立K8S cluster。

最後，K8S 支援集中式日誌記錄以提高資安感知。從部署的容器中收集日誌使團隊能夠分析它們以發現潛在的資安威脅和提高效能的機會。團隊可以將 K8S 日誌直接串流到 SIEM 系統中，進行自動化關聯和分析過程。

DevOps與多雲架構

DevOps 非常適合構建多雲環境。 DevOps 強調通過將開發和維運合併為一個功能來管理這兩個部分，從而縮短程式開發的生命週期，完美地反映了多雲架構的快節奏本質。

與多雲部署一樣，轉向 DevOps 開發過程需要仔細規劃，並且可能需要重新設計底層系統。 但是 DevOps 開發週期的效益使多雲的遷移是值得的。

具體來說，容器的使用讓我們能夠快速啟動測試環境以進行小型專案的作業。 隨著短期作業的完成，可以刪除這些容器，並且可以重新配置服務以用於其他用途。 多雲環境允許 DevOps 團隊快速測試 CSP提供的新功能。 它們還允許開發人員在每次測試代碼時快速 建立新的基礎架構。 開發人員可以運行測試、刪除容器、更改代碼、快速啟動一個新的相同容器並重新運行測試，而不是在同一個 VM 上進行反覆測試。 這確保了每次都有新的測試環境。 雖然這種類型的快速測試可以使用VM來完成，但容器讓這個過程更容易。

Provisioning

DevOps 的目標之一是快速將新需求納入應用程式的開發過程。 這使得該方法非常適合構建基於容器的多雲架構。 構建和部署容器以適應新功能並同時跨多個CSP部署這些容器只是編輯幾個文件和進行一些 API 呼叫的問題。 使用像 CHEF/ terraform這樣的工具來provisioning VM也可以完成同樣的事情，但是容器再次簡化了這個過程。 這種provisioning 的靈活性發揮了 DevOps 流程的優勢。

容器的使用是完美的搭配，因為它減輕了許多傳統上伴隨著 DevOps 雲端配置的特定於平台的問題。 通過在基於容器的平台上進行標準化，應用程式的效能有望在CSP之間保持一致。 雖然，情況並非總是如此。 容器確實使部署在不同的CSP上變得更容易，但是有很多變量可以用來衡量效能，一個CSP能與另一個CSP有明顯的不同。

所有這些都假設基礎資安和管理流程已經到位並得到遵循。 只要將安全性內建到 DevOps 和容器流程中，我們就可以快速安全地執行配置。

管理

正確管理資源對於成功的 DevOps 和多雲部署至關重要。 多雲部署本質上是複雜的，包含許多移動組件，這就是 K8S 等管理工具如此重要的原因。 但是一個工具的好壞取決於它背後的管理策略。

適當的多雲管理通過提供已部署系統的standardized view和已部署容器的通用日誌記錄來加強 DevOps 流程。 當需要改良代碼或建立新代碼時，我們可以access日誌以進行故障排除並更好地了解正在使用的資源。

良好的管理還使企業能夠為 DevOps 團隊提供客製的IT服務。 使用多個CSP意味著 DevOps 團隊可以access他們想要用的服務清單。 使用這些服務，企業基本上可以通過適當的管理為 DevOps 團隊提供 IaaS。

使用Terraform進行Orchestration

Terraform 是另一個廣泛使用的容器管理編排工具。 Terraform 將基礎設施視為代碼並維護受版本控制的container repo。這使得追蹤變更和在需要時重新檢視舊容器變得容易。

這也意味著動態性的變更可以快速保存為updated repo或現有容器的分支。我們可以存儲特殊的配置需求或變更，以備日後所需。與 K8S 非常相似，Terraform 允許我們一起部署clustered systems。如果團隊需要快速重新部署應用程式或加新的CSP，只需呼叫 API 即可複製現有基礎架構。

Terraform 還有助於建立執行計劃。這些計劃可幫助我們了解進行 API 呼叫時會發生什麼。因此，團隊可以確保在實際部署之前，所有內容都會按預期的進行。 Terraform 還允許我們使用 DNS 和 CNAME entries。與其依賴許多CSP提供的難記的主機名，我們可以使用已經預定好的 DNS 名稱配置新容器，並以更快的速度啟動和運行所有內容。

結論

利用容器在不同的CSP之間進行快速部署才是能真正自我適應多雲架構。 儘管使用容器極大地提高了組織部署的敏捷性，但也意味著更大的複雜性。

處理這種複雜性的最佳方法是使用容器編排工具。 編排工具使我們能夠集中和自動化跨所有CSP的所有容器的部署、管理和監控。

這種類型的部署需要有據可查的底層流程和策略，包括資安策略，以確保我們在所有CSP中一致且安全地部署基礎架構。