容器云平台运维的范围与架构设计

   

【导读】容器云平台有其独特的特点，不同于传统系统的运维。本文分享了作者对容器云平台运维范围和运维架构设计的思考与实践。

一、容器云平台运维范围

（一） 梳理要运维哪些内容

作为运维专家，您的职责至关重要：以最佳实践确保系统稳定运行，从而保障业务顺畅运营。系统故障直接影响业务，可能导致客户流失和损失。因此，运维人员必须透彻理解运维职责。这将指导您设计和实施高效的部署和运维架构。

容器云平台运维涵盖基础设施资源（服务器、存储、网络层、操作系统）以及平台自身（Docker、Kubernetes、镜像仓库）的维护。其还涉及日志、监控、告警、权限认证、配置等。
关键点在于支撑应用运维，包括部署、迁移、状态监控、告警、扩容、伸缩、配置更新、流量管控、负载均衡、访问控制等。

（二） 明确运维的工具和手段

高效运维的关键在于工具和方法，它们能将运维效率提升指数倍。掌握和运用合适的运维工具和方法，让软件运维不再是赤手空拳的挑战。

Google SRE 团队利用自动化运维工具、监控工具和配置管理工具，提高运维效率和系统稳定性。这些工具显著简化了日常运维流程，从而提升系统可靠性。

（三） 选择运维架构

不同的系统运维方法和运维架构也是不一样。容器云平台有其独特的特点，不同于传统系统的运维。对运维人员来说，最大的要求就是确定性。容器的弹性、自恢复、自动迁移等特性在带来便利的同时也带来了不确定性。特别是在庞大的云计算环境。不确定性会对运维人员来说面临着巨大的压力。因此作为运维人员就需要选择合适的架构来规避不确定性和不稳定性。结合容器云平台的特性和 API 网关组成两层服务治理体系，在提高安全性和可靠性的同时也充分利用了容器的轻量弹性特点。

（四） 开发测试和运维工作的差别在哪

运维与开发测试有着截然不同的目标。开发追求敏捷和速度，而运维则优先稳定性和可靠性，以最大程度地降低风险。
然而，完全的稳定是不现实的。为了实现动态稳定，运维需要利用容器的弹性和可移植性，以应对变化并保持系统可用性。

（五） DevOps和SRE的精髓在哪里

DevOps 追求开发运维一体化，但在国内并没有多少人真正思考 DevOps 该如何落地。Google SRE 我觉得是一种非常好的实践，他并没有要求开发人员去做运维，而是很多运维人员去做开发，而开发的主要是运维工具。

所以我们看到国内很多 DevOps 的宣传其实都是很片面的，并不是基于实践的总结，而是概念的炒作。当前云计算环境下的运维已经不同于传统的应用系统运维。当前应用系统逐步的融合、微服务化，以云计算为底座，云就像一个大的容器， docker 是这个大的容器中的小容器，承载微服务应用的敏捷部署和弹性伸缩等能力。

为提升运维效率并保障系统稳定，应侧重于采用或自主开发合适的运维工具。这些工具有助于提高工作效率，同时维护系统的稳定性。

开发人员的运维工作量与开发工作量比例为 1:4。这意味着一名开发人员负责的运维工作量是开发任务的四倍。如果同时承担运维任务，开发人员将陷入繁琐的运维事务中，影响开发效率。

二、 运维架构设计

（一） 镜像仓库的作用

云平台镜像仓库：互联环境，高效协作
镜像仓库可跨集群和平台共享，充当不同环境之间的桥梁。测试和开发、生产和测试环境可使用独立镜像仓库，实现镜像隔离。仓库支持镜像同步和操作，确保环境间数据一致性，提升容器云平台运营效率。

镜像确保不同环境部署一致，标准化应用分发。镜像仓库作为连接点，可隔离开发、测试、生产，提升安全和稳定。它促进了应用分发的标准化，提供了环境一致性，提高了稳定性和安全性。

（二） 实践SRE

SRE 强调运维人员具备开发技能，打造全能型人才。
国内对运维误解颇深，认为不懂开发者才从事运维。
提升运维效率的关键在于采用工具和自动化。
分离资源运维和应用运维，让专业人员专注于专业领域。

