随着数字化转型的深入，越来越多业务由线下转向线上，衍生出丰富的业务场景。这些场景驱动着软件系统进行敏态转型，同时也对实际承载业务的底层 IT 资源提出了新的要求，如何保证：既“快”又“稳”，成为整个敏态业务转型面临的新挑战。

今天主要和大家聊一聊，容器在当下数字化转型日益深入的背景下，是如何保证应用的稳定性的，分享内容主要包含容器特点、应用容器化后的关注点、稳定性保障机制等方面。

本文是 9 月 1 日“CloudTech 博云说”第七期分享内容《容器如何提升应用的稳定性？》的回顾整理。扫描上方海报二维码或点击文章末尾的阅读原文，回看精彩视频！

01 为什么选择容器？

第一个问题：为什么说容器更适合去承载敏态业务的运行？首先是业务对于快速响应、快速开发、快速迭代的要求越来越高；其次是单个软件系统越来越复杂，经历着从单体架构向微服务架构的过渡。

而容器技术的兴起，就是基于这样的时代背景，与传统的虚拟机相比，容器天然具备轻量、弹性、高可用等特点，可以和微服务应用结合，达到 1+1>2 的效果，更好地保障应用稳定性。

此外，在 IDC 2021 年的研究报告中提到：新增的生产级云原生应用，在新增应用中的占比，将从 2020 年的 10%增加到 2024 年的 60%。Gartner 在今年最新的一个趋势报告中指出：“到 2025 年, 跑在云原生技术平台上的应用，将占到新开发应用的 95%。由此可见，容器已经作为一项成熟的技术，开始大规模推广落地。

对于单个容器化的应用而言，做好应用的容器化改造，仅仅只是冰山一角，应用上容器的核心目的其实还是为了借助容器 “轻量”、“弹性”、“高可用”的特性来保障应用的稳定运行。

而浮在冰面之下的，还有很多新的关注点，例如“健康检查机制”、“pod 故障自愈机制”、“node 故障迁移机制”、“微服务治理”、“容器安全”等。下面给大家一一解读：

02 容器如何提升应用稳定性？

首先，容器集群与物理机/虚拟机集群相比，最大的特点是具备自动迁移的机制，当集群节点出现故障，导致服务中断后，可根据相关机制，触发对应的实例迁移动作，做到自动化/无感知的在其余健康节点上进行应用服务的迁移。从而保证服务的可用性。

• 默认迁移：当 node 节点异常后，出现服务中断的情况。在默认等待时间过后，会自动将停机 node 节点上的 pod 自动迁移到其他 node 节点上。

• 手动迁移：为避免默认等待时间，还可以使用 cordon、drain、uncordorn 三个标记实现节点的主动维护

• 平滑迁移：平滑迁移能可以实现节点维护期间不低于一定数量的 pod 正常运行，从而保证服务的可用性。

同时，在容器云上，强大的自愈能力也是非常重要的一个特性，默认实现方式是通过自动重启发生故障的容器，使之恢复正常。除此之外，我们还可以利用 Liveness（存活探针） 和 Readiness（就绪探针）检测机制来设置更为精细的健康检测指标，从而实现如下的需求：

• 零停机部署

• 避免部署无效的服务镜像

• 更加安全地滚动升级

面向集群跨数据中心的场景，提供容灾多活的支持能力：

• 横向维度从数据中心各类资源的物理分布视角进行容灾考量

• 纵向维度从应用的数据库、中间件、应用、调度等视角进行容灾考量。

• 同时穿插着容灾应急处理的机制、动作等过程类考量。

分别从 5 个层面，提供容灾双活的核心能力：

• 负载层：全局负载+内部负载两级负载模式，主要是配置

• 应用层：采用平台 Portal 统一管理跨集群（数据中心）应用，统一维护其生命周期（部署、升级、回滚、删除）

• 中间件层：每个中间件分别设计；尽可能减少跨数据中心调用；采用多集群数据同步方案解决跨数据中心一致性；次选采用单边读写，另一侧读/备份的方式

• 数据库层：基于不同数据库的专有方案落地；基于网络情况，决定是否采用单边写，另一侧读/备份

• 此外，还提供容器云平台层的双活能力：

  （1）管理端和集群分别独立部署；

  （2）管理端(含相应的中间件)采用主备方式，备用端日常不启用，只在灾难情况下启用；

  （3）集群由一侧管理端统一管理；

  （4）镜像自动跨集群同步

  （5）集群监控、日志，由各个集群独立维护。

前面我们聊到，将容器作为微服务应用的运行的最佳载体，仅仅只是解决了运行资源层的问题，还需额外考虑如何解决微服务应用治理与监控的问题。

首先需要考虑的是如何兼容各类微服务框架，例如 springcloud、dubbo、以及服务网格 istio。其次是从“微服务应用监控”与“流量治理”这两个角度出发，不断完善和补充微服务应用监控治理层面深度问题的定位与解决。真正达到 1+1>2 的效果。

