查看原文
其他

某汽车主机厂容器最佳实践 —— 需求定义

戴佳顺 twt企业IT社区 2024-02-18

本文介绍了某汽车主机厂容器平台项目的选型规划、设计和实施,分三部分连续推送,第一部分:某汽车主机厂容器最佳实践——技术可行性分析(点击标题可回顾),今天是第二部分。


1.项目目标

随着我司业务的进一步发展,为成为国内领先世界一流的汽车制造企业,汽车业务服务需要进一步拓展。为了更加快捷有效地为业务服务提供IT支撑,为了更加敏捷便利地应对业务高峰,为了更加快速高效地IT开发交付,我司启动了容器云平台项目,构建跨数据中心统一容器云平台。通过该平台的搭建,改善了IT的项目交付模式,将传统以虚拟机加应用的交付模式,以容器镜像进行交付。同时统一管理容器实例,以更好应对业务变化,并提升IT基础硬件资源利用率。

本平台的主要系统用户包括:我司信息系统部相关人员

本平台支撑的业务系统用户包括:我司相关人员,我司经销商/供应商相关人员,普通消费者等。

主要项目目标:

  • 实施我司容器化云平台

  • 建立容器化应用交付及运维标准

  • 集成我司现有相关基础架构平台接口(包括VMWare,存储,网络,DNS等)

  • 集成我司现有相关软件平台接口(包括DevOps相关CI/CD集成,相关认证体系集成等)

  • 基于我司容器化云平台实施三个以上基于Docker的轻量型PaaS服务(包括Tomcat,Redis,Nginx等),并为二阶段重量型数据服务(Mysql,Oracle等)提供解决方案

  • 调研我司现有服务方案(包括IaaS,CaaS,PaaS及Oracle等外部平台),为二阶段CSP(Cloud Service Platform)实施提供解决方案及演进路线

本项目要求以我司容器化云平台建设为主要任务,完成容器化应用交付及运维标准的落地。完成需求定义、平台构建、平台测试、平台上线、周边系统配合改造及上线、相关人员培训和质保服务;技术部分和其他非功能性需求和其他需求遵从后续说明。
本项目软件范围包括宿主机以上部分(OS层,容器层及相关周边实现)。

实施范围包括容器云平台建设:

  • 平台方案:具体参考下述章节。

  • 平台容量:平台规划第一年运行二十个物理节点,第二年运行六十个物理节点,第三年运行一百个物理节点。支持第一年二十个物理节点,涉及至少两个数据中心。


2.项目功能性需求

2.1 应用定义

容器实现:本项目定义Docker作为容器实现。

平台支持应用以“Pod”模式定义,以明确其内部子应用依赖关系。

2.2 伸缩场景

2.2.1手工伸缩

平台支持以“应用”或“Pod”进行手工伸缩。应用在伸缩期间伸缩的实例由于不可用,应不对外服务,其他实例对外服务保证正常可用。当新容器实例伸缩完毕并且平台验证通过后新实例才可对外提供服务。

2.2.2自动伸缩

平台支持以“应用”或“Pod”进行自动伸缩,可通过识别KPI包括CPU,内存等阈值实现。

当KPI达到指定阈值应进行自动扩展直到KPI低于阈值或达到设置的上限;恢复初始水平时支持自动收缩。应用在伸缩期间伸缩的实例由于不可用,应不对外服务,其他实例对外服务保证正常可用。当新容器实例伸缩完毕并且平台验证通过后新实例才可对外提供服务。

2.3 负载均衡

针对多个应用或Pod,平台应提供负载均衡服务,可支持DNS暴露或反向代理暴露。服务对外暴露应自动化。

平台应集成我司现有网络及DNS方案,具体参考网络章节。

平台的负载暴露点本身应高可用。

2.4 资源隔离及分配

平台应支持管理跨数据中心所有容器平台节点(管理节点,运行节点)的所有资源,包括CPU,内存,存储,网络等。

其中管理节点应支持普通应用隔离功能,即管理节点默认不会进行普通应用容器的运行支撑。运行节点应支持资源隔离,包括CPU,内存,网络等。

平台应支持数据中心中运行资源的逻辑分片,支持基于计算资源分片的多租户隔离。

2.5 健康检查/监控与告警

平台应支持各层次健康检查和监控告警。包括基础资源层,容器平台层,应用层。

基础资源层:平台应支持基础计算资源的监控告警,对于节点故障根据预设规则可进行应用漂移。对于节点或平台的资源不足应支持多渠道的告警。

容器平台层:平台应支持容器平台的监控告警,对于容器故障应进行应用漂移。本身应支持日志聚合和显示(包括在线容器,历史容器,日志聚合)。

应用层:平台应支持应用探针及监控告警。本身应支持日志聚合和显示(包括在线容器,历史容器,日志聚合)。

针对多个渠道的日志,应支持基于日志规则的多渠道监控告警。

日志查看权限参考用户权限管理章节。

2.6 存储

平台应对常见应用的存储依赖(包括应用,中间件,日志,本地文件,共享文件等)针对其特性给出建议的存储解决方案。

平台应支持不同类型的存储挂载,包括临时文件系统,宿主机文件系统,EMC块,S3,NFS及其他常见分布式文件系统。

平台应定义本地宿主机所使用的容器文件系统。

平台应集成我司现有EMC 块及S3文件存储。

2.7 高级调度策略