（三） 运维分层

运维涵盖范围广泛，从基础设施资源到应用维护。为了提升运维效率，建议将运维内容划分为三个层次：
* 基础设施资源：网络、服务器、存储等物理基础设施的维护。
* 平台：操作系统、中间件等支撑应用运行的环境的维护。
* 应用：业务系统及相关软件的维护。
通过分层管理，运维人员可专注于各自领域，提高运维服务质量。

（四） 接口标准化

高效协同的关键在于标准化接口。如同基础设施团队提供资源服务，需建立云管平台实现标准化的虚拟机接口服务，确保灵活扩展和动态扩容能力。

（五） 流程自动化

提升运维效率，自动化是关键。
自动审批虚拟机申请，消除人为阻碍。
预先定义IP地址段、配置参数等，自动创建虚拟机，满足不同需求。

（六） 将资源运维与应用运维分离

资源运维涵盖服务器、网络、存储和虚拟化等基础设施资源的维护。借助自动化工具，大部分任务可实现标准化。
监控管理系统可满足基本需求。多云资源管理需求兴起，带来一定复杂性。

容器平台资源运维专家负责基础设施资源的维护，涵盖网络、存储和虚拟化等专业领域。他们确保资源稳定运行，为容器云平台和 PaaS 平台提供可靠的基础。

（七） 应用运维是核心

容器云平台的核心在于赋能应用运维，为业务应用提供更便捷、高效的管理。
通过全面的应用管理能力，容器云平台简化了应用运维的工作，从部署、监控到弹性扩缩容、灰度发布等各个环节，为应用提供了全方位的支持。这使业务应用使用团队能够在平台提供的基础上，轻松高效地完成应用运维任务，从而提升应用性能和稳定性。

（八） 平台和组件支撑应用运维

容器云平台的运维重点在于平台和周边组件的持续完善和优化。通过开发和建设运维工具、流程和方法，运维团队可以优化平台运维，更好地支撑应用运营。

（九） 微服务架构微服务治理是难点

应用运维中，微服务架构下，服务治理可能是个难点。微服务架构带来了服务运维的复杂度，服务的部署、迁移、弹性伸缩、流量分发、内外部负载均衡、高可用、稳定性等需求对容器云平台支撑的应用运维能力要求很高。选择了什么样的微服务架构，如何更好的管理治理好微服务， 是容器云平台不得不考虑的一个重要问题。比如微服务中实现了注册发现，比如用 springcloud 的开发框架，已经有了一套自己的服务治理方法，如何跟容器云平台更好的融合？开发的微服务是否需要自己去实现注册发现，流量控制，熔断降级等机制，或是简单可以在容器云平台来实现？

我们有个需求是根据响应时间来弹性扩容。我们没有采用 cpu 内存作为弹性伸缩的指标，因为 cpu 内存是不准确的。Java 内存机制不适合采用内存方式，而 cpu 变化又太快，如果拉长时间则可能导致延误，出现大量超时。所以根据响应时间作为扩容指标则相对更优。那么这就需要在服务网关或容器云平台或者 api 网关来实现了。服务网关的话需要开发人员自己实现，每个团队都需要部署个这么的网关，明显不合适。在容器云平台如果实现这样的能力，则每个服务都可以直接使用。形成了标准化。

（十） 两层治理体系

采用分层服务治理：
- 容器云平台层：利用容器优势，高效管理云原生应用。
- API 网关层：满足传统应用的服务治理需求，无缝对接容器云平台。

混合云环境中，API网关可优化微服务治理。
当传统系统不适合或无法完全容器化时，API网关提供两层微服务治理体系，提高管理效率和维护便利性，有效管理非容器化或部分容器化的微服务应用。

容器云平台架构：
分离开发测试运维流程，聚焦应用管理。分析资源、平台和应用运维，实现双重服务治理。利用容器优势，规避弱点，提供高效、稳定的容器化解决方案。

 

-对此，您有什么看法见解？-

-欢迎在评论区留言探讨和分享。-