將工作負載遷移至新式容器Migrate workloads to modern containers

大部分新式容器選項都需要重新架構或重新部署應用程式。Most modern container options require a rearchitecture or redeployment of the application. 但 Azure Kubernetes Service (AKS) 的協調流程功能,可讓您將 AKS 解決方案整合到標準的遷移過程中。But the orchestration capabilities of Azure Kubernetes Service (AKS) allows for AKS solutions to be integrated into standard migration processes.

將現有工作負載從內部部署資料中心遷移至 Azure 中的 Kubernetes 叢集,會有明顯且不斷成長的趨勢。There's a clear and growing trend of migrating existing workloads from on-premises datacenters to a Kubernetes cluster in Azure. 這種方法有可能會降低遷移後基礎結構的使用量。This approach has the potential of reducing the post-migration infrastructure footprint. 更重要的是,遷移至容器可提供組合中更大的可攜性,讓工作負載更容易在公用和私人雲端之間移動。More importantly, migrating to containers allows for greater portability in the portfolio, allowing workloads to be more easily moved between public and private cloud. 當組織有龐大的 web 應用程式集合時,最常遇到此趨勢。This trend is most commonly experienced when organizations have a large collection of web applications.

一個遷移方法One Migrate approach

您可以遷移至 Azure Kubernetes Service (AKS) 來加速雲端中的容器,作為 雲端採用架構的一個遷移案例的一部分。You can migrate to Azure Kubernetes Service (AKS) to accelerate containers in the cloud, as a part of the Cloud Adoption Framework's One Migrate scenario. 一般而言,遷移至 Azure 會使用 Azure Migrate 和合作夥伴工具來評估工作負載、遷移工作負載,以及將工作負載發行至雲端。Typically, migration to Azure uses Azure Migrate and partner tools to assess workloads, migrate workloads, and release workloads to the cloud. 您可以將這三個步驟的程式套用至 AKS 遷移,不過,您可能需要一些其他工具來協助進行遷移步驟。You can apply this three-step process to AKS migration, however, you might need a few other tools to help with the migration steps.

評估工作負載Assess workloads

您需要清查工作負載及其目前的容器化狀態。You'll need an inventory of workloads and their current containerization status. 在容器內操作工作負載的功能和效能時,無法遷移工作負載。Workloads cannot be migrated until they have been validated as functional and performant while operating within a container. 與應用程式擁有者合作,以配置時間來執行容器化、驗證結果,以及建立工作的影像建立管線。Work with application owners to allocate time to perform containerization, validate results, and build image building pipelines for the work. 請注意獨特的相依性,例如 Windows 特定的需求 (例如 Gmsa) 、本機檔案系統使用方式、快取執行詳細資料、單一執行和相依性(例如資料庫)。Take note of unique dependencies such as Windows-specific requirements (e.g. Gmsa), local file system usage, cache implementation details, singleton implementations, and dependencies such as databases.

雖然集中式小組可以將容器化工作導向整個組織,但請考慮更多專案管理功能和技術需求收集和監督程式,應用程式擁有者必須高度參與此程式。While a centralized team can lead the containerization efforts across an org, consider that more of a project management function and technical requirements gathering and oversight process, application owners will need to be highly involved in this process.

遷移容器和工作負載Migrate containers and workloads

在遷移時,請確定您的目標 Kubernetes 版本位於支援的 AKS 視窗內。When migrating, ensure your target Kubernetes version is within the supported window for AKS. 如果使用較舊的版本,它可能不在支援的範圍內,而且需要 AKS 支援升級版本。If using an older version, it might not be within the supported range and require upgrading versions to be supported by AKS. 如需詳細資訊,請參閱 AKS 支援的 Kubernetes 版本For more information, see AKS supported Kubernetes versions.

如同任何遷移,請決定要比較容易的維護時段,並清楚瞭解如何進行遷移的所有感興趣的專案關係人。As with any migration, decide what maintenance window is agreeable and be clear to all interested stakeholders how the migration is proceeding. 在適當的情況下追蹤和儀表板的遷移。Track and dashboard the migration where appropriate. 如果無法協調下一階段的遷移,則在沒有停機時間的情況下,允許額外的規劃、成本和複雜性。If a down-time migration cannot be negotiated, then allow for extra planning, cost, and complications around a no down-time migration. 如果發現不需要停機時需要停機,請將該變更傳達給您的專案關係人。If it is found that a down-time migration is required when one was not expected, communicate that change to your stakeholders. 對該變更執行影響分析,以確保會記載風險並據此進行同意。Perform impact analysis on that change to ensure risks are documented and agreed upon.

所有遷移 (甚至是) 的停機時間,都可能需要修改現有的應用程式,並提供支援遷移的額外彈性。All migrations (even downtime migrations), may need to modify the existing application with added flexibility to support the migration. 確保應用程式小組完全參與規劃工作負載遷移的最早速度。Ensure application teams are fully involved in the planning of workload migrations as early as possible. 例如,您可能需要在目前的工作負載中部署其他 DNS、連接字串和設定切換功能,才能完成遷移。For example additional DNS, connection string, and settings switching capabilities may need to be deployed in the current workload before the migration can be completed.

目前,您必須使用數個開放原始碼工具的其中一個,才能完成將容器和工作負載複寫至 Azure 的動作:Currently, you'll need to use one of several open-source tools to complete the replication of your container and workloads to Azure:

如果您是從現有的 Kubernetes 平臺 (AKS 引擎、ACS 或其他 Kubernetes 執行) ,您可能會考慮使用一些開放原始碼工具來協助進行遷移。If you're coming from an existing Kubernetes platform (AKS Engine, ACS, or another Kubernetes implementation), you might consider using some open-source tooling to help with the migration. 在這些情況下,您已經有在 Kubernetes 中運作的工作負載,而 AKS 中的重新裝載通常更簡單。In these cases you've already got a workload that functions in Kubernetes, and rehosting in AKS is usually much simpler. 執行任何遷移之前,請先驗證 AKS 中的所有功能。Validate all capabilities exist in AKS before performing any migration.

在遷移時,請確定您的目標 Kubernetes 版本位於支援的 AKS 視窗內。When migrating, ensure your target Kubernetes version is within the supported window for AKS. 如果使用較舊的版本,它可能不在支援的範圍內,而且需要 AKS 支援升級版本。If using an older version, it may not be within the supported range and require upgrading versions to be supported by AKS. 如需詳細資訊,請參閱 AKS 支援的 Kubernetes 版本For more information, see AKS supported Kubernetes versions. 可能的話,請一律嘗試遷移至相同版本的 Kubernetes。Where possible, always try to migrate to the same version of Kubernetes. 這表示您可以在現有系統中進行就地升級,或根據您的優先順序規劃遷移後升級。That means either do an in-place upgrade in the existing system or plan a post-migration upgrade -- based on your priorities.

下一步:使用新式容器解決方案進行創新Next step: Innovate using modern container solutions

下列文章將帶您前往雲端採用旅程中特定點的指引,並協助您在雲端採用案例中成功。The following articles will take you to guidance at specific points in the cloud adoption journey and help you be successful in the cloud adoption scenario.