赵浩廷-智造产线边缘的云原生规模实践

智造产线边缘的云原生规模实践 赵浩廷红帽软件架构师 赵浩廷 红帽软件制造行业解决方案 在IBM和Red Hat工作，参与过售前和交付工作中间件云原生DevOps和制造业有不解之缘：整装型为主，也参与过一些炼化类从早年的工厂流程信息化、生产质量管控到数字化产线 目录 边缘侧云原生的业务驱动力1资源受限下的架构设计挑战2开源设计模式参考3落地业务场景：MES、PLC和管理4Q&A5 边缘侧云原生的业务驱动力 智能制造关注的趋势引领IT/OT融合 典型工业制造场景（整装）： 生产了多少产品（那种产品），有多少在制品（在制品状态）产品的质量如何（多少次品），出现质量的产品的在哪里消耗了多少资源（原材料，包材，人工时）产品和批次能否追踪追溯（BOM，物料，操作，设备参数）工厂的生产效率是多少，生产成本（创造价值）多少如果改变生产计划会有什么样的影响 制造业中的IT和OT系统必须服务于两个目的：数据和分析以及控制 IT和OT在业务成本压力下渐渐出现整合与融合 制造自动化的架构从硬件定义转向软件定义 Why NOW?技术成熟度满足行业趋势 资源受限下的架构设计挑战 边缘云原生架构设计的需求和约束 ●对成本高度敏感（“按成本设计”） ●无人工厂（“熄灯操作”） ○维护意味着安排现场作业由非专业人员更换○节点故障恢复能力（自我修复；继续以降低的容量运行；或者上级备份支撑点）○对集群重启的恢复能力（例如从站点范围的电源故障中正常恢复） ●边缘规模 ○对具有1 0种不同配置的1 0万个站点进行变更管理○高度可并行化：集中式策略/管理，但完全本地执行 ●运维人员无法水平扩展，对自动化提出的需求 ○能够以完全可重复的方式远程操作○升级软件和配置、扩展、备份/恢复、重建整个堆栈，无需CLI ●空间、功率、热设计、电尘约束站点 结合实际场景所定义的前置条件 ●将故障域限制为单个站点/设备●容忍单个设备故障和断电（→单个集群重新启动）●容忍不完善的网络上行连接●无共享架构（shared-nothing architecture）：平台级别没有分发/拉伸/联合 结合实际场景所定义的前置条件 对成本极为敏感（必须保持每个站点的修复成本/开销很小）。通常也受到严重的（空间、灰尘、静电干扰、电力、冷却……）资源限制。 ●每个站点/设备的系统冗余度<1 0%，●1个节点非HA /3个节点HA的最小空间占用●根据需求增加容量的能力（节点纵向扩容，基于基线配置）●空间小-每个站点没有备用/空服务器或者只有1 -2个工控机容量余量，●能够分配多个角色/将角色重新分配给节点而无需重新配置， 如何集中管理数百万个站点/设备？ •站点/设备根据集中管理的策略/配置自主实施部署与配置。•无需通过WAN进行配置（PXE、Ansible playbook、Ignition等）•站点/设备提取并缓存必要的工件•缓存可能已准备好/预填充•单一库存配置（类CMDB）•单层遥测（日志？） 如何让设备加入更”自治“？ 架构设计考虑: ●独立节点，在“Kubelet light”中作为静态Pod或者守护集运行工作负载。●运行系统管理Pod，用于注册带有设备注册表的节点、轮询Pod和配置映射的配置存储库、触发操作系统和系统级别组件更新等 当使用: ●按节点的方式进行设备和应用管理 开源设计模式参考 工业边缘开源参考架构：Manuela 使用GitOps规模化部署的模式 GitOps的落地模式参考 1 .满足多集群的应用发布要求；2.满足多环境以及多区域的应用发布要求；3.采用Kustomize的满足集中维护公共配置，以及兼顾维护特有配置的要求；4.修改公共配置时只需要在一个地方修改；5.版本升级修改镜像标签时只需要在一个地方修改；6.满足对单个集群粒度的应用生命周期管理；7.满足对单个集群粒度的集群特有配置修改；（通常是一次性的初始化） Example:https://github.com/xdevops-caj-acm/parksmap/tree/main/k8s-manifestsKustomize：https://github.com/kubernetes-sigs/kustomizeKustomize document:https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/Kustomize document:https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/Google Cloud | Kustomize:https://cloud.google.com/anthos-config-management/docs/concepts/kustomize 落地业务场景：MES、PLC和管理 某一线欧美车企生产工艺组云原生转型场景 生产自动化控制的成本效益（续前） ●使用通用的IT硬件替代●备件（千万级甚至过亿）成本降低●除部分功能安全要求场景外●业务逻辑可按需定制并通过CI/CD实现快速发布●实现了IT/OT在边缘工艺的交互 某龙头家电制造企业应用逻辑架构（转型过渡架构） •应用是”无状态“的对待•状态由业务逻辑保持•利用数据中心的资源进行冗余设计•单元业务“自治”•通过数据库+消息流完成业务•管理与业务操作分离•微服务设计，按领域单一镜像打包，约1 2+业务领域•车间级的数据可能丢失！ 应用发布管理（续前） ●使用GitOps支撑规模化部署（CD）●中心管理原则，厂区基层维护人员●应用配置差异使用Kustomize实现导入，如ConfigMap●运维团队人员2+1支持1 00+的工艺单元 某外资500强日化企业使用GitOps规模化自动部署IoT应用•采用了标准的Kustomize做法 •按业务线进行划分•ArgoCD CR也是GitOps的资源之一•云/边端分开管理，本地安全开关•中间件依赖Helm版本化 高可用--伪命题？ 看上去矛盾的需求：•数据可丢弃 •离线自治生产要求•业务数据高可用 工程实践的收获和感想 •IT和OT永远说两套语言•应用现代化技术或者说云的技术是IT发起的变革•成本和资源在工业自动化是永恒的话题：备件成本、维护成本•近边端的MES应用仍然是IT应用，对接设备的协转已经对IT很友好•部分老旧产线的改造需要时间和更多架构的妥协•制造业在开放、自主控制和创新的道路上越走越远 转型是一个只有开始的“旅程” THANKS！