发布于: Oct 14, 2022
弹性计算云服务是云计算的进一步发展产物，迁移上云解决了企业最棘手的问题，然而上云之后只是云原生的开始。
首先，虽然业务已经上云，但是业务形态仍然是传统的单体应用，发布周期长，而且代码改动造成的影响也比较大。因此，需要对应用进行微服务化改造来获得更高的敏捷性。
其次，把云上的计算资源简单地看成是固定的虚拟机去管理，在服务器的整个生命周期中，会经历无数次的发布、变更和调试。同一集群的服务器之间的配置变得越来越不一致，集群各个服务器出现的问题也不一样。这种配置不一致导致我们调试 bug，或者想要对集群进行扩容的时候效率非常低。运维成本也会随着机器的增加而增加。
第三，虽然迁移上云有利于降低企业采购基础设施，以及建设和运维的成本，但在 IDC 中面临的资源利用率的问题在上云之后并没有明显改善，计算资源依然是要按业务峰值再加一定的缓冲来申请，甚至为保证业务稳定性要预留较大的资源缓冲。再加上服务器申请交付流程麻烦（审批，环境初始化，部署流程配置，监控配置等），因此业务申请机器之后为了防止后续再重新申请，不会轻易回收已经申请到的服务器，从而在资源使用上仍然存在极大的浪费。
Flexera 报告指出，企业公有云支出成本的浪费是最主要的问题，并随着支出成本的上升而变得更加可观。受访企业自我评估他们的企业云支出有 30% 的浪费，如下图所示。但是由于很多企业倾向于低估浪费的程度而使得结果偏低。在与客户合作来识别浪费时，Flexera 发现，平均而言，实际浪费为 35％ 甚至更高。
要解决这些问题，我们需要对业务进行云原生架构改造，使其更加适应云计算环境。
首先，为了提高业务的灵活性以及快速部署的能力，需要对业务进行微服务化改造。相应的基础设施架构也需要从虚拟机部署改为容器化部署。
Amazon Web Services 的容器管理平台有 Amazon ECS (Elastic Compute Service) 和 Amazon EKS (Elastic Kubernetes Service) 两种选择。
Amazon ECS 是 Amazon Web Services 自主研发的容器管理平台，提供了简明的资源管理控制台。不需要维护集群的升级，ECS 后台会自动升级，我们直接应用新特性即可。同时 ECS 与 Amazon Web Services 其他服务也有着非常完美的集成，不需要做额外的开发即可开始使用。它是非常简单便利的容器管理平台。
Amazon EKS 是托管的 Kubernetes 容器管理平台，Kubernetes 早已是大趋势，拥有庞大的开源社区的支持、强大的工具和插件生态系统，以及宏大的开发路线图。并且，由于其统一的接口，可以实现多云多 Region 众多集群的统一管理。
用户可以根据需求选择一种平台进行容器化改造。
其次，要解决服务器配置管理混乱的问题，建议采用不可变基础设施架构。
在这种模式中，任何基础设施的实例（包括服务器、容器等）一旦创建之后便成为一种只读状态，禁止对任何运行的服务器做手动修改。如果需要修改或升级某些实例，唯一的方式就是创建新的实例替换原有实例。通过只读和替换这两个特性，可以保证集群配置的一致性，并且永远保持在最初的良好状态。这种架构模式带来的好处是，无论几十台还是几百台服务器，都可以像一台服务器一样去管理。随着服务器数量的增加，运维成本没有明显增加。
进一步可以通过自动化弹性扩缩容来提高资源的利用率。使业务根据每天请求的高低峰进行服务器资源的自动调整。这才是云计算的最本质的能力。
容器环境的弹性扩缩容分为两个层面，一个是容器层面，一个是 node 层面。两个层面的扩缩容逻辑是，业务负载变化触发容器层面的扩缩容，容器的扩缩容使 Node 集群的剩余可分配资源量变化进而触发 Node 节点的扩缩容。容器层面的自动扩缩容比较好实现，ECS 中使用 Application Autoscaling，EKS 中使用 HPA 来实现。而 Node 层面的扩缩容需要解决三个问题：
- 扩容时服务器环境初始化，可以用初始化脚本解决。
- 缩容时容器的优雅调度，可以使用 ASG lifecycle hook 调用 Lambda 解决。
- 最后最关键的是扩缩容时机，一个建议的方案是计算集群中 Node 节点的剩余的可分配资源情况，每分钟触发 Lambda 进行计算并推送到 CloudWatch，并把这个指标作为 Node 节点的扩缩容指标，这样就可以预留出特定数量的 Node 节点资源，在 Pod 扩容时无须等待 Node 就绪。
或者选择开源的 Cluster Autoscaler 来管理 Node 层面的扩缩容。
最后，Spot 实例是 Amazon Web Services 的剩余计算资源，相比按需实例，Spot 实例提供了最低一折的折扣。但是相应的，当按需资源需求增加的时候竞价实例可能随时会被回收。有了自动化作为基础，我们就可以把 Spot 实例加入到集群中，在 Spot 实例被回收之前把容器平滑地调度到其他实例中。从而在利用竞价实例的低价优势的同时，不会因为其不稳定性而对业务造成影响。
通过容器化改造，集群可以根据每天业务高低峰自动调整资源配置，高效利用资源，并且通过 Spot 实例进一步节约成本，同时结合不可变基础设施架构大幅度减少运维成本。在推广活动之前也可以很方便地一键化对资源进行扩容，活动之后方便地进行缩容。新业务上线不仅不需要提前申请过多的资源，而且申请下来的冗余资源也可以按需使用。业务的微服务化使得业务各个模块独立部署，独立扩缩容，快速上线。
进一步通过使用 EKS，结合聚云立方以及 KubeStar 平台，使众多的 Kubernetes 容器集群管理更加便利。服务治理、CI/CD、可观测性等方面都可以通过统一的平台来管理，而且也可以很直观地展示容器层面的费用情况。
相关文章