本项目定义kubernetes作为调度平台。

平台应支持高级调度策略,包括应用灰度部署,应用剔除等。同时平台应更合理的利用机器资源,自动平衡各宿主机运行状态。

2.8 参数配置及容器CMDB

平台应隔离不同环境的参数差异,包括开发环境,测试环境,生产环境。建立统一配置中心,支持各环境的不同参数或指定位置配置文件部署。

统一配置中心权限参考用户权限管理章节。

2.8.1应用配置

应用配置包括应用构建容器所附加的参数,类似Docker file定义。需要支持基于不同环境定义。通过应用配置可自动进行容器镜像构建或在运行容器时进行外部配置文件目录挂载。

2.8.2容器CMDB

容器配置包括容器镜像名定义,容器运行时所附加的参数定义,容器外部依赖定义等。需要支持不同环境定义。通过容器配置可自动进行容器镜像部署。
容器CMDB应支持应用拓扑展现,可以图式展现应用及依赖关系。

2.9 镜像管理

平台应支持企业级镜像管理,包括只读,可写,拒绝权限的镜像访问,及对应的部门组访问权限。应支持镜像空间回收功能,自动删除长期不用镜像及逾期待物理删除镜像等。

2.10 镜像安全

容器镜像应支持镜像安全扫描,并自动根据常见OS安全列表(包括且不限于Debian,Ubuntu,Red Hat,Alpine)更新CVE安全数据库。

2.11 多集群应用部署

平台应支持集群逻辑分片及跨数据中心管理。

针对不同组和数据中心管理权限参考用户权限管理章节。

2.12 网络

平台应基于我司相关网络环境给出容器虚拟网络方案,并在对应环境中进行验证。我司目前网络基于思科ACI。

平台网络方案应与我司目前的网络及管理设施进行集成,方便我司网络管理人员在同一平台进行管理维护。

平台应支持设置虚拟网络ACL规则。同一应用或Pod容器间网络应支持互通,不同应用,Pod容器,逻辑分片之间网络默认隔离,但可按需开通访问。

平台应支持搭建子域名解析DNS服务器,用于上层DNS的NS记录指定。

2.13 控制台

平台应提供完整管理功能的控制台,用于不同权限用户日常操作。原则上所有定义的用户操作均应通过控制台而非命令行进行。

平台同时支持基于开放API的二次开发和集成。

2.14 DevOps支持

本项目定义Jenkins(Pipeline)作为CI/CD流程调度平台,GIT/SVN/TFS作为代码管理平台。

平台应贯穿业界DevOps理念,同时整合我司DevOps CI/CD相关系统。

2.15 PaaS支持

平台应支持基于容器的PaaS服务。构建基于容器的Tomcat,Redis,Nginx等中间件服务,同时提供统一运维监控方案。

平台应调研二阶段重量型数据PaaS服务(Mysql,Oracle等)整合,并给出演进路线。


3 项目非功能性需求

3.1 高可用要求

3.1.1管理节点高可用

平台本身需要保证高可用。个别管理节点故障不影响平台本身管理功能。

3.1.2运行节点高可用

单个运行节点本身无法保证高可用,但运行节点故障只影响该节点本身。

平台应提供探针等功能识别应用及所运行节点的健康性,当管理节点识别到故障时应进行应用漂移,将其偏移至其他健康节点。

3.1.3其他节点高可用

其他关键组件应保证高可用。包括且不限于DNS服务,存储服务,反向代理服务,镜像存储服务等。

3.1.4平台升级时高可用

平台进行升级操作时应实现高可用及灰度切换。避免管理节点升级导致平台本身不可用,同时避免运行节点升级导致平台或业务应用不可用。

3.2 用户权限管理

平台应针对不同数据中心资源进行逻辑分片,支持多个数据中心及每个数据中心多个逻辑分片权限设置。权限包括只读,可写,拒绝访问等。

用户认证应集成我司的统一SSO服务。

3.3 用户友好界面

设计界面可充分借鉴当前已有的我司界面风格,需要显示我司相关logo标识。

3.4 用户界面响应要求

针对非报表类业务功能,系统应保证2S内数据返回。针对报表类业务功能,系统应保证10S内数据返回。

3.5 用户功能点使用记录

对于用户功能使用应进行记录。

3.6 浏览器要求

系统必须同时支持IE11,Firefox,Chrome等HTML5规范的浏览器

3.7 平台及组件升级

平台核心组件(包括容器,调度等)应具有模块化及可升级性。乙方需要在方案中提供对应组件未来的灰度升级方案。原则上升级方案应不对平台所负载的业务应用可用性产生影响。具体要求参考平台升级时高可用相关章节。具体升级实施在后续MA过程中进行落实。



作者:戴佳顺,汽车行业8年工作经验,6年以上经销商领域应用架构设计和系统开发工作,具有非常强的架构解构和落地能力。目前正在负责PaaS平台和云服务平台建设工作,基于IT4IT理念为企业构建涵盖IaaS、PaaS和SaaS的一体化云平台。



明天将继续发布第三部分:某汽车主机厂容器最佳实践——实践历程


点击阅读原文,关注社区最近的交流活动“汽车制造行业容器云平台设计与实践在线答疑”


长按二维码关注公众号

继续滑动看下一个

某汽车主机厂容器最佳实践 —— 需求定义

戴佳顺 twt企业IT社区
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存