除此之外，当业务突发波动（如秒杀活动、限量抢购活动）时，因无法准确预估流量有多少, 往往需要提前准备机器；突发流量过后，这些机器往往处于空载的状态。而在 K8S 集群上运行常规业务，可以最优成本并平滑处理突发流量，且无需人工管理节点和容量规划，实现全自动容器无限弹性扩容尤为重要。

针对这种场景，k8s 内置了各类弹性伸缩组件，其中最主要的就是 HPA（Pod 水平自动伸缩）控制器，基于设定的扩缩容规则，实时采集监控指标数据，根据用户设定的指标阈值计算副本数，进而调整目标资源的副本数量，完成扩缩容操作。从而做到有限避免“容量规划”与“实际负载”的矛盾，保障大流量负载的同时，也能提升资源的使用率。

除了需要保证已部署的应用正常运行外，应用通常是需要持续维护和更新的，应用更新时根据变更策略的不同会对服务可用性和服务质量产生不同的影响。在对应用服务稳定性，资源环境约束和业务场景需求等多方因素进行权衡后，可以选择合适的变更策略。

在这个场景之下，往往是常见的“升级”、“回滚”等操作，这部分可以借助容器编排引擎的能力，也有很多企业级容器云平台提供了界面化、自动化配置的能力。

同时，业务的发布往往也会存在多个版本，在新版本服务正式发布前，可以少量部署新版本与上一个版本共存。有效验证和避免新版本可能带来的问题，从而保障应用整体维度的可用性。这对灰度发布提出了新要求。

基于这样的背景，博云自研了增强型负载均衡，既支持比例、请求特征等组合式的灰度策略，也具备代理、限速、租户隔离、自身监控、扩缩容等高级特性，能够有效支撑起业务版本频繁变更后的负载场景。

除了应用本身的高可用外，支撑应用运行的各类中间件也需要高可用保障，使用 operator 的方式来统一封装单实例/高可用中间件，做到中间件的标准化交付。保障容器化中间件高性能高可靠的同时，也能够具备更便捷的自动化运维能力。从而达到“降本增效”的目标。

随着云原生技术的普及，容器集群规模的扩大，集群内外网络直通+跨多集群互访的场景频发，如何解决跨集群访问，已经发展成了一个非常重要又急迫的问题。

在对市面上主流的 CNI 插件进行了广泛的调研后，发现主流的 CNI 插件对以上需求的支持并不理想，难以同时满足如上的网络需求，集中体现在内外网互通、无法支持联邦集群、管理业务网络分离、灵活的网络隔离机制、易于运维管理和调试等问题，于是博云自研一个 Kubernetes CNI 插件来解决这些痛点问题，并命名为 BeyondFabric。

BeyondFabric 网络主要的优势在于高性能、低损耗、并且采用分布式部署，有效避免了单点故障，并且具备自动运维的能力。能够稳定高效的支撑起 overlay/underlay 各类网络模式下的联邦集群互联互通。

在跨多集群服务互访的场景下，一方面可以使用 Fabric overlay 网络方案，将多套集群的网络打通，另一方面可以使用 Fabric gateway 打通第三方任意 CNI 网络的集群。借助 Fabric 方案，可以实现多业务的跨集群部署，从而实现集群级别的容灾，大大提升应用的稳定性保障能力。

在集群内外网络直通的场景下，可以使用 Fabric underlay 网络方案，保证集群内的 pod 能够与外部网络直通，既提升了网络性能，也大大降低了网络层面的复杂度。

同时 Farbic underlay 网络方案支持固定 IP、双向限速、低网络损耗等高级特性。能够很好的支撑各类复杂的网络场景，大大提升集群网络稳定性保障能力。

此外，容器生态环境恶劣，漏洞频发，近年来也引起了大家的广泛关注。在容器化的场景下，传统的安全防护措施只对主机有效，无法检测容器镜像的漏洞和病毒，容器的东西向流量也无法检测和防护，还多了一层需要额外关注的容器安全层。

博云产品团队也做了容器安全产品 BKS，通过一套产品将主机和容器安全联系在一起，增强风险感知和防御能力，有效避免容器逃逸等行为，提供更加全面的安全防护能力。

03 博云容器云产品族

目前，博云容器云产品族整体定位是以“应用为中心，安全的云原生操作系统”，并适配主流信创平台。以应用为中心，以发行版 K8S、容器云平台为底座，上层衍生出了微服务平台、中间件平台、AI 支撑平台，以及容器安全等产品，为客户提供更加全面的云原生支撑。

其中，博云的企业级 k8s 作为最核心的技术底座，目前已经历过大量客户的长期、大规模生产级实践验证，累计为 400+客户提供专业的 PAAS 底座能力支持。

以上就是今天的分享，感谢大家。

点击BoCloud博云了解更多解决方案