容器云平台建设,运维痛并快乐着!

2022-12-12 00:00:00 架构 能力 平台 容器 等级

预计阅读时间5分钟

背景

来源:云原生产业联盟 《云原生发展白皮书》

基于云原生的容器云平台以其高效稳定、快速响应的特点,相对于传统架构,可以帮助企业更好的应对业务规模的不断增长:

  • 的弹性能力,不同于传统虚拟机分钟级的弹性响应,以容器技术为基础的云原生技术架构可实现秒级甚至毫秒级的弹性响应;
  • 服务自治故障自愈能力,具有高度自动化的分发调度,可实现应用故障的自动摘除与重构,具有极强的自愈能力;
  • 大规模可复制能力,可实现跨区域、跨平台甚至跨服务商的规模化复制部署能力;
  • 异构资源标准化,容器技术有效解决了异构环境的部署一致性问题,促进了资源的标准化,为服务化、自动化提供了基础;
  • 提升业务应用的迭代速度,大幅提升交付速度,降低业务试错成本,高效响应用户需求,增强用户体验;

相信看过云原生产业联盟发布的《云原生发展白皮书》,无论是企业或热爱技术的Coder都会跃跃欲试,但是容器云平台的建设不是一蹴而就的:

  • 首先我们需要建设一套稳定、可靠、合规的容器云平台;
  • 其次我们要对传统架构进行改造,应用、中间件、数据库都要进行容器化改造;
  • 后我们将不得不升级技术栈,更好的拥抱云原生,为平台的稳定运行保驾护航;

“ 知彼知己方能百战不殆 ”,因此带着“没有调查、没有参与、没有发言权”的想法,让大家更细致、更全面、更深入的了解容器云平台建设的部分过程。

容器云平台架构

容器云平台架构.png

来源:中国开源云联盟《中国开源云联盟发布企业级容器云平台标准》

企业级容器云平台架构,主要包括管理容器运行引擎、容器网络、容器编排等;非主要功能要求可用性、兼容性、安全、易用性、负载优化等内容。企业级容器云平台主要是实现在云平台上运行应用时取得优化的效果。

如果了解过云原生全景图(Cloud Native Landscape)肯定会对架构图不陌生,同时我们在网上或技术交流云原生过程中经常看到或听到CRI、CNI、CSI等专业术语,因此我们在此统一归纳解释:

  • PaaS          平台及服务(Platform-as-a-Service)
  • OCI            开放容器组织(Open Container Initiative)
  • CRI             容器运行时接口(Container Runtime Interface)
  • CNI            容器网络接口(Container Network Interface)
  • CSI             容器存储接口(Container Storage Interface)
  • CNM          容器网络模型(Container Network Model)
  • DevOps      开发运维自动化(Development and Operations)
  • LDAP          轻量目录访问协议(Lightweight Directory Access Protocol)
  • SLA             服务等级协议(Service-Level Agreement)
  • CI/CD          持续集成/持续交付(Continue Integration/Continue Delivery)
  • QoS            服务质量(Quality of Service)

以上缩略词都分布在架构图中运行时环境、容器编排、管理等不同层面,同时也是容器云平台建设过程中我们需要重点关注点。

容器云平台建设

为了让大家更好的体验,现对容器云平台建设的部分思路做了简单梳理。

容器云建设.png

1.准备工作

(1)需求梳理

合规需求

由于不同行业都要遵守「网络安全等级保护制度」,例如金融行业要达到等保三或更高的等保四级。因此在建设容器云平台时,我们首先想到的是合规需求,即无论是自建或是采购都需要以等保和监管合规为基线。

合规来源:腾讯金融云合规性https://cloud.tencent.com/document/product/304/2766

金融专区机房建设及云平台管理系统遵循的行业标准为:

  • 《商业银行数据中心监管指引》
  • 《银行集中式数据中心规范》
  • 《金融业信息系统机房动力系统测评规范》
  • 《金融行业信息系统信息安全等级保护测评指南》
  • 《商业银行信息科技风险管理指引》
  • 《银行业信息系统灾难恢复管理规范》
  • 《网上银行系统信息安全通用规范》
  • 《商业银行业务连续性监管指引》

参考的监管单位发文要求:

  • 《银行业金融机构外包风险管理指引》
  • 《银行业金融机构信息科技风险监管指引》
  • 《中国银监会办公厅关于加强银行业金融机构信息科技非驻场集中式外包风险管理的通知》
  • 《中国银监会办公厅关于开展银行业金融机构信息科技非驻场集中式外包监管评估工作的通知》
  • 《保险信息安全风险评估指标体系规范》
  • 《保险公司信息系统安全管理指引(试行)》
  • 《证券公司网上证券信息系统技术指引》
  • 《证券期货业信息系统安全等级保护测评要求》

等保来源:网络安全等级保护网http://www.djbh.net/webdev/web/HomeWebAction.do?p=getGzjb&id=8a81825674296d130174bdf702c8002e

等级保护2.0标准体系主要标准如下:

  • 网络安全等级保护条例(总要求/上位文件)
  • 计算机信息系统安全保护等级划分准则(GB 17859-1999) (上位标准)
  • 网络安全等级保护实施指南(GB/T25058-2020)
  • 网络安全等级保护定级指南(GB/T22240-2020)
  • 网络安全等级保护基本要求(GB/T22239-2019)
  • 网络安全等级保护设计技术要求(GB/T25070-2019)
  • 网络安全等级保护测评要求(GB/T28448-2019)
  • 网络安全等级保护测评过程指南(GB/T28449-2018)

