共计 3229 个字符，预计需要花费 9 分钟才能阅读完成。
在金融行业数字化转型的驱动下，国有银行、股份制银行和各级商业银行也纷纷步入容器化的过程。
如果以容器云上生产为指标，那么整个容器云平台的设计、建设和优化对于银行来说是一个微小的挑战。如何更好地利用云原生技术，帮忙银行实现麻利、轻量、疾速、高效地进行开发、测试、交付和运维一体化，从而重构业务，推动金融科技的倒退，是个长期课题。
本期云原生漫谈，将和您独特摸索，云原生时代智能运维的进阶之路。
随着金融业务的疾速倒退，撑持业务的 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 运维的倒退方向。咱们也期待着可能帮忙更多企业实现云原生时代的智能运维进阶。
