KubeVela 多集群工作流之 export-service：将 Service Endpoint 导出到指定集群

云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载导读export-service是 KubeVela 内置的工作流步骤WorkflowStep用于把应用在某个集群上暴露的服务端点Service Endpoint导出重新创建到由 topology 策略指定的其他集群。本文基于官方示例export-service.eg.md讲解其完整用法并结合 export-service.cue 定义源码与多集群 e2e 测试深入剖析其底层实现原理。读完本文你将能够在多集群交付场景中用collect-service-endpointsexport-service两步实现跨集群的服务访问地址共享例如将边缘集群的工作负载端点暴露到中心集群。一、适用场景与整体思路在多集群应用交付中一个常见诉求是应用部署在集群 A但希望集群 B 中的其他应用也能通过稳定的 Service 域名访问它。直接为集群 B 重新部署一份应用往往成本过高且数据不一致更优雅的做法是先把应用部署到某个集群如本地 hub 集群并通过exposetrait 生成 Service用collect-service-endpoints步骤把 Service 的 host / port 提取出来用export-service步骤在目标集群由 topology 策略决定中创建一个指向该 host 的ClusterIP ServiceEndpoints对象。这样目标集群中的应用可以通过 Kubernetes 内置的 Service 域名如busybox.namespace)解析并访问源集群的服务实现端点导出、流量跨集群。export-service在定义元数据中标注为category: Application Delivery应用交付类工作流步骤scope: Application作用于整个 Application 维度。定义源码位于 vela-templates/definitions/internal/workflowstep/export-service.cue随 Helm Chart 安装时渲染为WorkflowStepDefinition资源见 charts/vela-core/templates/defwithtemplate/export-service.yaml。二、官方示例collect 端点并 export 到 worker 集群以下 YAML 是官方文档 export-service.eg.md 给出的完整示例apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: app-collect-service-endpoint-and-export spec: components: - type: webservice name: busybox properties: image: busybox imagePullPolicy: IfNotPresent cmd: - sleep - 1000000 traits: - type: expose properties: port: [8080] type: LoadBalancer policies: - type: topology name: local properties: clusters: [local] - type: topology name: worker properties: clusters: [cluster-worker] workflow: steps: - type: deploy name: deploy properties: policies: [local] - type: collect-service-endpoints name: collect-service-endpoints outputs: - name: host valueFrom: value.endpoint.host - name: port valueFrom: value.endpoint.port - type: export-service name: export-service properties: name: busybox topology: worker inputs: - from: host parameterKey: ip - from: port parameterKey: port2.1 示例执行流程拆解步骤类型作用deploydeploy按localtopology 策略把busybox组件部署到 localhub集群collect-service-endpointscollect-service-endpoints收集应用 Service 端点把value.endpoint.host、value.endpoint.port分别写入工作流输出变量host、portexport-serviceexport-service以host作为 ip和port为参数按workertopology 策略把 Service 导出到cluster-worker集群三个步骤之间通过工作流变量传递数据outputs定义步骤对外输出inputs定义步骤从上游变量取值并映射到自身的parameterKey如ip、port。2.2 与 collect-service-endpoints 的配合要点collect-service-endpoints的输出结构中value.endpoint.host与value.endpoint.port是最常用的两个字段官方姊妹文档 collect-service-endpoints.eg.md 中同样展示了先collect-service-endpoints、再export-data把 host 写入 ConfigMap 的写法可作为对照参考。该步骤还支持按components、port、portName、outer过滤端点并按protocal默认http可选https拼装访问 URL其定义见 vela-templates/definitions/internal/workflowstep/collect-service-endpoints.cue。三、export-service 参数详解根据 export-service.cue 中的parameter声明该步骤支持 6 个参数参数类型必填默认值说明namestring否当前应用名context.name导出目标 Service/Endpoints 的名称namespacestring否当前应用命名空间context.namespace导出目标 Service/Endpoints 的命名空间ipstring是无要导出的端点 IP 地址portint是无Service 对外暴露的端口spec.ports[].porttargetPortint是无实际转发到的目标端口spec.ports[].targetPort同时用于 Endpoints 的ports[].porttopologystring否不指定指定导出目标集群的 topology 策略名注意与export-data等步骤不同export-service没有默认的targetPortip、port、targetPort三个参数都必须显式提供。在示例中targetPort未直接给出是因为该步骤的inputs只映射了ip与port——实际使用时若目标端口与服务端口不一致务必补充targetPort。3.1 参数如何被消费在 CUE 模板中parameter.name/parameter.namespace会以条件表达式覆盖meta的默认值meta: { name: *context.name | string namespace: *context.namespace | string if parameter.name ! _|_ { name: parameter.name } if parameter.namespace ! _|_ { namespace: parameter.namespace } }也就是说不传name/namespace时导出的 Service 会沿用当前应用的名字与命名空间传了则以传入值为准。四、底层实现原理导出是如何发生的export-service的 CUE 模板核心逻辑可分为三部分见 vela-templates/definitions/internal/workflowstep/export-service.cue。4.1 构造要导出的对象Service Endpoints模板会一次性构造两个 Kubernetes 对象objects: [{ apiVersion: v1 kind: Service metadata: meta spec: { type: ClusterIP ports: [{ protocol: TCP, port: parameter.port, targetPort: parameter.targetPort }] } }, { apiVersion: v1 kind: Endpoints metadata: meta subsets: [{ addresses: [{ ip: parameter.ip }] ports: [{ port: parameter.targetPort }] }] }]创建的 Service 固定为ClusterIP类型——它只在目标集群内部提供稳定 DNS 名不重新对外暴露负载均衡器同步创建同名Endpoints把parameter.ip写入subsets[].addressesparameter.targetPort写入subsets[].ports正因为同时创建了Service与Endpoints目标集群内Service的Endpoints才不被 EndpointSlice 控制器覆盖从而可以指向源集群的端点 IP。4.2 通过 topology 策略计算目标集群模板借助内置操作符op.#GetPlacementsFromTopologyPolicies解析拓扑getPlacements: op.#GetPlacementsFromTopologyPolicies { policies: *[] | [...string] if parameter.topology ! _|_ { policies: [parameter.topology] } }若指定了parameter.topology如示例中的worker则只从该 topology 策略中取出 placement若不指定则读取应用内所有topology 策略的 placement即导出到所有拓扑覆盖的集群。4.3 逐集群 Apply最后把构造好的对象逐个下发到每个 placement 对应的集群apply: { for p in getPlacements.placements { for o in objects { \(p.cluster)-\(o.kind): kube.#Apply { $params: { value: o, cluster: p.cluster } } } } }对每个目标集群都会执行一次kube.#Apply将 Service 与 Endpoints 对象下发到该集群。这也意味着导出的对象会出现在每一个被 topology 选中的集群中。五、多集群场景的验证e2e 测试佐证仓库的 e2e 测试覆盖了collect-service-endpoint export的完整链路。在 test/e2e-multicluster-test/multicluster_test.go 中从 testdata/app/app-collect-service-endpoint-and-export.yaml 读取 Application 并创建等待 Application 进入ApplicationRunning状态在 hub 集群断言busyboxService 存在并校验 host 为busybox.namespace分别在 hub 集群与 worker 集群断言 ConfigMap 中的数据host均等于该值——验证跨集群数据导出生效。测试用的 YAML 与官方示例同源将expose类型换为ClusterIP、拓扑换为all并把导出步骤换为export-data说明该collect → export组合是多集群交付中的标准能力且同时存在export-service导出 Service 对象与 export-data导出为 ConfigMap/Secret 数据两种落地形态。六、典型用法与注意事项6.1 将导出目标限定为单个集群只需在policies中定义好 topology并在export-service的properties.topology中指名即可policies: - type: topology name: worker properties: clusters: [cluster-worker] workflow: steps: - type: export-service name: export-service properties: name: busybox topology: worker6.2 使用建议与边界ip 的来源通常配合collect-service-endpoints的value.endpoint.host作为ip传入也可在工作流上游通过其他步骤如read-object获取后作为变量注入。portvstargetPortport是目标集群内 Service 对外监听的端口targetPort是转发及 Endpoints 中记录的目标端口两者不同时应同时显式配置否则工作流模板会因缺少必填参数而校验失败。拓扑策略必须存在topology参数指向的 topology 策略必须已在spec.policies中定义否则op.#GetPlacementsFromTopologyPolicies取不到 placement导出步骤不会产生任何下发动作。适用边界该步骤导出的是ClusterIP Service Endpoints适合集群间内网互通的场景若目标集群无法路由到源集群的 Pod/节点 IP则需配合网络插件或 LoadBalancer 类型的端点使用。七、小结export-service是 KubeVela 多集群交付工作流中端点导出环节的内置步骤它以 topology 策略为边界、以ip/port/targetPort为载荷在目标集群内生成指向源集群端点的ClusterIP Service与Endpoints。配合collect-service-endpoints的自动收集能力开发者可以用纯声明式工作流完成跨集群服务访问地址的打通无需手写多集群编排脚本。其定义源码export-service.cue与 e2e 用例multicluster_test.go是进一步深入学习和二次开发的最佳起点。赞分享云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载相关推荐KubeVela 多集群实战使用 Trait 的 controlPlaneOnly 属性将资源固定派发到 Hub 集群KubeVela 多集群实战使用 Trait 的 controlPlaneOnly 属性将资源固定派发到 Hub 集群 在 KubeVela 多集群应用编排中云原生DevOps运维微服务Flower 多集群部署实践用 Red Hat Service InterconnectSkupper将 SuperLink 与 SuperNode 跨 OpenShift 集群互联Flower 多集群部署实践用 Red Hat Service InterconnectSkupper将 SuperLink 与 SuperNode 跨嵌入式物联网机器人自动驾驶智能硬件Karmada karmadactl create service loadbalancer 命令详解多集群环境下的 LoadBalancer Service 创建Karmada karmadactl create service loadbalancer 命令详解多集群环境下的 LoadBalancer Service云原生多集群集群管理微服务上一篇Slang 编译器 IR Pass 管线全解析linkAndOptimizeIR 调度、Pass 分类清单与新增 Pass 实战指南下一篇使用 tsParticles 官方 React 模板搭建粒子效果应用cra-template-particles 从创建到定制创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考