OpenMetadata Helm Chart 本地测试实践K8s 原生流水线执行与 Airflow 配置迁移验证【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata本文围绕仓库中docker/development/helm目录下的 Helm 本地测试指南展开先完整讲解如何用 Docker Compose 拉起 PostgreSQL 与 OpenSearch 依赖、用 Minikube 搭建单节点集群再通过values-k8s-test.yaml与values-airflow-test.yaml两套 values 文件分别验证 OpenMetadata 的 Kubernetes 原生流水线客户端K8s native pipeline client与迁移后的嵌套 Airflow 配置并结合服务端源码说明K8sPipelineClientConfig的默认值与参数解析逻辑、PipelineServiceClientFactory的客户端装配机制以及 OMJob Operator 的两阶段执行模型帮助你在本地复现并系统性地验证 Helm Chart 的流水线相关变更。1. 测试环境与目录结构Helm 本地测试的核心思路是OpenMetadata 的 Chart 托管在独立的openmetadata-helm-charts仓库中而本仓库提供一套本地依赖 集群 values 文件的完整测试床让你在 Chart 开发时可以直接用本地构建的镜像如openmetadata/server快速验证渲染结果与运行时行为而不必等待镜像发布。该测试床位于 docker/development/helm/包含以下关键文件文件作用docker/development/helm/README.md本地测试指南主体本文依据docker/development/helm/docker-compose-deps.yml本地依赖PostgreSQL OpenSearchdocker/development/helm/values-k8s-test.yamlK8s 原生流水线客户端的测试 valuesdocker/development/helm/values-airflow-test.yaml迁移后 Airflow 配置的测试 values2. 前置条件2.1 必需工具# Install required tools brew install helm kubectl minikube docker-compose # Or on Ubuntu/Debian: # sudo snap install helm kubectl minikube # sudo apt-get install docker-compose2.2 硬件资源要求CPU建议 4 核以上内存建议 8GB 以上存储20GB 以上空闲空间Minikube 需要在这台主机上分配 4 核 / 8192MB加上宿主机上跑 PostgreSQL、OpenSearch 与 Docker Desktop 的开销8GB 内存是保证部署不 OOM 的底线。3. 搭建本地依赖PostgreSQL 与 OpenSearch3.1 启动依赖服务cd docker/development/helm # Start PostgreSQL and OpenSearch docker-compose -f docker-compose-deps.yml up -d # Wait for services to be ready (2-3 minutes) docker-compose -f docker-compose-deps.yml logs -f # Verify services are running curl http://localhost:9200/_cluster/health docker exec openmetadata_postgres_test psql -U openmetadata_user -d openmetadata_db -c SELECT 13.2 依赖编排文件解析docker-compose-deps.yml 的定义值得逐条对照因为它决定了 Chart 中数据库与搜索配置应指向的地址与端口PostgreSQL使用仓库自带的镜像构建上下文docker/postgresql/Dockerfile_postgres容器名openmetadata_postgres_test库名openmetadata_db、用户openmetadata_user、密码openmetadata_password这三个值必须与第 4 节创建的 Kubernetes Secret 一致。宿主机端口映射为5433:5432注释明确说明使用不同端口以避免冲突同时通过command预调优了max_connections200、shared_buffers256MB等参数健康检查使用pg_isready。OpenSearch镜像opensearchproject/opensearch:3.4.0单节点模式discovery.typesingle-node关闭安全插件DISABLE_SECURITY_PLUGINtrueJVM 堆限定为 1024MB宿主机映射 9200/9300 端口健康检查请求/_cluster/health。两者共享openmetadata_networkbridge 网络数据分别落在./docker-volume/db-data-postgres卷与opensearch_data命名卷。一个容易踩坑的细节由于 PostgreSQL 宿主机映射端口是 5433Pod 内通过host.docker.internal访问时应指向 5433 才能命中该映射——values-airflow-test.yaml 中database.port: 5433正是对应这一映射而 values-k8s-test.yaml 写的是 5432两者取值差异即源于此。若本地 5433 被占用或宿主机另有 PG 实例需要自行确认端口指向。4. 启动 Minikube 并创建 Secret4.1 启动 Kubernetes 集群# Start minikube with sufficient resources minikube start --cpus 4 --memory 8192 --driver docker # Enable ingress addon (optional) minikube addons enable ingress # Verify cluster is ready kubectl cluster-info kubectl get nodes注意--driver docker它让 Minikube 复用宿主机 Docker 守护进程因此 Pod 才能通过host.docker.internal访问宿主机上的 PostgreSQL 与 OpenSearch这也是两套 values 文件中数据库与搜索地址统一写成host.docker.internal的原因。4.2 创建 Chart 期望的 Secrets# Create secrets that the chart expects kubectl create secret generic postgres-secrets \ --from-literalopenmetadata-postgres-passwordopenmetadata_password kubectl create secret generic airflow-secrets \ --from-literalopenmetadata-airflow-passwordadmin这两个 Secret 的名字与 key 必须与 values 文件中的secretRef/secretKey完全对应# values-k8s-test.yaml 中的引用方式 database: auth: password: secretRef: postgres-secrets # Secret 名称 secretKey: openmetadata-postgres-passwordAirflow 密码admin对应的是 Airflow 场景下airflow.auth.password的引用见 values-airflow-test.yaml。5. 场景 A测试 Kubernetes 原生流水线客户端K8s 原生路径的目标是完全绕开 Airflow由 OpenMetadata 服务端直接向 Kubernetes API 创建 Job/CronJob或 OMJob/CronOMJob 自定义资源来执行采集流水线。5.1 安装命令# Use local chart directly, e.g., CHART_PATH/Users/pmbrull/github/openmetadata-helm-charts/charts/openmetadata # Install with K8s native configuration helm install openmetadata-k8s-test $CHART_PATH --values values-k8s-test.yaml # Check deployment status kubectl get pods -A kubectl get jobs -n openmetadata-pipelines-test kubectl get serviceaccounts,roles,rolebindings -n openmetadata-pipelines-test # Check logs kubectl logs -l app.kubernetes.io/nameopenmetadata -f # Test access minikube tunnel # In separate terminal curl http://localhost:8585/api/v1/system/health其中CHART_PATH指向你本地克隆的 helm-charts 仓库路径按各自环境替换即可。minikube tunnel用于把 LoadBalancer Service 端口8585暴露到localhost。5.2 values-k8s-test.yaml 关键参数解析values-k8s-test.yaml 的核心是嵌套结构的pipelineServiceClientConfigpipelineServiceClientConfig: type: k8s # Use Kubernetes native instead of Airflow # Common configuration for all pipeline service clients metadataApiEndpoint: http://openmetadata.openmetadata-ingestion.svc.cluster.local:8585/api k8s: namespace: # 空串表示默认使用 release namespace serviceAccountName: openmetadata-ingestion ttlSecondsAfterFinished: 10 # 测试环境缩短 Job 保留时间 ingestionImage: openmetadata/collate-base:1.12.0-20260402 # 本地构建的采集镜像 imagePullPolicy: IfNotPresent resources: limits: { cpu: 1, memory: 2Gi } requests: { cpu: 100m, memory: 512Mi } tolerations: - key: dedicated operator: Equal value: ingestion effect: NoSchedule useOMJobOperator: true # 启用 OMJob operator 保证 exit handler 执行结合服务端源码 K8sPipelineClientConfig.java上述取值都有对应的默认值与校验规则测试 values 的每一项都在覆盖或收窄它们配置项测试 values 取值源码默认值说明namespaceopenmetadata-pipelines空串由 Chart 侧替换为 release namespaceserviceAccountNameopenmetadata-ingestionopenmetadata-ingestion执行流水线 Job 的 SAttlSecondsAfterFinished106048001 周测试时缩短以快速清理 JobingestionImage本地镜像docker.getcollate.io/openmetadata/ingestion:latest本地构建镜像resources100m/512Mi → 1/2Gi500m/1Gi → 2/4Gi测试环境收窄资源activeDeadlineSeconds未设置7200Job 超时上限backoffLimit未设置3失败重试次数startingDeadlineSeconds未设置60防止 CronJob 追赶错过窗口源码中还有一个值得注意的初始化行为validateConfiguration()会校验 namespace 必须是小写字母数字加连字符、资源量必须是合法的 Kubernetes Quantity非法配置会抛出PipelineServiceClientException使客户端初始化直接失败——也就是说 Helm 渲染出的配置一旦不合法会在服务端启动阶段而不是运行阶段暴露问题这正好与第 8 节的Configuration Validation验证步骤呼应。同一文件还配置了 OMJob Operator 的启用与资源omjobOperator: enabled: true image: repository: docker.getcollate.io/openmetadata/omjob-operator tag: 1.12.0-SNAPSHOT resources: requests: { cpu: 500m, memory: 512Mi } limits: { cpu: 1, memory: 1Gi } env: logLevel: DEBUG watchNamespaces: # 空 监听所有命名空间 healthCheck: enabled: true注释中记录了调参经验operator 曾在 128Mi 下被 OOMKilledJava 应用需要至少 512Mi 请求 / 1Gi 上限。此外service.type: LoadBalancer、放宽的探针livenessProbe/readinessProbe.initialDelaySeconds: 120、startupProbe.failureThreshold: 10都是为了适配 Minikube 单节点慢启动的本地测试场景。6. 场景 B测试迁移后的 Airflow 配置# Install with migrated Airflow configuration helm install openmetadata-airflow-test $CHART_PATH \ --values values-airflow-test.yaml \ --timeout 10m \ --wait # Check deployment kubectl get pods -A kubectl logs -l app.kubernetes.io/nameopenmetadata -f迁移的核心是配置结构从扁平的className apiEndpoint变为按type分发的嵌套结构。对比 values-airflow-test.yamlpipelineServiceClientConfig: type: airflow # 使用传统 Airflow 方式 # 所有流水线客户端共享的公共配置 metadataApiEndpoint: http://openmetadata:8585/api airflow: apiEndpoint: http://openmetadata-dependencies-api-server:8080 verifySsl: no-ssl auth: username: admin password: secretRef: airflow-secrets secretKey: openmetadata-airflow-password与 K8s 路径的差异点公共层只有metadataApiEndpoint指向集群内 ServiceAirflow 特有参数收进airflow:子块密码同样走 Secret 引用。两套 values 文件结构对称正是迁移后 Chart 需要保证两种 type 均可渲染、均可运行的验证目标。在服务端客户端的实例化由 PipelineServiceClientFactory.java 完成它基于PipelineServiceClientConfiguration中的类名通过反射加载具体实现如AirflowRESTClient或 K8s 客户端用双重检查锁缓存实例并在请求类型与缓存类型不一致时重建客户端配置被显式enabled: false时返回 null 跳过初始化。配置入口则是 OpenMetadataApplicationConfig.getPipelineServiceClientConfiguration()它还负责把sslConfig中的旧键certificatePath兼容转换为caCertificate——这类兼容逻辑正是迁移配置测试场景需要覆盖的回归面。7. 验证清单7.1 基础功能# Check all pods are running kubectl get pods -A # Check OpenMetadata pod logs kubectl logs deployment/openmetadata-k8s-test -f # Check database connectivity kubectl exec deployment/openmetadata-k8s-test -- curl -f http://postgres:5432 || echo DB connection testAPI 健康检查# Access health endpoint curl http://localhost:8585/api/v1/system/health # Check API response curl http://localhost:8585/api/v1/system/config7.2 K8s 原生流水线特性RBAC 资源验证流水线命名空间、ServiceAccount 与权限是否按 Chart 渲染# Check namespace creation kubectl get namespace openmetadata-pipelines-test # Check service account kubectl get serviceaccount -n openmetadata-pipelines-test openmetadata-ingestion-test # Check permissions kubectl auth can-i create jobs \ --assystem:serviceaccount:openmetadata-pipelines-test:openmetadata-ingestion-test \ -n openmetadata-pipelines-testkubectl auth can-i直接模拟流水线 SA 询问能否在该命名空间创建 jobs是验证 Role/RoleBinding 是否齐全的最小化手段。配置加载# Check environment variables in pod kubectl exec deployment/openmetadata-k8s-test -- env | grep K8S_ # Check secrets kubectl get secret openmetadata-k8s-test-pipeline-secret -o yaml kubectl get secret openmetadata-k8s-test-pipeline-secret -o jsonpath{.data} | base64 -d手动流水线 Job 测试直接向流水线命名空间投递一个 Job验证 SA 可用且镜像可拉取cat EOF | kubectl apply -f - apiVersion: batch/v1 kind: Job metadata: name: test-ingestion-job namespace: openmetadata-pipelines-test spec: template: spec: serviceAccountName: openmetadata-ingestion-test containers: - name: test image: docker.getcollate.io/openmetadata/ingestion:latest command: [echo, Test pipeline job works] restartPolicy: Never EOF kubectl get jobs -n openmetadata-pipelines-test kubectl logs job/test-ingestion-job -n openmetadata-pipelines-test失败诊断Failure Diagnostics创建一个必然失败的 Job观察服务端能否按app.kubernetes.io/pipeline/app.kubernetes.io/run-id标签追踪到失败并派生诊断 Jobcat EOF | kubectl apply -f - apiVersion: batch/v1 kind: Job metadata: name: test-failing-job namespace: openmetadata-pipelines-test labels: app.kubernetes.io/pipeline: test-pipeline app.kubernetes.io/run-id: test-123 spec: template: spec: serviceAccountName: openmetadata-ingestion-test containers: - name: main image: docker.getcollate.io/openmetadata/ingestion:latest command: [sh, -c, echo Starting ingestion...; sleep 10; echo Something went wrong!; exit 1] restartPolicy: Never EOF # Watch for diagnostic job creation kubectl get jobs -n openmetadata-pipelines-test -w # Check diagnostic job logs kubectl logs -n openmetadata-pipelines-test -l app.kubernetes.io/componentdiagnostics这套标签体系与服务端 K8sPipelineClient 对流水线资源统一打标app.kubernetes.io/pipeline、app.kubernetes.io/run-id等的做法一致诊断 Job 通过componentdiagnostics标签区分。7.3 配置迁移与破坏性变更测试# Test that both airflow and k8s configs are valid helm template test-airflow $CHART_PATH --values values-airflow-test.yaml /tmp/airflow-manifest.yaml helm template test-k8s $CHART_PATH --values values-k8s-test.yaml /tmp/k8s-manifest.yaml # Validate manifests kubectl apply --dry-runclient -f /tmp/airflow-manifest.yaml kubectl apply --dry-runclient -f /tmp/k8s-manifest.yaml再针对旧的扁平配置格式做回归测试预期应触发校验失败或告警cat /tmp/old-values.yaml EOF openmetadata: config: pipelineServiceClientConfig: enabled: true className: org.openmetadata.service.clients.pipeline.airflow.AirflowRESTClient apiEndpoint: http://test EOF helm template test-old $CHART_PATH --values /tmp/old-values.yaml8. K8sPipelineClient 与 OMJob Operator 的执行模型源码包 openmetadata-service/src/main/java/org/openmetadata/service/clients/pipeline/k8s/ 下的设计文档 README.md 描述了 values 中useOMJobOperator开关背后真实的执行链路理解它有助于解读上面各验证步骤观察到的资源部署流水线deployPipeline构建 workflow 配置WorkflowConfigBuilder若服务端连接缺失会用 ingestion-bot JWT 从服务端配置兜底创建→ 写入 ConfigMapom-config-pipelineNamekey 为config内容是 workflow YAML→ 写入 Secretom-secret-pipelineNamekey 为securityConfig→ 有调度的流水线按useOMJobOperator创建CronOMJob或原生CronJob无调度的则清理既有调度资源任一步失败会回滚已创建的 ConfigMap/Secret/CronJob。按需执行runPipeline生成 run IDuseOMJobOperatortrue时创建OMJob自定义资源main pod 跑python main.py之后 operator 再拉起 exit handler pod 跑python exit_handler.pyfalse时直接创建原生Job单容器运行。这解释了为何 values 中启用 operator 能保证 exit handler 执行——状态上报依赖的退出钩子由 operator 的两阶段状态机PENDING → RUNNING → EXIT_HANDLER_RUNNING → SUCCEEDED/FAILED驱动而不是依赖 Pod 自身的 postStart 钩子。标签与选择器所有流水线资源统一带app.kubernetes.io/nameopenmetadata、componentingestion、managed-byopenmetadata、pipelinename、run-idid等标签服务端按pipeline标签取最近 Pod 拉日志、通过更新spec.suspend启停调度——第 7 节所有kubectl get/logs -l命令都建立在这一标签契约上。9. 调试与清理9.1 常用调试命令# Get all resources kubectl get all -A # Describe OpenMetadata deployment kubectl describe deployment openmetadata-k8s-test # Get events kubectl get events --sort-by.lastTimestamp -A # Check helm release helm list helm status openmetadata-k8s-test helm get values openmetadata-k8s-testhelm get values能回看渲染时实际生效的 values对排查我改的 key 没生效这类问题最有用get events按时间排序后看末尾通常能直接定位拉镜像失败、探针超时等部署期问题。9.2 清理测试部署# Remove helm releases helm uninstall openmetadata-k8s-test helm uninstall openmetadata-airflow-test # Clean up namespaces kubectl delete namespace openmetadata-pipelines-test # Clean up secrets kubectl delete secret postgres-secrets airflow-secretsMinikube 与依赖容器如需彻底释放资源可另行执行minikube stop和docker-compose -f docker-compose-deps.yml down。10. 预期结果与性能基准部署成功的判定指标所有 Pod Runningkubectl get pods -A全部处于Running状态健康检查通过curl http://localhost:8585/api/v1/system/health返回 200RBAC 就绪openmetadata-pipelines-test命名空间内命名空间、ServiceAccount、Role/RoleBinding 均已创建配置加载Pod 内环境变量按 values 正确注入日志无错kubectl logs deployment/openmetadata-k8s-test显示正常启动。指南给出的参考性能基准单节点 Minikube、4 核 8GB 条件下完整部署启动时间 5 分钟含依赖在内的总内存占用 4GB正常负载下 CPU 2 核流水线 Job 创建到执行 30 秒。这套测试床的完整闭环是依赖服务容器化、集群本地化、values 覆盖K8s 原生 Airflow 迁移两条配置分支、验证覆盖 RBAC/配置/Job/失败诊断四个维度最终同时保证新增的 K8s 原生流水线能力可用、以及存量 Airflow 配置不回归。【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenMetadata Helm Chart 本地测试实践：K8s 原生流水线执行与 Airflow 配置迁移验证
OpenMetadata Helm Chart 本地测试实践K8s 原生流水线执行与 Airflow 配置迁移验证【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata本文围绕仓库中docker/development/helm目录下的 Helm 本地测试指南展开先完整讲解如何用 Docker Compose 拉起 PostgreSQL 与 OpenSearch 依赖、用 Minikube 搭建单节点集群再通过values-k8s-test.yaml与values-airflow-test.yaml两套 values 文件分别验证 OpenMetadata 的 Kubernetes 原生流水线客户端K8s native pipeline client与迁移后的嵌套 Airflow 配置并结合服务端源码说明K8sPipelineClientConfig的默认值与参数解析逻辑、PipelineServiceClientFactory的客户端装配机制以及 OMJob Operator 的两阶段执行模型帮助你在本地复现并系统性地验证 Helm Chart 的流水线相关变更。1. 测试环境与目录结构Helm 本地测试的核心思路是OpenMetadata 的 Chart 托管在独立的openmetadata-helm-charts仓库中而本仓库提供一套本地依赖 集群 values 文件的完整测试床让你在 Chart 开发时可以直接用本地构建的镜像如openmetadata/server快速验证渲染结果与运行时行为而不必等待镜像发布。该测试床位于 docker/development/helm/包含以下关键文件文件作用docker/development/helm/README.md本地测试指南主体本文依据docker/development/helm/docker-compose-deps.yml本地依赖PostgreSQL OpenSearchdocker/development/helm/values-k8s-test.yamlK8s 原生流水线客户端的测试 valuesdocker/development/helm/values-airflow-test.yaml迁移后 Airflow 配置的测试 values2. 前置条件2.1 必需工具# Install required tools brew install helm kubectl minikube docker-compose # Or on Ubuntu/Debian: # sudo snap install helm kubectl minikube # sudo apt-get install docker-compose2.2 硬件资源要求CPU建议 4 核以上内存建议 8GB 以上存储20GB 以上空闲空间Minikube 需要在这台主机上分配 4 核 / 8192MB加上宿主机上跑 PostgreSQL、OpenSearch 与 Docker Desktop 的开销8GB 内存是保证部署不 OOM 的底线。3. 搭建本地依赖PostgreSQL 与 OpenSearch3.1 启动依赖服务cd docker/development/helm # Start PostgreSQL and OpenSearch docker-compose -f docker-compose-deps.yml up -d # Wait for services to be ready (2-3 minutes) docker-compose -f docker-compose-deps.yml logs -f # Verify services are running curl http://localhost:9200/_cluster/health docker exec openmetadata_postgres_test psql -U openmetadata_user -d openmetadata_db -c SELECT 13.2 依赖编排文件解析docker-compose-deps.yml 的定义值得逐条对照因为它决定了 Chart 中数据库与搜索配置应指向的地址与端口PostgreSQL使用仓库自带的镜像构建上下文docker/postgresql/Dockerfile_postgres容器名openmetadata_postgres_test库名openmetadata_db、用户openmetadata_user、密码openmetadata_password这三个值必须与第 4 节创建的 Kubernetes Secret 一致。宿主机端口映射为5433:5432注释明确说明使用不同端口以避免冲突同时通过command预调优了max_connections200、shared_buffers256MB等参数健康检查使用pg_isready。OpenSearch镜像opensearchproject/opensearch:3.4.0单节点模式discovery.typesingle-node关闭安全插件DISABLE_SECURITY_PLUGINtrueJVM 堆限定为 1024MB宿主机映射 9200/9300 端口健康检查请求/_cluster/health。两者共享openmetadata_networkbridge 网络数据分别落在./docker-volume/db-data-postgres卷与opensearch_data命名卷。一个容易踩坑的细节由于 PostgreSQL 宿主机映射端口是 5433Pod 内通过host.docker.internal访问时应指向 5433 才能命中该映射——values-airflow-test.yaml 中database.port: 5433正是对应这一映射而 values-k8s-test.yaml 写的是 5432两者取值差异即源于此。若本地 5433 被占用或宿主机另有 PG 实例需要自行确认端口指向。4. 启动 Minikube 并创建 Secret4.1 启动 Kubernetes 集群# Start minikube with sufficient resources minikube start --cpus 4 --memory 8192 --driver docker # Enable ingress addon (optional) minikube addons enable ingress # Verify cluster is ready kubectl cluster-info kubectl get nodes注意--driver docker它让 Minikube 复用宿主机 Docker 守护进程因此 Pod 才能通过host.docker.internal访问宿主机上的 PostgreSQL 与 OpenSearch这也是两套 values 文件中数据库与搜索地址统一写成host.docker.internal的原因。4.2 创建 Chart 期望的 Secrets# Create secrets that the chart expects kubectl create secret generic postgres-secrets \ --from-literalopenmetadata-postgres-passwordopenmetadata_password kubectl create secret generic airflow-secrets \ --from-literalopenmetadata-airflow-passwordadmin这两个 Secret 的名字与 key 必须与 values 文件中的secretRef/secretKey完全对应# values-k8s-test.yaml 中的引用方式 database: auth: password: secretRef: postgres-secrets # Secret 名称 secretKey: openmetadata-postgres-passwordAirflow 密码admin对应的是 Airflow 场景下airflow.auth.password的引用见 values-airflow-test.yaml。5. 场景 A测试 Kubernetes 原生流水线客户端K8s 原生路径的目标是完全绕开 Airflow由 OpenMetadata 服务端直接向 Kubernetes API 创建 Job/CronJob或 OMJob/CronOMJob 自定义资源来执行采集流水线。5.1 安装命令# Use local chart directly, e.g., CHART_PATH/Users/pmbrull/github/openmetadata-helm-charts/charts/openmetadata # Install with K8s native configuration helm install openmetadata-k8s-test $CHART_PATH --values values-k8s-test.yaml # Check deployment status kubectl get pods -A kubectl get jobs -n openmetadata-pipelines-test kubectl get serviceaccounts,roles,rolebindings -n openmetadata-pipelines-test # Check logs kubectl logs -l app.kubernetes.io/nameopenmetadata -f # Test access minikube tunnel # In separate terminal curl http://localhost:8585/api/v1/system/health其中CHART_PATH指向你本地克隆的 helm-charts 仓库路径按各自环境替换即可。minikube tunnel用于把 LoadBalancer Service 端口8585暴露到localhost。5.2 values-k8s-test.yaml 关键参数解析values-k8s-test.yaml 的核心是嵌套结构的pipelineServiceClientConfigpipelineServiceClientConfig: type: k8s # Use Kubernetes native instead of Airflow # Common configuration for all pipeline service clients metadataApiEndpoint: http://openmetadata.openmetadata-ingestion.svc.cluster.local:8585/api k8s: namespace: # 空串表示默认使用 release namespace serviceAccountName: openmetadata-ingestion ttlSecondsAfterFinished: 10 # 测试环境缩短 Job 保留时间 ingestionImage: openmetadata/collate-base:1.12.0-20260402 # 本地构建的采集镜像 imagePullPolicy: IfNotPresent resources: limits: { cpu: 1, memory: 2Gi } requests: { cpu: 100m, memory: 512Mi } tolerations: - key: dedicated operator: Equal value: ingestion effect: NoSchedule useOMJobOperator: true # 启用 OMJob operator 保证 exit handler 执行结合服务端源码 K8sPipelineClientConfig.java上述取值都有对应的默认值与校验规则测试 values 的每一项都在覆盖或收窄它们配置项测试 values 取值源码默认值说明namespaceopenmetadata-pipelines空串由 Chart 侧替换为 release namespaceserviceAccountNameopenmetadata-ingestionopenmetadata-ingestion执行流水线 Job 的 SAttlSecondsAfterFinished106048001 周测试时缩短以快速清理 JobingestionImage本地镜像docker.getcollate.io/openmetadata/ingestion:latest本地构建镜像resources100m/512Mi → 1/2Gi500m/1Gi → 2/4Gi测试环境收窄资源activeDeadlineSeconds未设置7200Job 超时上限backoffLimit未设置3失败重试次数startingDeadlineSeconds未设置60防止 CronJob 追赶错过窗口源码中还有一个值得注意的初始化行为validateConfiguration()会校验 namespace 必须是小写字母数字加连字符、资源量必须是合法的 Kubernetes Quantity非法配置会抛出PipelineServiceClientException使客户端初始化直接失败——也就是说 Helm 渲染出的配置一旦不合法会在服务端启动阶段而不是运行阶段暴露问题这正好与第 8 节的Configuration Validation验证步骤呼应。同一文件还配置了 OMJob Operator 的启用与资源omjobOperator: enabled: true image: repository: docker.getcollate.io/openmetadata/omjob-operator tag: 1.12.0-SNAPSHOT resources: requests: { cpu: 500m, memory: 512Mi } limits: { cpu: 1, memory: 1Gi } env: logLevel: DEBUG watchNamespaces: # 空 监听所有命名空间 healthCheck: enabled: true注释中记录了调参经验operator 曾在 128Mi 下被 OOMKilledJava 应用需要至少 512Mi 请求 / 1Gi 上限。此外service.type: LoadBalancer、放宽的探针livenessProbe/readinessProbe.initialDelaySeconds: 120、startupProbe.failureThreshold: 10都是为了适配 Minikube 单节点慢启动的本地测试场景。6. 场景 B测试迁移后的 Airflow 配置# Install with migrated Airflow configuration helm install openmetadata-airflow-test $CHART_PATH \ --values values-airflow-test.yaml \ --timeout 10m \ --wait # Check deployment kubectl get pods -A kubectl logs -l app.kubernetes.io/nameopenmetadata -f迁移的核心是配置结构从扁平的className apiEndpoint变为按type分发的嵌套结构。对比 values-airflow-test.yamlpipelineServiceClientConfig: type: airflow # 使用传统 Airflow 方式 # 所有流水线客户端共享的公共配置 metadataApiEndpoint: http://openmetadata:8585/api airflow: apiEndpoint: http://openmetadata-dependencies-api-server:8080 verifySsl: no-ssl auth: username: admin password: secretRef: airflow-secrets secretKey: openmetadata-airflow-password与 K8s 路径的差异点公共层只有metadataApiEndpoint指向集群内 ServiceAirflow 特有参数收进airflow:子块密码同样走 Secret 引用。两套 values 文件结构对称正是迁移后 Chart 需要保证两种 type 均可渲染、均可运行的验证目标。在服务端客户端的实例化由 PipelineServiceClientFactory.java 完成它基于PipelineServiceClientConfiguration中的类名通过反射加载具体实现如AirflowRESTClient或 K8s 客户端用双重检查锁缓存实例并在请求类型与缓存类型不一致时重建客户端配置被显式enabled: false时返回 null 跳过初始化。配置入口则是 OpenMetadataApplicationConfig.getPipelineServiceClientConfiguration()它还负责把sslConfig中的旧键certificatePath兼容转换为caCertificate——这类兼容逻辑正是迁移配置测试场景需要覆盖的回归面。7. 验证清单7.1 基础功能# Check all pods are running kubectl get pods -A # Check OpenMetadata pod logs kubectl logs deployment/openmetadata-k8s-test -f # Check database connectivity kubectl exec deployment/openmetadata-k8s-test -- curl -f http://postgres:5432 || echo DB connection testAPI 健康检查# Access health endpoint curl http://localhost:8585/api/v1/system/health # Check API response curl http://localhost:8585/api/v1/system/config7.2 K8s 原生流水线特性RBAC 资源验证流水线命名空间、ServiceAccount 与权限是否按 Chart 渲染# Check namespace creation kubectl get namespace openmetadata-pipelines-test # Check service account kubectl get serviceaccount -n openmetadata-pipelines-test openmetadata-ingestion-test # Check permissions kubectl auth can-i create jobs \ --assystem:serviceaccount:openmetadata-pipelines-test:openmetadata-ingestion-test \ -n openmetadata-pipelines-testkubectl auth can-i直接模拟流水线 SA 询问能否在该命名空间创建 jobs是验证 Role/RoleBinding 是否齐全的最小化手段。配置加载# Check environment variables in pod kubectl exec deployment/openmetadata-k8s-test -- env | grep K8S_ # Check secrets kubectl get secret openmetadata-k8s-test-pipeline-secret -o yaml kubectl get secret openmetadata-k8s-test-pipeline-secret -o jsonpath{.data} | base64 -d手动流水线 Job 测试直接向流水线命名空间投递一个 Job验证 SA 可用且镜像可拉取cat EOF | kubectl apply -f - apiVersion: batch/v1 kind: Job metadata: name: test-ingestion-job namespace: openmetadata-pipelines-test spec: template: spec: serviceAccountName: openmetadata-ingestion-test containers: - name: test image: docker.getcollate.io/openmetadata/ingestion:latest command: [echo, Test pipeline job works] restartPolicy: Never EOF kubectl get jobs -n openmetadata-pipelines-test kubectl logs job/test-ingestion-job -n openmetadata-pipelines-test失败诊断Failure Diagnostics创建一个必然失败的 Job观察服务端能否按app.kubernetes.io/pipeline/app.kubernetes.io/run-id标签追踪到失败并派生诊断 Jobcat EOF | kubectl apply -f - apiVersion: batch/v1 kind: Job metadata: name: test-failing-job namespace: openmetadata-pipelines-test labels: app.kubernetes.io/pipeline: test-pipeline app.kubernetes.io/run-id: test-123 spec: template: spec: serviceAccountName: openmetadata-ingestion-test containers: - name: main image: docker.getcollate.io/openmetadata/ingestion:latest command: [sh, -c, echo Starting ingestion...; sleep 10; echo Something went wrong!; exit 1] restartPolicy: Never EOF # Watch for diagnostic job creation kubectl get jobs -n openmetadata-pipelines-test -w # Check diagnostic job logs kubectl logs -n openmetadata-pipelines-test -l app.kubernetes.io/componentdiagnostics这套标签体系与服务端 K8sPipelineClient 对流水线资源统一打标app.kubernetes.io/pipeline、app.kubernetes.io/run-id等的做法一致诊断 Job 通过componentdiagnostics标签区分。7.3 配置迁移与破坏性变更测试# Test that both airflow and k8s configs are valid helm template test-airflow $CHART_PATH --values values-airflow-test.yaml /tmp/airflow-manifest.yaml helm template test-k8s $CHART_PATH --values values-k8s-test.yaml /tmp/k8s-manifest.yaml # Validate manifests kubectl apply --dry-runclient -f /tmp/airflow-manifest.yaml kubectl apply --dry-runclient -f /tmp/k8s-manifest.yaml再针对旧的扁平配置格式做回归测试预期应触发校验失败或告警cat /tmp/old-values.yaml EOF openmetadata: config: pipelineServiceClientConfig: enabled: true className: org.openmetadata.service.clients.pipeline.airflow.AirflowRESTClient apiEndpoint: http://test EOF helm template test-old $CHART_PATH --values /tmp/old-values.yaml8. K8sPipelineClient 与 OMJob Operator 的执行模型源码包 openmetadata-service/src/main/java/org/openmetadata/service/clients/pipeline/k8s/ 下的设计文档 README.md 描述了 values 中useOMJobOperator开关背后真实的执行链路理解它有助于解读上面各验证步骤观察到的资源部署流水线deployPipeline构建 workflow 配置WorkflowConfigBuilder若服务端连接缺失会用 ingestion-bot JWT 从服务端配置兜底创建→ 写入 ConfigMapom-config-pipelineNamekey 为config内容是 workflow YAML→ 写入 Secretom-secret-pipelineNamekey 为securityConfig→ 有调度的流水线按useOMJobOperator创建CronOMJob或原生CronJob无调度的则清理既有调度资源任一步失败会回滚已创建的 ConfigMap/Secret/CronJob。按需执行runPipeline生成 run IDuseOMJobOperatortrue时创建OMJob自定义资源main pod 跑python main.py之后 operator 再拉起 exit handler pod 跑python exit_handler.pyfalse时直接创建原生Job单容器运行。这解释了为何 values 中启用 operator 能保证 exit handler 执行——状态上报依赖的退出钩子由 operator 的两阶段状态机PENDING → RUNNING → EXIT_HANDLER_RUNNING → SUCCEEDED/FAILED驱动而不是依赖 Pod 自身的 postStart 钩子。标签与选择器所有流水线资源统一带app.kubernetes.io/nameopenmetadata、componentingestion、managed-byopenmetadata、pipelinename、run-idid等标签服务端按pipeline标签取最近 Pod 拉日志、通过更新spec.suspend启停调度——第 7 节所有kubectl get/logs -l命令都建立在这一标签契约上。9. 调试与清理9.1 常用调试命令# Get all resources kubectl get all -A # Describe OpenMetadata deployment kubectl describe deployment openmetadata-k8s-test # Get events kubectl get events --sort-by.lastTimestamp -A # Check helm release helm list helm status openmetadata-k8s-test helm get values openmetadata-k8s-testhelm get values能回看渲染时实际生效的 values对排查我改的 key 没生效这类问题最有用get events按时间排序后看末尾通常能直接定位拉镜像失败、探针超时等部署期问题。9.2 清理测试部署# Remove helm releases helm uninstall openmetadata-k8s-test helm uninstall openmetadata-airflow-test # Clean up namespaces kubectl delete namespace openmetadata-pipelines-test # Clean up secrets kubectl delete secret postgres-secrets airflow-secretsMinikube 与依赖容器如需彻底释放资源可另行执行minikube stop和docker-compose -f docker-compose-deps.yml down。10. 预期结果与性能基准部署成功的判定指标所有 Pod Runningkubectl get pods -A全部处于Running状态健康检查通过curl http://localhost:8585/api/v1/system/health返回 200RBAC 就绪openmetadata-pipelines-test命名空间内命名空间、ServiceAccount、Role/RoleBinding 均已创建配置加载Pod 内环境变量按 values 正确注入日志无错kubectl logs deployment/openmetadata-k8s-test显示正常启动。指南给出的参考性能基准单节点 Minikube、4 核 8GB 条件下完整部署启动时间 5 分钟含依赖在内的总内存占用 4GB正常负载下 CPU 2 核流水线 Job 创建到执行 30 秒。这套测试床的完整闭环是依赖服务容器化、集群本地化、values 覆盖K8s 原生 Airflow 迁移两条配置分支、验证覆盖 RBAC/配置/Job/失败诊断四个维度最终同时保证新增的 K8s 原生流水线能力可用、以及存量 Airflow 配置不回归。【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考