最近，微软宣布将于 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 权限升级错误。

参考链接：https://www.infoworld.com/article/3328553/containers/how-to-migrate-your-apps-from-azure-container-service.html