規劃在已啟用 Azure Arc 的 Kubernetes 上部署容器應用程式

在正式叢集安裝容器應用擴充功能前，請先使用這篇文章。 Azure Arc 上的容器應用程式會使用由 Kubernetes 叢集提供的容量與平台服務。 節點、負載平衡、DNS、出站連接、儲存、身份、日誌記錄及升級等決策都會影響應用程式的可用性。

請利用本文的章節辨識部署需求，並在安裝前驗證前置條件。

規劃範圍

Azure Arc 上的 Container Apps 涵蓋 Azure 資源、現有的 Kubernetes 叢集及已部署的應用程式。 規劃以下區域：

支援的拓撲與版本矩陣

使用受廠商支援也受已啟用 Azure Arc 之 Kubernetes 支援的最新 Kubernetes 修補程式發行版本。 容器應用程式的文件並未為每個發行版公布獨立的 Kubernetes 版本範圍。 在正式安裝或升級前，請向 Microsoft 支援驗證精確的發行版和 Kubernetes 版本。

以下矩陣記錄目前已公布的發行支援情況。 請在每次安裝之前，對照 Azure Arc 已啟用 Kubernetes 叢集的可用延伸模組 與 Azure Arc 上 Azure 容器應用程式 的限制 重新驗證。

這個擴充功能不支援 Windows 節點或 Arm64 叢集。 Arc 擴充框架至少需要一個合適的 linux/amd64 節點，但生產部署則需要足夠多的節點來應付擴充、工作負載、升級與失敗。

叢集上僅能執行一個支援的 KEDA 安裝。 確認 KEDA 是否會由容器應用程式擴充套件安裝，或叢集中已存在。 如果 KEDA 已經存在，請停止並確認支援的共存配置後再繼續。 不要移除現有的 KEDA 安裝或套用未公開的擴充功能設定，因為其他工作負載可能會依賴它。

容量需求

為下列項目規劃容量：

• 容器應用擴充功能所建立的資源中列出的固定及每節點容器應用擴充元件。
• 每個容器應用程式的最大預期複製數。
• 同時執行工作與重試突發高載。
• Dapr 側車與應用程式側車。
• Kubernetes 系統工作負載及其他叢集租戶。
• 節點與延伸模組的滾動升級。
• 高可用性部署中至少有一個節點發生故障。

設定應用程式最大副本數量並不會保留叢集容量。

最小安裝容量

沒有通用的生產最低標準，因為擴充套件的放置、啟用元件、節點數量、守護程序負載、KEDA 安裝、Log Analytics、DAPR 使用和工作負載請求都會有所不同。 以已發佈的擴充元件請求作為基準，並測量可分配的（非總）節點資源。 評估叢集大小並非實際執行環境調整大小的建議。

安裝前，請記錄：

• 符合資格的 linux/amd64 節點上的可分配 CPU 和記憶體。
• 節點數量與故障區域的擺放。
• 免費的 Pod 和服務 IP 容量。
• 目前的系統和租戶請求與限制。
• 因污點、親和力、配額或中斷預算而導致容量無法使用。

估算工作負載能力

針對每個應用，計算：

peak capacity = maximum replicas x (application requests + sidecar requests)

新增尖峰並行作業容量、擴充容量、系統保留容量、升級尖峰容量及故障保留容量。 確保節點標籤、污點、親和規則和資源碎片化不會讓名義上的空置容量無法調度。

透過排程代表性工作負載及模擬節點排水來驗證計畫。 確認擴充艙和所需的工作負載副本是否準備好。

網路要求

Azure Arc 上的容器應用程式需要幾條不同的網路路徑：

使用 Azure Arc 啟用的 Kubernetes 網路需求作為標準端點清單。 在未選擇正確的 Azure 雲端並啟用 Arc 功能前，不要將端點清單複製到防火牆規則集。 測試叢集網路中所有必需的完整合格網域名稱（FQDN）。 Arc 要求規定 HTTPS 端點使用官方簽署且可驗證的憑證。 確認非生產叢集中的代理與 TLS 檢查行為;不支援的攔截或不信任的替換憑證可能阻止代理程式與擴充元件連接。

所選 LoadBalancer 實作決定位址池、健康探針、路由及所需容量。 若自訂負載平衡器需要保留位址，請先保留該位址，並在安裝時透過擴充 loadBalancerIp 設定傳遞。 健康探測連接埠與來源範圍設定依實作而異；請從所選的負載平衡器取得這些資訊，而不要假設其為 Azure Load Balancer 的預設值。

