關於調整 Kubernetes 中的 OCI 佇列用戶規模
此播放手冊說明如何使用 Oracle Cloud Infrastructure (OCI) 佇列的功能，並提供符合大多數需要動態調整功能之使用案例的處方，這些案例以從屬端需求的量為基礎，而不會發生背壓或效能瓶頸問題。
您可以將微服務部署到 Oracle Kubernetes Engine (OKE)，此引擎會處理來自 OCI Queue 的訊息，然後利用佇列深度來水平擴展 OKE 叢集上執行的微服務執行處理。此範例包含訊息產生器，您可以從任何地方執行；例如，從本機機器或作為另一個容器或 VM 的一部分。
此手冊還提供程式碼和詳細的設定指示，您可以在 Oracle-DevRel GitHub 儲存區域中找到這些指示 (您可以從此手冊的「瀏覽更多」區段存取)。此解決方案提供所有 Java 程式碼、命令檔和組態檔，以及建置、部署和執行組建區塊的詳細步驟。本文件將提供架構檢視並檢查建置的重要元素，包括找出將修改程式碼的部分，以符合您需求的解決方案。
瞭解 OCI 佇列 API
雖然「佇列」可以從需求波動引發應用程式，但當使用者涉及時，您不想要在訊息建立與訊息處理之間傳送許多時間。因此，後端需要能夠根據需求動態調整規模。需求是由位於佇列內的訊息數目所決定；訊息越多代表需求越多，就需要花費更多的計算工作。相反地，空白佇列代表沒有需求，因此最少需要後端資源。動態調整規模可解決這些常數變動。
架構
此架構要求佇列位於我們可見的容錯域之外的訊息，因為它是完全受管理的服務。
在 OCI 中，您可以使用從屬端管理的節點或 Oracle 管理的節點來執行 Kubernetes。此案例使用較舊的方法從屬端節點，因此您需要連附至叢集的運算節點。這些節點最好分散在可用性區域內的容錯域。
注意：
在本手冊中，需求產生來自本機機器，因此不在 OCI 環境內。最後兩個主要元素會控制縮放比例。首先，會定期呼叫 OCI 函數並擷取佇列深度的詳細資訊。若要抽象識別佇列深度的方式，請使用有助於呼叫 OCI 函數的 API 閘道。
最後，我們需要輔助服務 (例如 Vault)，以儲存存取佇列的憑證、監視一般健康觀察等等。
- 本機代管的產生器會將訊息放入 OCI 佇列中。
- 我們的 OCI 用戶執行處理會從佇列擷取訊息。在代碼內，耗用率會透過使用延遲來限制。這樣可確保供應商產生的訊息比單一使用者可以從佇列中移除的訊息多。因此，調整機制將會運作。
- Kubernetes 排定工作定期支援 KEDA 呼叫發布的 API 以取得佇列上的訊息數目。
- API 閘道會將要求導向 OCI 函數的執行處理。
- OCI 函數會查詢 OCI 佇列。
- 傳回回應，這會導致 KEDA 觸發增加或減少微服務的執行處理。
- 區域
OCI 區域是一個本地化的地理區域，其中包含一或多個資料中心 (稱為可用性網域)。區域與其他區域無關，因此廣大的距離可加以區隔 (跨國家或甚至洲)。
- 可用性網域
可用性網域是區域內的獨立資料中心。每個可用性網域中的實體資源會與其他可用性網域中的資源隔離，以提供容錯能力。可用性網域並不共用基礎設施服務，例如電力、散熱冷卻系統或內部可用性網域網路。因此，一個可用性網域發生失敗並不會影響區域中的其他可用性網域。
- 容錯域
容錯域是可用性網域內的一組硬體和基礎設施。每個可用性網域都有三個容錯域，具備獨立電源和硬體。當您將資源分散到多個容錯域時，您的應用系統就可容忍容錯域中的實體伺服器故障、系統維護以及電源故障。
- 區間
區間是 OCI 租用戶內的跨區域邏輯分割區。使用區間組織您的 Oracle Cloud 資源、控制對資源的存取，以及設定使用量配額。若要控制每個區間中資源的存取，您可以定義原則以指定可存取資源的人員及可執行的動作。
- 虛擬雲端網路 (VCN) 和子網路
VCN 是您在 OCI 區域中設定的可自訂軟體定義網路。就像傳統的資料中心網路，VCN 可讓您完全控制網路環境。VCN 可以有多個非重疊 CIDR 區塊，而您可以在建立 VCN 之後進行變更。您可以將 VCN 區隔成子網路，然後對區域或可用性網域進行調整。每個子網路都是由不與 VCN 中其他子網路重疊的連續位址範圍所組成。您可以在建立子網路後變更其大小。子網路可以是公用網路或專用子網路。
- 運算執行處理
OCI 運算可讓您佈建及管理運算主機。您可以按照資源需求 (CPU、記憶體、網路頻寬與儲存體) 啟動具有資源配置的運算執行處理。建立運算執行處理之後，您可以安全地存取、重新啟動、連附及取消連附磁碟區，以及在不需要時予以終止。
- 函數
Oracle Functions 是一個完全託管、多租用戶、可高度擴展、隨選、Functions-as-a-Service (FaaS) 平台。它由 Fn 專案開放原始碼引擎提供技術支援。函數可讓您部署程式碼，然後直接呼叫程式碼或觸發程式以回應事件。Oracle Functions 使用 OCI Registry 中代管的 Docker 容器。
- 容器登錄
OCI Registry 是 Oracle 管理的登錄，可讓您簡化開發到生產的工作流程。登錄可讓您輕鬆儲存、共用及管理開發使用者自建物件，例如 Docker 映像檔。OCI 的高可用性且可擴展架構可確保您可以可靠地部署和管理應用程式。
- Kubernetes 容器引擎
OCI Container Engine for Kubernetes 是一項完全託管、可擴展且高可用性的服務，可用來將容器化應用程式部署到雲端。您可以指定應用系統所需的運算資源，而 Kubernetes 的容器引擎則會在現有租用戶的 OCI 上佈建這些資源。Kubernetes 的容器引擎使用 Kubernetes 將跨主機叢集的容器化應用程式部署、擴展及管理自動化。
- API 閘道
Oracle API Gateway 可讓您發布內含端點的 API，以管理函數 (例如函數、微服務以及其他應用程式介面) 的可見性。端點對後端解決方案提供精細的安全控制，並且抽象化 API 的導入方式。
- 佇列
佇列是無伺服器高度可擴展的非同步通訊機制。最適合使服務與訊息傳遞脫鉤。
注意事項
將微服務部署到 Kubernetes 以處理來自 OCI 佇列的訊息時，您應該考慮下列事項：
- 佇列原則的考量
控制和設定 OCI 佇列的原則和建立和使用訊息的原則是分開的。這樣可以讓您對透過 API 提供的作業提供精細的控制。這表示您需要對應用程式的需求和安全需求提供一些考量。對於生產環境，建議使用嚴格的控制；此實作使用寬鬆的組態設定，將導致示範無法運作的組態錯誤降到最低。
- Kubernetes 調整規模限制的考量
您必須考量後端調整規模的速率和限制。您需要解決一些因素，例如佇列在啟動微服務的其他執行處理之前可以得到的深度。應執行微服務的其他執行處理數目上限。雖然實際上，如果有人 (蓄意或意外) 以錯誤的訊息開始浪費您的佇列，但您不想吸收剩餘運算能力的成本。您也需要考慮縮減微服務其他執行處理的速度。速度太快，您會發現環境持續啟動及停止服務。無論微服務的效率如何，啟動及停止服務執行處理所需的總成本都會是最終成本的首要費用。
- 調整控制項的考量
控制縮放的最後一個層面是您是否要套用縮放比例以及如何控制縮放比例。此案例運用稱為 KEDA (Kubernetes Event Driven Autoscaler) 的 CNCF 專案。除了後端調整如何執行之外，您還必須考量如何呼叫 API。在此情況下，您可以設定 Kubernetes 排定工作 (當工作是由工作節點執行時，圖表會反映此流程) 以呼叫 API。
必要條件
開始之前，您需要解決此處所述的先決條件來準備環境。
- 若要產生訊息，您需要安裝 Java 8 或更新版本 (Java 8 與 Apache Maven)。
- 與 OCI 佇列的互動將需要使用者和關聯的證明資料才能進行存取。設定這些原則：
- 設定此原則以識別您將使用的區間 (
compartment-name)：allow any-user to manage queues in compartment compartment-name - 若要限制使用者只讀取或寫入 OCI 佇列，請建立名為
MessageConsumers和MessageProducers的 OCI 群組，然後將適當的使用者配置給這些群組。請使用下列原則：allow group MessageConsumers to use queues in compartment compartment-name allow group MessageProducers to use queues in compartment compartment-name - 為產生器從屬端提供標準 OCI 組態屬性，以便能夠向 OCI 進行認證並使用該 API。
- 您需要設定原則以支援動態行為，因為新資源即將到來，且需要存取佇列。建立「動態群組」，並使用您需要彈性控制的資源來設定這些原則。由於此控制項在 OCI 內發生，請使用執行處理主體。呼叫此群組
queue_dg。請使用下列原則敘述句：
其中ALL {instance.compartment.id='instance Compartment id (OCID)'} allow dynamic-group queue_dg to use queues in compartment queue_parent_compartmentinstance Compartment id (OCID)是包含工作節點的區間。
- 設定此原則以識別您將使用的區間 (