关键信息基础设施标准体系框架如下:

  • 关键信息基础设施保护条例(征求意见稿)(总要求/上位文件)
  • 关键信息基础设施安全保护要求(征求意见稿)
  • 关键信息基础设施安全控制要求(征求意见稿)
  • 关键信息基础设施安全控制评估方法(征求意见稿)

功能需求

有了等保和监管合规为标准参考,我们就可以更有针对性的对不同功能区做进一步的要求,如下我们从基础架构、运维管理的角度做了规划:

  • 集群管理

    支持多集群管理、对接LDAP、RBAC授权、集群版本平滑升级、集群扩缩容、多云管理等

  • 网络管理

    支持不同的网络分区(DMZ区/内网区/外联区/专线区)隔离、underlay/overlay网络、固定IP或IP段等

  • 存储管理

    支持多协议存储(如块、文件、S3)、横向扩容等

  • 应用管理

    支持CI/CD、DevOps、灰度发布、弹性伸缩、中间件等

  • 运维管理

    支持不同维度监控(如:组件、节点、网络、存储、容器、链路追踪等)、监控大盘、自定义告警规则、多渠道告警等

  • 安全管理

    支持安全扫描策略、配置巡检并提供巡检报告、集群事件审计

  • 服务保障

    提供可承诺的SLA、提供定期平台巡检等

  • 兼容性

    支持信创及兼容主流硬件设备

  • 镜像管理

    支持镜像安全扫描、镜像同步、镜像回收和清理策略等;

(2)架构总结

为了更好规划容器云平台建设进度,我们需要从以下三方面进行盘点:

  • 基础资源总结

    容器云平台需要几个节点?这个数据并不是随口一说,而是要有数据支撑,此时我们就需要对现有的业务使用的基础资源进行盘点,并以此为基准,按容量规划进行相应的调整就可得出一个比较准确的数据。

  • 网络架构

    容器云平台需要几套集群?金融行业对网络要求比较严格,因此会有多分区的情况,此时集群就需要按网络分区数量确定。如果网络只有一个分区,就可以使用一套集群。

  • 技术架构

    容器化需要改造哪些内容?因此我们要关注当前的技术架构,大致可分为网络使用underlay还是overlay、应用无状态改造、中间件容器化、数据库容器化、配置中心、微服务升级服务网络等,越是基础架构就越需要投入更多的精力来确定一套适合公司现状的佳实践。

厂商能力

如果我们的容器云平台不是自建,而是考虑采购第三方商业产品来进行技术兜底,如何从众多厂家中选择无论产品能力还是技术能力都比较靠谱的呢?结合CNCF及相关第三方的数据证明,我们将其进行了整合。

(1)云原生能力

云原生能力主要由CNCF进行了认证:

  • 通过CNCF推出的Kubernetes 一致性认证
  • KCSP 合作伙伴
  • CNCF基金会成员

只有符合以上三条是CNCF社区认可的,肯定比我们要更权威。

(2)其他能力

在云原生能力外,我们还要参考第三方的数据来证明厂商的市场占有率、技术成熟读等

  • Garnter  CaaS(容器即服务) 名单

    Garnter 中国 ICT 技术成熟度曲线,分为 5 个阶段:技术萌芽期,期望膨胀期,泡沫破裂低谷期,稳步爬升复苏期,生产成熟期。

  • IDC 市场占有率

  • 可信云容器解决方案

    中国信息通信研究院提出的,针对以Kubernetes、Docker等为代表的云原生技术解决方案的评估。

结合云原生能力和三方数据的支撑,相信能够帮助我们更好的识别三方厂商的能力。

制定方案交流计划

相关无论是自建还是三方采购,如果只依赖于现阶段我们对容器云的了解肯定是不足的,因此在有资源的情况下需要多和容器云厂商进行交流,来听取更多的不同行业、场景的解决方案。

对于和厂商的交流并不是得过且过的随便一听,我认为也是要求规划的,大体可分为以下两个阶段:

  1. 轮交流:了解厂商产品能力

   结合前期准备工作收集的合规、功能、架构三方面的数据,有针对性的了解厂商的产品能力,和厂商进行可行性方面的探讨,为后续的工作打好基础。

  1. 第二轮交流:从基础架构、微服务、DevSecOps、安全等四方面展开深入交流。

   交流前应将容器云建设的几个方面划分优先级,先按高优先级重点深入交流,其他可再多搞几轮交流。

如果细心的同学可以发现,我们重点关注的内容主要是围绕“云原生定义”而展开的。

云原生定义.jpg

总结

在项目的开始阶段,我们需要投入更多的精力去分析需求、总结现有数据、确定需求、为寻找解决方案做规划,因此非常重要,只要保持一个清晰的思路,相信我们就成功了一半。而后续方案交流中的技术细节,我们需要做的是选择题,找出一套适合我们的方案即可。

当然本文只是容器云建设过程中的一小部分,这部分可以让我们在前期发现自身的不足,在建设过程不断推进中逐渐提升自己,去全面拥抱云原生。

相关文章