將 WebSphere 應用程式遷移至 Azure Kubernetes Service 上的 WildFly
本指南說明當您想要移轉現有的 WebSphere 應用程式以在 Azure Kubernetes Service 容器中的 WildFly 上執行時,應該注意的事項。
移轉前
為確保成功移轉,在開始之前,請先完成下列各節中所述的評量和清查步驟。
清查伺服器容量
記錄目前生產伺服器的硬體(記憶體、CPU、磁碟),以及平均和尖峰要求計數和資源使用率。 無論您選擇哪一種遷移路徑,您都需要這項資訊。 例如,協助引導選取節點集區中 VM 的大小、容器要使用的記憶體數量,以及容器需要多少 CPU 共用。
它可以調整 AKS 中的節點集區大小。 若要瞭解如何,請參閱 調整 Azure Kubernetes Service (AKS) 中的節點集區大小。
清查所有秘密
檢查實際執行伺服器上的所有屬性和設定檔是否有任何秘密和密碼。 請務必檢查 您 WAR 中的ibm-web-bnd.xml 。 您也可以在應用程式內找到包含密碼或認證的組態檔。
清查所有憑證
記載所有用於公用 SSL 端點的憑證。 您可以執行下列命令來檢視實際執行伺服器上的所有憑證:
keytool -list -v -keystore <path to keystore>
驗證支援的 Java 版本是否正常運作
在 Azure Kubernetes Service 上使用 WildFly 需要特定版本的 Java,因此您必須確認您的應用程式使用該支援的版本正確執行。
注意
如果您的目前伺服器是在不支援的 JDK 上執行,此驗證特別重要(例如 Oracle JDK 或 IBM OpenJ9)。
若要取得目前的 Java 版本,請登入您的生產伺服器,然後執行下列命令:
java -version
如需使用哪些版本來執行WildFly的指引,請參閱 需求 。
清查 JNDI 資源
清查所有 JNDI 資源。 某些訊息代理程式,例如 JMS 訊息代理程式,可能需要移轉或重新設定。
在應用程式內
檢查 WEB-INF/ibm-web-bnd.xml 和/或 WEB-INF/web.xml檔案。
檔數據源
如果應用程式使用任何資料庫,則必須擷取下列資訊:
- 數據源名稱為何?
- 連線集區設定是什麼?
- 哪裡可以找到 JDBC 驅動程式 JAR 檔案?
如需詳細資訊,請參閱 WebSphere 檔中的設定資料庫連線 能力。
判斷是否要使用檔案系統及如何使用
每當使用應用程式伺服器上的檔案系統時,都必須重新設定,或在罕見的情況下,還需要進行架構變更。 檔案系統可由 WebSphere 模組或您的應用程式程式代碼使用。 您可能會發現下列各節所述的部分或所有案例。
唯讀靜態內容
如果應用程式目前提供靜態內容,則必須為其提供替代位置。 您可能想要考慮將靜態內容移至 Azure Blob 儲存體,並新增 Azure CDN 以進行全球快速下載。 如需詳細資訊,請參閱 Azure 儲存體中的靜態網站裝載和快速入門:整合 Azure 儲存體帳戶與 Azure CDN。
動態發佈的靜態內容
如果您的應用程式允許您應用程式上傳/產生的靜態內容,但在建立後不可變,則您可以使用上述的 Azure Blob 儲存體和 CDN,搭配 Azure 函式來處理上傳和 CDN 重新整理。 我們已在使用 Azure Functions 上傳和透過 CDN 預先載入靜態內容中提供範例實作供您使用。
動態或內部內容
對於您應用程式經常寫入和讀取的檔案 (例如暫存資料檔案),或只有您的應用程式才能看見的靜態檔案,您可以掛接 Azure 儲存體共用,作為永續性磁碟區。 如需詳細資訊,請參閱在 Azure Kubernetes Service 中建立和使用具有 Azure 檔案儲存體 的磁碟區(AKS)。
判斷您的應用程式是否依賴排程的作業
排程的作業,例如讓排程器工作或 Unix cron 工作,不應該與 Azure Kubernetes Service (AKS) 搭配使用。 Azure Kubernetes Service 不會防止您在內部部署包含排程工作的應用程式。 不過,如果您的應用程式相應放大,則每個排程期間,相同的排程工作可能會執行多次。 這種情況可能會導致非預期的後果。
若要在 AKS 叢集上執行排程的工作,請視需要定義 Kubernetes CronJobs。 如需詳細資訊,請參閱 使用 CronJob 執行自動化工作。
判斷是否需要連線至內部部署環境
如果您的應用程式需要存取您的任何內部部署服務,您必須佈建其中一個 Azure 連線能力服務。 如需詳細資訊,請參閱將內部部署網路連線至 Azure。 或者,您必須重構應用程式,以使用內部部署資源所顯示的公開可用 API。
判斷 Java 訊息服務 (JMS) 佇列或主題是否正在使用中
如果應用程式使用 JMS 佇列或主題,您就必須將這些佇列或主題遷移到裝載在外部的 JMS 伺服器。 對於這些使用 JMS 的佇列或主題來說,Azure 服務匯流排和進階訊息佇列通訊協定 (AMQP) 會是絕佳的移轉策略。 如需詳細資訊,請參閱搭配 Azure 服務匯流排 標準和AMQP 1.0使用Java Message Service 1.1。
如果您已設定 JMS 持續性存放區,就必須在移轉之後擷取存放區的設定並加以套用。
判斷您的應用程式是否使用 WebSphere 特定 API
如果您的應用程式使用 WebSphere 特定的 API,您必須重構它以移除這些相依性。 例如,如果您已使用IBM WebSphere 應用程式伺服器 9.0 版 API 規格中所述的類別,則已在應用程式中使用 WebSphere 特定 API。
判斷您的應用程式是否使用 Entity Beans 或 EJB 2.x 樣式 CMP Beans
如果您的應用程式使用 Entity Beans 或 EJB 2.x 樣式 CMP 豆類,您必須重構應用程式以移除這些相依性。
判斷 Java EE 應用程式用戶端應用程式功能是否正在使用中
如果您有使用 Java EE 應用程式用戶端應用程式用戶端功能連線到您的 (server) 應用程式,您必須重構用戶端應用程式和 (伺服器) 應用程式,才能使用 HTTP API。
判斷您的應用程式是否包含 OS 特定程式代碼
如果您的應用程式包含主機 OS 上具有相依性的任何程式代碼,則必須重構它以移除這些相依性。 例如,您可能需要使用 或 \
取代檔案系統路徑File.Separator
中的任何用法/
,或Paths.get
如果您的應用程式在 Windows 上執行。
判斷EJB定時器是否正在使用中
如果您的應用程式使用EJB定時器,您必須驗證每個WildFly實例都可以獨立觸發EJB定時器程序代碼。 此驗證是必要的,因為在 Azure Kubernetes Service 部署案例中,每個 EJB 定時器都會在其自己的 WildFly 實例上觸發。
判斷 JCA 連接器是否正在使用中
如果您的應用程式使用 JCA 連接器,您必須驗證 JCA 連接器可以在 WildFly 上使用。 如果 JCA 實作系結至 WebSphere,您必須重構應用程式以移除該相依性。 如果可以使用,則必須將 JAR 新增至伺服器 classpath,並將必要的組態檔放在 WildFly 伺服器目錄中的正確位置,以供使用。
判斷 JAAS 是否正在使用中
如果您的應用程式使用 JAAS,您必須擷取 JAAS 的設定方式。 如果使用資料庫,您可以將它轉換成WildFly上的JAAS網域。 如果是自定義實作,您必須驗證它是否可以在WildFly上使用。
判斷您的應用程式是否使用資源配接器
如果您的應用程式需要資源配接器 (RA),它必須與WildFly相容。 藉由將RA部署到伺服器並正確設定,判斷RA在WildFly的獨立實例上是否正常運作。 如果 RA 正常運作,您必須將 JAR 新增至 Docker 映像的伺服器類別路徑,並將必要的組態檔放在 WildFly 伺服器目錄中的正確位置,以供使用。
判斷應用程式是否由多個 WAR 組成
如果應用程式由多個 WAR 組成,則應該將這些 WAR 視為個別應用程式,並瀏覽本指南以了解這些 WAR。
判斷應用程式是否封裝為 EAR
如果您的應用程式封裝為 EAR 檔案,請務必檢查 application.xml 和 application-bnd.xml 檔案並擷取其組態。
注意
如果您想要能夠獨立調整每個 Web 應用程式,以便更妥善地使用 Azure Kubernetes Service (AKS) 資源,您應該將 EAR 分成不同的 Web 應用程式。
識別在生產伺服器上執行的所有外部處理序和精靈
如果您有任何在應用程式伺服器外部執行的處理序 (例如監視精靈),則必須加以消除或將其遷移到其他位置。
執行就地測試
在建立容器映像之前,請將您的應用程式移轉至您想要在 AKS 上使用的 JDK 和 WildFly 版本。 徹底測試應用程式,以確保相容性和效能。
遷移
布建 Azure Container Registry 和 Azure Kubernetes Service
使用下列命令來建立容器登錄和具有登錄上讀取者角色的服務主體的 Azure Kubernetes 叢集。 請務必 為叢集的網路需求選擇適當的網路模型 。
az group create \
--resource-group $resourceGroup \
--location eastus
az acr create \
--resource-group $resourceGroup \
--name $acrName \
--sku Standard
az aks create \
--resource-group $resourceGroup \
--name $aksName \
--attach-acr $acrName \
--network-plugin azure
建立WildFly的 Docker 映像
若要建立 Dockerfile,您需要下列必要條件:
- 支援的 JDK。
- WildFly 的安裝。
- 您的 JVM 執行時間選項。
- 傳入環境變數的方法(如果適用的話)。
然後,您可以執行下列各節中所述的步驟,如果適用的話。 您可以使用 WildFly容器快速入門存放庫 作為 Dockerfile 和 Web 應用程式的起點。
設定 KeyVault FlexVolume
建立 Azure KeyVault 並填入所有必要的秘密。 如需詳細資訊,請參閱快速入門:使用 Azure CLI 從 Azure Key Vault 設定和擷取祕密。 然後,設定 KeyVault FlexVolume ,讓 Pod 能夠存取這些秘密。
您也需要更新用來啟動WildFly的啟動腳本。 此腳本必須先將憑證匯入WildFly所使用的密鑰存放區,才能啟動伺服器。
設定數據源
若要將WildFly設定為存取資料源,您必須將JDBC驅動程式JAR新增至 Docker 映像,然後執行適當的 JBoss CLI 命令。 建置 Docker 映射時,這些命令必須設定數據源。
下列步驟提供 PostgreSQL、MySQL 和 SQL Server 的指示。
下載適用於 PostgreSQL、MySQL 或 SQL Server 的 JDBC 驅動程式。
將下載的封存解壓縮,以取得驅動程式.jar檔案。
建立名稱如下
module.xml
的檔案,並新增下列標記。 將<module name>
佔位元元(包括角括號)取代org.postgres
為 PostgreSQL、com.mysql
MySQL 或com.microsoft
SQL Server。 將 取代<JDBC .jar file path>
為上一個步驟中.jar檔案的名稱,包括將檔案放在 Docker 映射中位置的完整路徑,例如 。/opt/database
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="<module name>"> <resources> <resource-root path="<JDBC .jar file path>" /> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
建立名稱如下
datasource-commands.cli
的檔案,並新增下列程序代碼。 將取代<JDBC .jar file path>
為您在上一個步驟中使用的值。<module file path>
取代為上一個步驟中的檔案名稱與路徑, 例如/opt/database/module.xml
。注意
Microsoft 建議您使用最安全的可用驗證流程。 此程式中所述的驗證流程,例如資料庫、快取、傳訊或 AI 服務,在應用程式中需要高度的信任,而且不會在其他流程中帶來風險。 只有在更安全的選項,例如無密碼或無密鑰連線的受控識別時,才能使用此流程。 針對本機計算機作業,偏好使用無密碼或無密鑰連線的使用者身分識別。
batch module add --name=org.postgres --resources=<JDBC .jar file path> --module-xml=<module file path> /subsystem=datasources/jdbc-driver=postgres:add(driver-name=postgres,driver-module-name=org.postgres,driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource) data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=$DATABASE_CONNECTION_URL --user-name=$DATABASE_SERVER_ADMIN_FULL_NAME --password=$DATABASE_SERVER_ADMIN_PASSWORD --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker reload run batch shutdown
更新應用程式的 JTA 資料來源:
src/main/resources/META-INF/persistence.xml
開啟應用程式的檔案,並尋找<jta-data-source>
元素。 取代其內容,如下所示:<jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>
將下列內容新增至 ,
Dockerfile
以便在建置 Docker 映射時建立數據源RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \ sleep 30 && \ <WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/database/datasource-commands.cli && \ sleep 30
DATABASE_CONNECTION_URL
判斷要用於每個資料庫伺服器的 ,且與 Azure 入口網站 上的值不同。 這裡顯示的網址格式是 WildFly 使用的必要格式:jdbc:postgresql://<database server name>:5432/<database name>?ssl=true
在稍後階段建立部署 YAML 時,您必須傳遞下列環境變數 ,
DATABASE_CONNECTION_URL
DATABASE_SERVER_ADMIN_FULL_NAME
並使用DATABASE_SERVER_ADMIN_PASSWORD
適當的值。
注意
Microsoft 建議您使用最安全的可用驗證流程。 此程式中所述的驗證流程,例如資料庫、快取、傳訊或 AI 服務,在應用程式中需要高度的信任,而且不會在其他流程中帶來風險。 只有在更安全的選項,例如無密碼或無密鑰連線的受控識別時,才能使用此流程。 針對本機計算機作業,偏好使用無密碼或無密鑰連線的使用者身分識別。
如需使用WildFly設定資料庫連線的詳細資訊,請參閱PostgreSQL、MySQL或 SQL Server。
設定 JNDI 資源
若要設定您需要在WildFly上設定的每個JNDI資源,您通常會使用下列步驟:
- 下載必要的 JAR 檔案,並將其複製到 Docker 映像。
- 建立參考這些 JAR 檔案的 WildFly module.xml 檔案。
- 建立特定 JNDI 資源所需的任何設定。
- 建立 JBoss CLI 腳本,以在 Docker 組建期間用來註冊 JNDI 資源。
- 將所有專案新增至 Dockerfile。
- 在部署YAML中傳遞適當的環境變數。
下列範例顯示建立 JMS 連線至 Azure 服務匯流排 JNDI 資源所需的步驟。
-
將下載的封存解壓縮,以取得.jar檔案。
在 中建立名稱如下
module.xml
的檔案,並在 中/opt/servicebus
新增下列標記。 請確定 JAR 檔案的版本號碼與上一個步驟的 JAR 檔名一致。<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="org.jboss.genericjms.provider"> <resources> <resource-root path="proton-j-0.31.0.jar"/> <resource-root path="qpid-jms-client-0.40.0.jar"/> <resource-root path="slf4j-log4j12-1.7.25.jar"/> <resource-root path="slf4j-api-1.7.25.jar"/> <resource-root path="log4j-1.2.17.jar"/> <resource-root path="netty-buffer-4.1.32.Final.jar" /> <resource-root path="netty-codec-4.1.32.Final.jar" /> <resource-root path="netty-codec-http-4.1.32.Final.jar" /> <resource-root path="netty-common-4.1.32.Final.jar" /> <resource-root path="netty-handler-4.1.32.Final.jar" /> <resource-root path="netty-resolver-4.1.32.Final.jar" /> <resource-root path="netty-transport-4.1.32.Final.jar" /> <resource-root path="netty-transport-native-epoll-4.1.32.Final-linux-x86_64.jar" /> <resource-root path="netty-transport-native-kqueue-4.1.32.Final-osx-x86_64.jar" /> <resource-root path="netty-transport-native-unix-common-4.1.32.Final.jar" /> <resource-root path="qpid-jms-discovery-0.40.0.jar" /> </resources> <dependencies> <module name="javax.api"/> <module name="javax.jms.api"/> </dependencies> </module>
在中
/opt/servicebus
建立jndi.properties
檔案。connectionfactory.${MDB_CONNECTION_FACTORY}=amqps://${DEFAULT_SBNAMESPACE}.servicebus.windows.net?amqp.idleTimeout=120000&jms.username=${SB_SAS_POLICY}&jms.password=${SB_SAS_KEY} queue.${MDB_QUEUE}=${SB_QUEUE} topic.${MDB_TOPIC}=${SB_TOPIC}
建立名稱如下
servicebus-commands.cli
的檔案,並新增下列程序代碼。batch /subsystem=ee:write-attribute(name=annotation-property-replacement,value=true) /system-property=property.mymdb.queue:add(value=myqueue) /system-property=property.connection.factory:add(value=java:global/remoteJMS/SBF) /subsystem=ee:list-add(name=global-modules, value={"name" => "org.jboss.genericjms.provider", "slot" =>"main"} /subsystem=naming/binding="java:global/remoteJMS":add(binding-type=external-context,module=org.jboss.genericjms.provider,class=javax.naming.InitialContext,environment=[java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory,org.jboss.as.naming.lookup.by.string=true,java.naming.provider.url=/opt/servicebus/jndi.properties]) /subsystem=resource-adapters/resource-adapter=generic-ra:add(module=org.jboss.genericjms,transaction-support=XATransaction) /subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:add(class-name=org.jboss.resource.adapter.jms.JmsManagedConnectionFactory, jndi-name=java:/jms/${MDB_CONNECTION_FACTORY}) /subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=ConnectionFactory:add(value=${MDB_CONNECTION_FACTORY}) /subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=JndiParameters:add(value="java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory;java.naming.provider.url=/opt/servicebus/jndi.properties") /subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:write-attribute(name=security-application,value=true) /subsystem=ejb3:write-attribute(name=default-resource-adapter-name, value=generic-ra) run-batch reload shutdown
將下列內容新增至 ,
Dockerfile
以便在建置 Docker 映射時建立 JNDI 資源RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \ sleep 30 && \ <WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/servicebus/servicebus-commands.cli && \ sleep 30
在稍後階段建立部署 YAML 時,您必須使用適當的值傳遞下列環境變數、
MDB_CONNECTION_FACTORY
DEFAULT_SBNAMESPACE
和SB_SAS_POLICY
、SB_SAS_KEY
、MDB_QUEUE
、SB_QUEUE
MDB_TOPIC
和SB_TOPIC
。
檢閱WildFly設定
檢閱 WildFly系統管理指南 ,以涵蓋先前指引未涵蓋的任何其他移轉前步驟。
建置 Docker 映射並將其推送至 Azure Container Registry
建立 Dockerfile 之後,您必須建置 Docker 映射,並將其發佈至您的 Azure 容器登錄。
如果您使用WildFly 容器快速入門 GitHub 存放庫,建置映像並將其推送至 Azure Container Registry 的程式相當於叫用下列三個命令。
在這些範例中 MY_ACR
,環境變數會保存 Azure 容器登錄的名稱,而 MY_APP_NAME
變數會保留您想要在 Azure 容器登錄上使用的 Web 應用程式名稱。
建置 WAR 檔案:
mvn package
登入您的 Azure Container Registry:
az acr login --name ${MY_ACR}
建置並推送映射:
az acr build --image ${MY_ACR}.azurecr.io/${MY_APP_NAME} --file src/main/docker/Dockerfile .
或者,您可以使用 Docker CLI 先在本機建置及測試映射,如下列命令所示。 這種方法可以簡化在初始部署至 ACR 之前測試和精簡映像。 不過,您必須安裝 Docker CLI,並確定 Docker 精靈正在執行。
建置映像:
docker build -t ${MY_ACR}.azurecr.io/${MY_APP_NAME}
在本機執行映像:
docker run -it -p 8080:8080 ${MY_ACR}.azurecr.io/${MY_APP_NAME}
您現在可以在 http://localhost:8080
存取您的應用程式。
登入您的 Azure Container Registry:
az acr login --name ${MY_ACR}
將映像推送至您的 Azure 容器登錄:
docker push ${MY_ACR}.azurecr.io/${MY_APP_NAME}
如需在 Azure 中建置和儲存容器映像的詳細資訊,請參閱 Learn 模組 使用 Azure Container Registry 建置和儲存容器映像。
布建公用IP位址
如果您的應用程式可從內部或虛擬網路外部存取,您將需要公用靜態IP位址。 您應該在叢集的節點資源群組內布建此 IP 位址,如下列範例所示:
export nodeResourceGroup=$(az aks show \
--resource-group $resourceGroup \
--name $aksName \
--query 'nodeResourceGroup' \
--output tsv)
export publicIp=$(az network public-ip create \
--resource-group $nodeResourceGroup \
--name applicationIp \
--sku Standard \
--allocation-method Static \
--query 'publicIp.ipAddress' \
--output tsv)
echo "Your public IP address is ${publicIp}."
部署到 Azure Kubernetes Service (AKS)
建立並套用 Kubernetes YAML 檔案(s)。 如需詳細資訊,請參閱 快速入門:使用 Azure CLI 部署 Azure Kubernetes Service (AKS) 叢集。 如果您要建立外部負載平衡器(無論是針對您的應用程式還是輸入控制器),請務必提供上一節中布建的IP位址作為 LoadBalancerIP
。
將外部化參數納入為環境變數。 如需詳細資訊,請參閱 定義容器的環境變數。 請勿包含秘密(例如密碼、API 金鑰和 JDBC 連接字串)。 下一節將討論這些內容。
建立部署 YAML 時,請務必包含記憶體和 CPU 設定,讓您的容器大小正確。
設定永續性記憶體
如果您的應用程式需要非揮發性記憶體,請設定一或多個 永續性磁碟區。
移轉排程的工作
若要在 AKS 叢集上執行排程的工作,請視需要定義 Kubernetes CronJobs。 如需詳細資訊,請參閱 使用 CronJob 執行自動化工作。
移轉後
既然您已將應用程式移轉至 Azure Kubernetes Service,您應該確認它如預期般運作。 完成之後,我們有一些建議可讓您的應用程式更雲端原生。
建議
請考慮將 DNS 名稱新增至配置給輸入控制器或應用程式負載平衡器的 IP 位址。 如需詳細資訊,請參閱 在 Azure Kubernetes Service (AKS) 上搭配輸入控制器使用 TLS。
請考慮為您的應用程式新增 HELM 圖表 。 Helm 圖表可讓您將應用程式部署參數化,以供一組更多樣化的客戶使用和自定義。
設計和實作DevOps策略。 若要在提高開發速度的同時維持可靠性,請考慮使用 Azure Pipelines 將部署和測試自動化。 如需詳細資訊,請參閱 使用 Azure Pipelines 建置和部署至 Azure Kubernetes Service。
啟用叢集的 Azure 監視。 如需詳細資訊,請參閱啟用 Kubernetes 叢集的監視。 這可讓 Azure 監視器收集容器記錄、追蹤使用率等等。
請考慮透過 Prometheus 公開應用程式特定計量。 Prometheus 是 Kubernetes 社群中廣泛採用的開放原始碼計量架構。 您可以在 Azure 監視器中設定 Prometheus 計量,而不是裝載自己的 Prometheus 伺服器,以啟用應用程式的計量匯總,以及自動回應或呈報異常狀況。 如需詳細資訊,請參閱 啟用 Prometheus 和 Grafana。
設計和實作商務持續性和災害復原策略。 針對任務關鍵性應用程式,請考慮多區域部署架構。 如需詳細資訊,請參閱 Azure Kubernetes Service 的高可用性和災害復原概觀(AKS)。
檢閱 Kubernetes 版本支持原則。 您必須繼續更新 AKS 叢集,以確保它一律執行支援的版本。 如需詳細資訊,請參閱 Azure Kubernetes Service (AKS) 叢集的升級選項。
讓負責叢集管理和應用程式開發的所有小組成員檢閱相關的 AKS 最佳做法。 如需詳細資訊,請參閱 在 Azure Kubernetes Service (AKS) 上建置和管理應用程式的叢集操作員和開發人員最佳做法。
請確定您的部署檔案會指定輪流更新的完成方式。 如需詳細資訊,請參閱 Kubernetes 檔中的滾動更新部署 。
設定自動調整以處理尖峰時間負載。 如需詳細資訊,請參閱在 Azure Kubernetes Service (AKS) 中使用叢集自動調整程式。
請考慮監視程序代碼快取大小,並在 Dockerfile 中新增 JVM 參數
-XX:InitialCodeCacheSize
-XX:ReservedCodeCacheSize
,以進一步優化效能。 如需詳細資訊,請參閱 Oracle 檔中的 Codecache Tuning 。