底層已啟用 Arc 的 Kubernetes 叢集負責控制已連線環境的網路限制。 如果應用程式相依使用私有端點，請從應用程式 Pod 驗證叢集是否能解析其 DNS 名稱並將路由至其私有 IP。 需要用戶端 IP 資訊的應用程式應驗證所選負載平衡器與代理鏈所產生的轉發標頭，並定義哪些代理是可信的。

驗證網路

1. 部署 Kubernetes LoadBalancer 測試服務，並確認它能從每個預期客戶端網路接收到可達的位址。
2. 從符合資格的叢集節點或診斷 pod，解析並連接所有必要的 Azure Arc 端點及工作負載依賴。
3. 確認代理是否允許必要的 HTTPS 和 WebSocket 流量，且不會用不受信任的發行者取代憑證。
4. 確認叢集DNS、莢艙間流量、服務、入口網路鉤子及負載平衡器健康探測是否能與預期的網路政策相容。
5. 擴充套件安裝後，確認入口服務已接收預定的 IP 且可達，然後再建立生產 DNS 紀錄。

DNS 需求

安裝擴充套件後，部署測試應用程式並取得其產生的 FQDN。 驗證每個預期用戶端網路的 FQDN 都能解析並觸達擴充功能 Ingress。 connected-environment 名稱是產生的應用程式領域的一部分，因此請特別選擇它。

對於內部應用，當內部與外部客戶端需要不同答案時，建議使用分割視距DNS。 識別權威 DNS 區域、記錄的存留時間（TTL）及復原要求。 判斷應用程式是否使用產生的網域、自訂網域，或兩者皆用，並在部署前規劃憑證的發行與續期。

驗證每個預期用戶端網路的 DNS 與入口：

nslookup <APPLICATION_FQDN>
curl --verbose https://<APPLICATION_FQDN>

應用程式的 FQDN 必須解析到 Ingress IP，並傳回預期的應用程式回應。 在分享冗長輸出前，請移除授權標頭、Cookie 和敏感的查詢字串。

身份、祕密與登記

Azure Arc 上的容器應用程式不支援受控識別。使用受控識別從 Azure Container Registry 提取映像也不受支援。

若要存取 Azure 資源，只有在目標服務支援時，才使用專用的應用程式註冊與服務主體。 僅在實際可行的最小範圍內授予所需的資料平面角色。 將租戶 ID 和客戶端 ID 與憑證分開，當應用程式和目標服務支援時使用憑證，並規劃憑證的到期與輪替。 不要重複使用 Arc 連接叢集身份或叢集管理員身份來存取應用程式。

對於私有登錄檔，若登錄檔支援，請使用具有僅可拉取存取權限的登錄檔範圍認證。 避免使用 ACR 管理員憑證用於生產工作負載。 將登錄檔和應用程式憑證儲存為容器應用程式的秘密，並從應用程式設定中以名稱引用。

容器應用程式的秘密是應用範圍的，變更秘密不會自動更新現有版本。 將 Azure 控制平面存取與特權 Kubernetes 存取視為安全邊界。 根據 Kubernetes 部署的安全需求，限制對擴充功能與應用程式命名空間的存取。

請使用這個旋轉序列：

1. 在身份提供者或登錄處建立第二個有效的憑證。
2. 更新容器應用程式秘密，並依需求部署或重新啟動受影響的版本。
3. 用新的憑證驗證影像拉取和應用程式認證。
4. 撤銷舊的證件。
5. 確認沒有任何仍在使用中的修訂版本或工作參照舊值。

切勿在指令歷史、原始碼控制、診斷套件、Pod 描述或應用程式日誌中放置秘密值。 限制誰能讀取擴充功能保護的設定和 Kubernetes 秘密。

儲存體

根據工作負載所需的持久性來規劃儲存空間：

Arc 上容器應用程式的限制目前記載 Azure 檔案儲存體 SMB，且需要 SMB CSI 驅動程式。 不要以為 Azure 託管容器應用程式支援的磁碟區類型在 Arc 上也支援。請使用 Azure Arc 上 Azure 容器應用程式 連結的 SMB 安裝指令，而不是在這裡維護另一個副本。

將用於掛載的儲存體帳戶認證視為機密資料。 Arc 上的 Container Apps 不支援受控識別。請使用與生產環境完全相同版本的 CSI 驅動程式和儲存體服務，測試所選的掛接選項、檔案權限、並行存取、失敗行為和認證輪替。

規劃持久資料備份、還原測試、保留資料及災難復原。 測試修訂版本與 Job 如何回報掛載失敗的情況，並將 Pod 事件和 CSI 驅動程式日誌納入診斷程序中。 Linux 是該擴充功能唯一支援的節點作業系統。

計畫可檢視性

Log Analytics 整合是可選的。 如果你打算使用它，請在安裝擴充功能時加以設定，因為之後無法再將它加入該擴充功能執行個體。

