本文共 2212 字，大约阅读时间需要 7 分钟。
最近，微软宣布将于2020年1月正式暂停其ACS（Azure Container Service）服务，并鼓励ACS用户将其分布式基础架构转移到新推出的Azure Kubernetes Service服务上，这对微软来说是一个合乎逻辑的举动。虽然ACS将继续支持Docker Swarm和Mesosphere的DC/OS替代编排选项，但将不再运行它们。相反，微软正集中精力改善Azure中的Kubernetes支持以及相关工具。
虽然ACS即将退役，但基于此的应用不会立即停止，用于管理的API将被停止，因此无法控制且无法使用Azure工具添加新集群或更新和扩展现有服务。尽管代码可以运行，但如果不能使用自己的工具管理，功能还是会受到限制。用户会被锁定在目前使用的旧版本框架中，并且无法依赖自动安全更新。
很明显，对于大多数应用来说，在2020年1月之后留在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权限升级错误。
参考链接：
转载地址：http://epasx.baihongyu.com/