在金融行业数字化转型的驱动下，国有银行、股份制银行和各级商业银行也纷纷步入容器化的进程。
如果以容器云上生产为目标，那么整个容器云平台的设计、建设和优化对于银行来说是一个巨大的挑战。如何更好地利用云原生技术，帮助银行实现敏捷、轻量、快速、高效地进行开发、测试、交付和运维一体化，从而重构业务，推动金融科技的发展，是个长期课题。
本期云原生漫谈，将和您共同探索，云原生时代智能运维的进阶之路。
随着金融业务的快速发展，支撑业务的IT基础设施的变化节奏也大大加快。
金融IT运维团队对IT基础设施运维的任务，比以往任何时候都要更加艰巨。核心是保障生产安全运营，并提高软硬件环境的交付质量。然而在今天的金融IT 3.0时代，IT需求变得越来越强，变化越来越快，服务器等数量爆增，管理起来日益繁杂。同时，运维管理规模的不断扩大，运维人员的不断扩充，使得日常运维工作面临着双重的压力与风险。
以容器、微服务为代表的云原生技术催生了新一代云原生运维技术体系，可以帮助金融企业最大化释放运维效能。基于多年来的实践经验，我们对于来自金融行业一线的运维问题进行了回答：
相较于虚拟机，容器的运维和监控有什么优劣势？为什么说基于K8s的容器是实现智能运维的必然选择？高并发场景下，如何实现容器的自动扩缩容？如何快、准、狠地排查容器中的应用问题？容器的智能运维有无成功实践案例？
希望本篇文章能为您提供借鉴。
相较于虚拟机，容器的运维和监控有什么优劣势？
从运维的角度来看，容器的轻量化使得运维更加灵活高效，更方便应用自动化来提升运维效率。
相较于传统运维，容器可以实现：
更快速部署和交付：对于应用系统的部署可以极大地节省时间成本和人力成本；
更标准化交付物：容器的标准交付物为镜像，包含应用程序和依赖环境，一次构建多次使用，大大简化了应用交付模式；
更高效的资源利用：容器不需要虚拟机额外的管理程序，依赖内核运行，在运维资源开销上要低的多；
更加敏捷的迁移和扩展：容器可以跨操作系统、跨环境运行，实现无缝迁移的效果，以及高并发场景下的自动扩缩容。
从监控的角度来看，轻量化的容器也带来了监控的复杂度，特别是大量容器运行的平台如何排错和根因分析。
由于容器是黑盒运行，在运维中容器问题的诊断比较复杂；由于容器运行的密度比较大，需要面对的运维实体和对象数量会很庞大；由于容器的自身特性，容器的创建、销毁等生命周期过程，各类运维数据的采集是个挑战。另外容器启动后，监控系统怎么发现，同时需要对其做哪些数据采集，这些问题都是容器监控自动化过程需要解决的。
在监控这个领域，除了目前比较热门的纯软件层全链路监控以及混沌工程，建议应该结合硬件的监控和检测实现端到端的监控和测试，以提升平台的稳定性和效能。
为什么说基于K8s的容器是实现智能运维的必然选择？
随着容器的不断成熟，越来越多的金融企业选择利用容器来搭建业务系统。可是，大家在实际操作中发现，像 Docker 之类的容器引擎，更适合管理少量容器，而如今的云原生应用、机器学习任务或者大数据分析业务，动辄就要使用成百上千的容器， K8s就自然而然地成为了实现智能运维的必然选择。
首先是 K8s 采用声明式 API，让开发者可以专注于应用自身，而非系统执行细节。比如，在 Kubernetes 之上，提供了 Deployment、StatefulSet、Job 等不同类型应用负载的抽象。声明式 API 是云原生重要的设计理念，有助于将系统复杂性下沉，交给基础设施进行实现和持续优化。
此外，K8s 提供了可扩展性架构，所有 K8s 组件都是基于一致的、开放的 API 进行实现和交互。开发者也可通过 CRD（Custom Resource Definition）/ Operator等方式提供领域相关的扩展，极大拓宽了 K8s 的应用场景。
最后，K8s 提供平台无关的技术抽象：如 CNI 网络插件, CSI 存储插件等等，可以对上层业务应用屏蔽基础设施差异。
高并发场景下如何实现容器的自动扩缩容？
首先，建议先做好容器云平台配套的监控、日志的建设，再去建设自动扩缩容的自动化能力。
一般可以在高并发场景下使用 K8s 的Horizontal Pod Autoscaling（以下简称HPA）, 通过HPA功能，可以实现容器的自动弹性扩缩容功能。对于K8s集群来说，在高并发场景下HPA可以实现多种纬度的自动化功能，例如当工作负载上升的时候，可以创建新的实例副本来保证业务系统稳定运行，当工作负载并发下降的时候，可以销毁副本实例来减少资源消耗。当前的自动伸缩的指标包括：CPU，内存，并发数，网络传输等。
此外，从整体实施的角度来看，建议聚焦于场景驱动，先从某个业务应用开始逐步试点和推广，运维团队逐步积累到各个场景下业务应用的扩缩容的触发指标、阀值和评估扩缩容成效，最终实现全面的自动扩缩容。
如何快、准、狠地排查容器中的应用问题？
建议可以从以下三个层面来排查容器中的应用问题：
业务层面
通常我们说的微服务链路追踪、流量追踪用来解决业务层的问题 说的微服务链路追踪、流量追踪用来解决业务层的问题，正常情况下会引入服务网格平台，好处是不会受开发语言限制（当然SpringCloud也是可以，只是局限在Java应用里），可实现链路追踪，发现业务API调用关系，对处理业务故障拍错很有帮助。
容器层面
容器层面的问题解决相当于传统情况下对包、配置、进程、OS等进行分析和调优，这点通过切入容器环境进行排障分析。值得一提的是在灵雀云的产品中，提供对容器debug的独特功能，可以通过临时添加debug容器到目标pod中的方式对目标容器进行各类测试，避免直接登录进入业务容器而导致风险或业务容器中没有需要的debug工具。
网络和数据包层面
可以通过trace、tcpdump、流量镜像等方式对数据包分析，这点通常需要CNI插件支持，一般的calico、flannel都无法做到，可以考虑采用开源的Kube-OVN插件作为容器CNI，可以有效帮助解决网络层排障的问题。
容器的智能运维有无成功实践案例？
我们以某大型车企的云原生容器应用为例，2018年，在高并发访问、高吞吐量以及车辆的车联网接入需求推动下，其智能网联应用做微服务的改造和应用容器化，“智能网联开发院”和“数字化部门”联合起来对整个平台架构进行了相应的设计，在平台建设中核心痛点就是需要引入一个微服务的治理平台，以及一个业务应用的管理平台，来支撑整个智能网联平台的开发需要。
项目依托于灵雀云ACP管理平台，配合微服务治理平台，实现了业务应用的运行以及业务应用治理的工作。项目一期实现部分服务器的纳管，形成计算资源池，为业务应用提供部署资源。同时，通过微服务治理功能，实现为业务应用的不同部门或者不同开发团队，适配相应的容器化集群。
当然，平台的落地并不能只是把工具提供给了客户，让客户更好地用起来，也是一个非常大的挑战，尤其对于微服务这样比较新的概念来说。灵雀云在项目当中也为客户提供了微服务治理咨询服务，对于微服务的拆分，微服务改造，以及如何更好地使用平台的各种功能都提供了有针对性的咨询服务。
经过几年的努力，该车企的营销数字化业务的不同业务系统都逐渐迁移到这个平台上来。这么大规模的平台和业务应用，运维人员可能只需要3~5个人。
对于他们来说，能得到的收益，首先就是统一业务系统的开发架构，第二是统一了业务系统的部署架构，第三是极大地减少了复杂的业务系统运维，少量的人员就可以支持大量的业务系统的运维工作，同时，通过平台的资源自动伸缩、微服务治理能力，实现了智能化的业务运行、运维和业务治理。
搭建云原生运维体系非一蹴而就，需要循序渐进，在安全可控的基础上逐步扩展。在技术层面，合适的云原生技术平台可以帮助企业释放运维的巨大压力，并保证安全稳定。我们相信，在数字化转型的大背景下，减少人力参与的智能运维势必会成为未来IT运维的发展方向。我们也期待着能够帮助更多企业实现云原生时代的智能运维进阶。