當您設定 Log Analytics 時，可以在 ContainerAppConsoleLogs_CL 中找到應用程式記錄。 在 Azure Arc 上建立容器應用程式教學課程示範了 TimeGenerated、ContainerAppName_s 和 Log_s；在建立查詢或警示前，請先檢查即時資料表。 確認初次攝取時，請預留10到15分鐘。

規劃工作區存取、保留、警示、匯出以及資料擷取成本。 在啟用收集前，請檢查應用程式日誌中的憑證、個人資料及敏感網址。

如果您未設定 Log Analytics，或在發生資料擷取異常期間，請使用 Kubernetes 日誌：

kubectl get pods -n <APPS_NAMESPACE> -o wide
kubectl logs -n <APPS_NAMESPACE> <POD_NAME> --all-containers=true --tail=200
kubectl get events -n <APPS_NAMESPACE> --sort-by=.lastTimestamp

系統元件會將日誌寫入標準輸出。 預設情況下，系統元件遙測會傳送給 Microsoft，而應用程式日誌則不會傳送，除非你設定 Log Analytics。 設定 logProcessor.enabled=false 關閉日誌處理和轉發到工作區，並可能增加支援要求你手動收集的診斷證據。

在正式上線前，對唯一的應用程式記錄訊息進行端對端測試，為擴充功能健康狀態和應用程式失敗建立警示，並確認 Azure 和 Kubernetes 的診斷資料皆可存取。

升級、備份與恢復

選擇並記錄擴充功能的發布週期和升級政策。 容器應用程式設定教學使用 stable 發布軌道，並自動升級次要版本。 Azure Arc 叢集擴充功能可以依循發行節奏自動升級，或釘選至特定版本並手動升級。 在更改版本前，請先閱讀容器 應用擴充功能的發布說明 ，並提供備用容量、相容的 Kubernetes 版本、維護視窗及應用程式驗證。

在擴充功能或 Kubernetes 升級之前：

1. 確認已連接叢集與擴充配置狀態為 Succeeded。
2. 確認目標 Kubernetes 與擴充套件的組合是否受支援。
3. 檢視版本說明與目前設定，包括發佈列車、自動升級設定、KEDA 安裝、命名空間、Log Analytics 等。loadBalancerIp
4. 確認是否有足夠的備用容量可進行滾動式替換，並確認中斷預算允許作業繼續進行。
5. 驗證目標影像的影像登錄連結性及存取政策。
6. 備份應用程式來源設定及所有持久化應用程式資料。
7. 在變更前後執行應用程式、入口測試、縮放測試、工作測試、儲存測試及日誌測試。

不要把 Kubernetes 命名空間備份當作 Azure 資源的備份。 連接叢集、擴充功能、自訂位置、連接環境、容器應用程式和工作都以 Azure Resource Manager 表示，並依賴叢集內的資源。 請另行備份宣告式應用程式設定。 除非 Microsoft 支援提供該復原程序，否則不要手動還原新安裝擴充套件管理的部署、自訂資源或秘密。

擴充功能降級或回復舊版，並不是 Arc 上的 Container Apps 文件中記載的一般性復原機制。在未先與 Microsoft 支援確認有受支援的處理方式之前，請勿因應事件而變更發行通道、固定為舊版，或修改由擴充功能管理的工作負載。

開發並測試一份涵蓋 Kubernetes 基礎設施、網路、DNS、負載平衡、儲存、Azure Arc 代理、容器應用程式擴充功能、自訂位置、連接環境、應用程式設定、憑證及持久應用程式資料的復原執行手冊。 復原後驗證入口、修訂、縮放、工作、儲存和日誌。 部署時使用由 Kubernetes 拓撲與備份產品支援的復原程序。

規劃 Azure 中斷連線。 Arc 代理需要連線來發現擴展變更並傳播所需狀態。 新建立的擴充功能資源之受保護的設定最多可保留 48 小時；如果叢集在此期間持續中斷連線，該擴充功能可能會從 Pending 移至 Failed。 測試 Azure 連線中斷時的工作負載行為，而不是假設有持續性保證。

相關內容

• Azure Arc 上的 Azure 容器應用程式
• 設定已啟用 Azure Arc 的 Kubernetes 叢集以執行 Azure 容器應用程式
• 在 Azure Arc 上建立容器應用程式
• 在 Azure Arc-enabled Kubernetes 上對 Azure 容器應用程式 進行疑難排解
• 已啟用 Azure Arc 的 Kubernetes 網路需求
• 已啟用 Azure Arc 的 Kubernetes 上的自訂位置
• Azure Arc-enabled Kubernetes 中的叢集擴展