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

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