云原生在工业场景的落地，驱动力并非技术追新。传统工业软件的部署方式——手动配置、脚本分发、逐机调试——在多工厂、多产线环境下暴露出一致性缺陷。同一套平台，部署在A工厂能跑，到B工厂就因为glibc版本差异或内核参数不同而崩溃。容器化解决的正是这个问题：将运行时依赖打包为不可变制品，在任何满足条件的节点上以相同方式启动。
Kubernetes将这一能力从单机扩展到集群级别，提供了调度、弹性伸缩和声明式配置。但对于工业互联网平台而言，K8s的通用设计需要做大量场景适配。
K8s在工业场景的适配改造
标准K8s部署假设网络畅通、镜像可拉取、存储可动态创建。工业现场几乎不满足这些前提。
离线部署是首要约束。工厂内网通常与公网物理隔离，无法从Docker Hub或公有云镜像仓库拉取镜像。私有镜像仓库（Harbor）需部署在内网，所有镜像预先同步。K8s本身安装包也需离线版本——kubeadm、etcd、CNI插件、CSI驱动全部打包为离线安装介质。Rancher的离线安装方案、Kubespray的air-gap模式是两条可行路径，前者管理面重但UI友好，后者纯Ansible驱动适合大规模批量部署。
GPU调度在AI推理场景中不可回避。工业视觉质检、振动分析等模型推理需要GPU加速。K8s通过Device Plugin机制暴露GPU资源，nvidia-device-plugin将GPU注册为Extended Resource，Pod可通过requests: nvidia.com/gpu: 1申请。但工业场景有一个特殊问题：部分推理服务需要独占GPU避免干扰，此时需启用GPU独占模式（--gpu-sharing=false），或使用MIG（Multi-Instance GPU）将单卡切分为多个实例分配给不同推理服务。
设备网络涉及两类需求。一类是采集服务需要直接访问设备IP，不经过NAT——K8s默认网络模型对Pod IP做了NAT转换，采集Pod与PLC通信可能因网络跳数增加而引入延迟。HostNetwork模式让Pod直接使用宿主机网络栈，绕过CNI，适用于低延迟采集场景。另一类是SR-IOV（Single Root I/O Virtualization）用于高性能网络，将物理网卡虚拟化为多个VF（Virtual Function）直通给Pod，实现近线速吞吐。Intel SR-IOV Network Device Plugin提供了K8s集成方案。
持久化存储与设备直通
工业数据平台的存储需求与互联网应用差异显著。互联网应用以对象存储和共享文件系统为主，工业场景则大量依赖本地存储——高频数据写入对IOPS和延迟敏感，分布式存储的额外开销不可接受。
本地盘直通（Local Persistent Volume）是首选方案。K8s 1.14 GA的Local PV将节点本地磁盘直接暴露给Pod，无网络开销，IOPS可达SSD上限。但Local PV的Pod绑定是永久的——一旦调度到某节点，迁移意味着数据搬移。对StatefulSet管理的数据节点，这要求节点故障时有明确的数据恢复策略。
K8s存储方案 | 性能特征 | 工业适用场景 | 局限性 |
Local PV | IOPS上限取决于磁盘 | 高频数据写入节点 | 节点绑定不可迁移 |
CSI（Ceph/Local-Path） | 网络开销5-15% | 管理面/元数据存储 | 延迟波动较大 |
HostPath | 直接I/O | 边缘节点单机部署 | 无隔离，不安全 |
NFS | 共享访问 | 模型文件/配置共享 | 单点风险，延迟高 |
设备直通（Device Passthrough）通过Device Plugin实现。工业现场有大量非标硬件——数据采集卡、GPIO控制器、串口服务器——这些设备无法通过标准K8s资源模型描述。Device Plugin框架允许厂商编写自定义插件，将硬件资源注册为K8s可调度资源。例如串口设备可通过devices.k8s.io/serial_port注册，Pod按需申请。
微服务拆分：按数据流而非按组织结构
工业互联网平台的微服务拆分不应照搬互联网经验。互联网公司按业务团队拆分服务边界，工业平台应按数据流拆分——因为工业数据有明确的流向：采集→存储→分析→告警→展示。
按业务域拆分将平台分为五个核心域：
- 采集域：协议适配（OPC UA/MQTT/Modbus）、数据清洗、缓冲队列
- 存储域：数据写入、查询服务、数据生命周期管理
- 分析域：实时计算（流处理）、批量计算、模型推理
- 告警域：规则引擎、告警路由、通知分发
- 可视化域：大屏渲染、报表服务、API聚合层
每个域内部再按数据流阶段拆分。采集域内，协议适配与数据清洗是独立服务——协议适配服务需要频繁更新（新设备接入），而数据清洗服务稳定运行不需频繁迭代。拆分后，协议适配服务可独立发布，不影响数据清洗服务的运行。
服务通信的选择与数据特征强相关。设备数据上报是高频低延迟场景，适合gRPC——Protocol Buffer序列化效率高于JSON，HTTP/2多路复用减少连接开销。管理类操作低频但需要事务保证，REST API更合适。告警分发是典型的事件驱动场景，消息队列（Kafka/RocketMQ）解耦生产者和消费者，避免告警风暴时拖垮下游。
服务网格的取舍
Istio在工业K8s中的引入需要审慎评估。服务网格提供了流量管理（灰度发布/熔断/重试）、安全（mTLS/授权策略）和可观测性（指标/追踪/日志）三大能力。对于工业平台，可观测性是刚需——设备数据链路长，采集到展示经过多个服务，缺乏分布式追踪很难定位延迟瓶颈。
代价是资源开销。Istio的Sidecar（Envoy）每个Pod注入一个代理进程，内存占用约50-100MB，CPU在QPS高时增加2-5ms延迟。对于高频数据采集服务（单Pod每秒处理数万条数据点），Sidecar开销不可忽视。
一个折中方案是选择性注入。只在管理面服务（API网关、用户服务、报表服务）注入Sidecar，数据面服务（采集、存储）不注入——数据面服务间通信走直连，绕过Sidecar。Linkerd作为替代方案，用Rust实现的代理更轻量，资源占用约为Envoy的1/3，但功能不如Istio丰富。
落地挑战与应对
私有镜像仓库是基础设施前置条件。Harbor提供镜像存储、漏洞扫描和签名验证。工业场景需特别关注镜像精简——基础镜像用Alpine（5MB）替代Ubuntu（70MB），减少离线安装包体积。多架构镜像（amd64/arm64）需覆盖x86服务器和ARM边缘设备。
离线安装包构建是系统工程。K8s组件镜像、CNI/CSI/Device Plugin镜像、平台业务镜像、依赖中间件镜像（Redis/MinIO/Nacos），全部打包进一个tar包，附带安装脚本和校验逻辑。安装脚本需处理节点角色差异（Master/Worker/Edge）、网络插件选择（Calico/Flannel）和存储初始化。
K8s运维能力不足是最现实的障碍。工厂IT团队通常不具备K8s运维经验，Kubernetes的故障排查门槛远高于传统虚拟机。Operator模式可以将运维知识编码——TDengine的K8s Operator封装了集群创建、节点扩缩容、数据重平衡、备份恢复等操作，运维人员通过CRD（Custom Resource Definition）以声明式方式管理，降低操作门槛。
StatefulSet是数据节点管理的核心组件。TDengine的数据节点（dnode）需要稳定网络标识和持久化存储，StatefulSet提供有序的Pod名称（dnode-0, dnode-1）和稳定的PVC绑定。集群扩容时新增Pod按序启动，保证数据副本一致性。Operator在此基础上增加业务逻辑——检测集群健康状态、自动执行副本补全、触发数据重平衡。
结语
云原生在工业数据平台的落地，核心不在于K8s本身的技术先进性，而在于对工业约束的适配深度。离线部署、GPU调度、设备直通、本地存储——每一项都要求对标准K8s做定制化改造。微服务拆分按数据流而非组织结构，服务网格选择性注入而非全局铺开，这些决策的依据是工业场景的实际约束而非互联网最佳实践。
TDengine作为AI原生工业数据平台，原生提供K8s Operator和StatefulSet部署支持，数据节点管理通过CRD声明式配置，无需额外中间件层。在工业互联网平台向云原生演进的过程中，数据层的容器化能力决定了整体架构的弹性边界。
