最近，微軟宣佈將於2020年1月正式暫停其ACS（Azure Container Service）服務，並鼓勵ACS用戶將其分佈式基礎架構轉移到新推出的Azure Kubernetes Service服務上，這對微軟來說是一個合乎邏輯的舉動。雖然ACS將繼續支持Docker Swarm和Mesosphere的DC/OS替代編排選項，但將不再運行它們。相反，微軟正集中精力改善Azure中的Kubernetes支持以及相關工具。
現有ACS應用程序代碼可運行，但將無法管理和更新
雖然ACS即將退役，但基於此的應用不會立即停止，用於管理的API將被停止，因此無法控制且無法使用Azure工具添加新集羣或更新和擴展現有服務。儘管代碼可以運行，但如果不能使用自己的工具管理，功能還是會受到限制。用戶會被鎖定在目前使用的舊版本框架中，並且無法依賴自動安全更新。
很明顯，對於大多數應用來說，在2020年1月之後留在ACS上的風險大於遷移風險，因此我們需要儘快做好遷移安排。
如何從ACS進行遷移？
對於使用Kubernetes的ACS應用程序，這不會太困難。Swarm和DC/OS的底層編排概念和工具會有所不同，所以構建在這之上的代碼將很難移動。即便如此，由於所有服務都依賴相同的容器模型，因此無需進行重大代碼更改。
微軟明確表示，它希望用戶遷移到其他解決方案，並將自己的Azure Kubernetes Service（AKS）作爲首選。當然，AKS是Azure在Kubernetes開源投資的大頭，其acs-engine工具已經進入GitHub，即aks-engine。如果在自己的Azure虛擬基礎架構上使用acs-engine，則應該能夠直接切換到aks-engine來管理Kubernetes實例，因爲它是向後兼容的。
1、成本問題
雖然有很多事情需要考慮，但並不像看起來那麼複雜。首先，我們需要考慮成本問題。從ACS遷移到AKS不應該對計費產生重大影響，也不應該轉向Mesosphere DC/OS的開源版本。我們可以遷移到適用於Swarm的Docker Enterprise或Mesosphere DC/OS的企業版，但這就需要結算其他公司的許可費用和Azure的基礎架構費用。這意味着將放棄Azure的月付優勢，將結算分成多家收款方。
其次，從Swarm或DC/OS ACS實例轉向使用完整產品不需要大量工作，但是可能會產生新的操作要求，因爲需要在Azure之外使用特定於產品的管理工具。對於某些企業而言，這可能是一個問題，但在實踐中，這些平臺提供與ACS相同的功能，還可以直接獲得Azure支持。如果願意，也可以選擇重寫代碼以在AKS上運行。
2、遷移前準備
微軟已經在Azure上關注Kubernetes一年多了，因此，AKS是微軟在Azure上部署Kubernetes託管應用程序的首選解決方案，通過Azure容器實例支持虛擬kubelet等功能，進一步減少與運行Kubernetes相關的工作量。
從ACS遷移到AKS確實存在一些問題，用戶可能需要對應用程序體系結構進行更改以處理兩種服務之間的差異。一些問題是由於AKS是一個託管Kubernetes，一旦處理應該簡化應用。比如，將StorageClass對象從非託管更改爲託管，對於PersistentVolumes也是如此。AKS使用Azure託管磁盤，讓它直接控制存儲，根據需要增加容量。需要避免使用任何基於Windows Server的Kubernetes節點，因爲計劃的支持目前只在私有測試版中。
遷移前可能需要升級Kubernetes版本，並最好在開發環境中處理，這樣可以直接部署到AKS。部署後，應用程序將由AKS管理，並支持動態擴展，這之中也存在API差異，因此如果計劃使用外部Kubernetes工具進行監控和調試，請檢查是否支持AKS API。
3、處理Kubernetes存儲並部署到AKS
如果要將無狀態應用程序從ACS遷移到AKS，則可以像將應用程序YAML部署到新集羣並讓AKS部署和啓動容器一樣簡單。一旦運行，就可以在將公共IP地址從ACS實例切換到AKS之前測試代碼。
狀態應用程序更復雜，可能有延長停機時間的可能。一種選擇是在AKS上設置應用程序故障轉移副本，並複製數據。一旦與現有ACS應用程序同步，就可以在將流量重定向到AKS之前從ACS應用程序故障轉移到AKS。
如果將存儲遷移到託管磁盤會增加額外的複雜性，數據量越大通常需要越多的停機時間。用戶需要停止從ACS進行代碼寫入，關閉它併爲磁盤創建快照。快照可用於創建新磁盤，可用作AKS持久卷。部署後，用戶需要先測試應用程序，然後才能開始向其發送流量。從關閉ACS到AKS部署上線，用戶都將無法訪問。
將代碼部署到AKS的方法類似於將代碼部署到Kubernetes集羣。首先，使用與ACS中相同的節點定義在AKS中創建集羣。然後，編輯YAML以支持AKS定義和位置，並使用現有CI/CD管道部署到新服務主機。代碼存在後，可以在將用戶遷移到新服務之前使用現有測試工具和技術對其進行測試。
完成所有操作後，用戶可以利用支持Virtual Kubelet的完全託管環境並獲得自動更新，從而免受安全問題的影響，例如最近公佈和修復的Kubernetes權限升級錯誤。