GCP Kubernetes部署Cube连接Snowflake生成YAML数据模型无响应

问题背景 #

Cube实例部署在GCP Kubernetes环境，已成功连接Snowflake数据库，可查看并选择数据表，但点击「Generate Data Model」选择YAML格式后无任何反应，无法生成模型。

部署配置（Helm values.yaml） #

# Default values for chart.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
intro: 1

image:
  repository: cubejs/cube
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: "v1.2.31"

cube_images:
  cubejs: "cubejs/cube:v1.2.32"
  cubeStore: "cubejs/cubestore:v1.2.32"   

imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""

serviceAccount:
  # Specifies whether a service account should be created
  create: true
  # Annotations to add to the service account
  annotations: {}
  # The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname template
  name: ""

podAnnotations: {}

podSecurityContext: {}
  # fsGroup: 2000

securityContext: {}
  # capabilities:
  #   drop:
  #   - ALL
  # readOnlyRootFilesystem: true
  # runAsNonRoot: true
  # runAsUser: 1000

# Environment variables for cube API and cubestore components
# Please ensure that this section is edited in order to support the DB 
# of your choice. 

config:
  vault_env:
    CUBEJS_DB_SNOWFLAKE_ACCOUNT:  "cubejs_db_snowflake_account"
    CUBEJS_DB_SNOWFLAKE_PRIVATE_KEY:  "cube_js_sf_key"
    CUBEJS_DB_SNOWFLAKE_PRIVATE_KEY_PASS: "cube_js_sf_key_passcode"
    CUBEJS_DB_SNOWFLAKE_AUTHENTICATOR: "cubejs_db_snowflake_authenticator"
    CUBEJS_DB_TYPE: "cubejs_db_type"
    CUBEJS_DB_SNOWFLAKE_WAREHOUSE: "cubejs_db_snowflake_warehouse"
    CUBEJS_DB_SNOWFLAKE_ROLE: "cubejs_db_snowflake_role"
    CUBEJS_DB_USER: "cubejs_db_snowflake_user"
    CUBEJS_DB_NAME: "cubejs_db_snowflake_name"
    CUBEJS_DB_SSL: cubejs_db_ssl
    CUBEJS_DEV_MODE: cubejs_dev_mode
    CUBEJS_API_SECRET: cubejs_api_secret
    CUBEJS_DB_EXPORT_GCS_CREDENTIALS: cubejs_db_export_gcs_credentials
    CUBESTORE_GCP_CREDENTIALS: cubestore_gcp_credentials
    CUBESTORE_GCS_BUCKET: cubestore_gcs_bucket
    CUBESTORE_GCS_SUB_PATH: cubestore_gcs_sub_path
    CUBESTORE_GCP_KEY_FILE: cubestore_gcp_key_file
    CUBEJS_DB_EXPORT_INTEGRATION: cubejs_db_export_integration
    CUBEJS_DB_EXPORT_BUCKET_TYPE: cubejs_db_export_bucket_type
    CUBEJS_DB_EXPORT_BUCKET: cubejs_db_export_bucket
    CUBEJS_DB_EXPORT_INTEGRATION: cubejs_db_export_integration

env:
  # this section is for the CUBE API deployment and the refresh worker
  # Keep in mind that the env var CUBEJS_REFRESH_WORKER to differentiate
  # the refresh worker from the API node is inside the template as it is
  # a mandatory env var for cube refresh worker role

  # Please keep in mind that the db username and password SHOULD NOT BE EXPOSED
  # IN PLAINTEXT AS BELOW. Use a vault service along with a k8s CSI driver to 
  # mount the secrets as env vars in a end-to-end encrypted fashion. 
  cube:
  - name: CUBEJS_DEFAULT_API_SCOPES
    value: graphql,meta,data,jobs
  - name: CUBEJS_CUBESTORE_HOST
    value: cubestore-router   
  - name: CUBEJS_LOG_LEVEL
    value: debug

  extraEnvVars:
    - name: NODE_OPTIONS
      value: "--max-old-space-size=6144"
    - name: RUST_BACKTRACE
      value: 1

cube:
  api:
    apiCount: 2
    resources:
      requests:
        cpu: "2"
        memory: "3Gi"
      limits:
        cpu: "2"
        memory: "3Gi"

  worker:
    resources:
      requests:
        cpu: "2"
        memory: "6Gi"
      limits:
        cpu: "2"
        memory: "6Gi"

cubestore:
  router:
    resources:
      requests:
        cpu: "4"
        memory: "6Gi"
      limits:
        cpu: "4"
        memory: "6Gi"

  workers:
    workersCount: 2
    resources:
      requests:
        cpu: "4"
        memory: "8Gi"
      limits:
        cpu: "4"
        memory: "8Gi"


  # Cubestore router and store worker env vars are as below
  # keep in mind that the env vars that differentiate the router from the worker
  # are in the respective deployment files
  cubestore:
#  - name: CUBESTORE_REMOTE_DIR
#    value: /cube/data
  - name: CUBEJS_LOG_LEVEL
    value: debug

# Sections for each of the components of the cube cluster
# Edit as per need.
cubeApi:
  image: "cubejs/cube:latest"
  service:
    type: NodePort
    port: 4000
    service_port: 4000
  pgsql:
    port: "15432"
  replicas: 1  

cubeRefreshWorker:
  image: "cubejs/cube:latest"
  service:
    type: ClusterIP
    port: 80
    service_port: 80
  replicas: 1  

cubestoreRouter:
  image: "cubejs/cubestore:latest"   
  service:
    type: ClusterIP
    port: "9999"
    service_port: 9999
  replicas: 1    

cubestoreWorker:
  image: "cubejs/cubestore:latest"   
  service:
    type: ClusterIP
    port: "10001"
    service_port: 10001
  replicas: 2

resources: {}
  # We usually recommend not to specify default resources and to leave this as a conscious
  # choice for the user. This also increases chances charts run on environments with little
  # resources, such as Minikube. If you do want to specify resources, uncomment the following
  # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
  # limits:
  #   cpu: 100m
  #   memory: 128Mi
  # requests:
  #   cpu: 100m
  #   memory: 128Mi

autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 100
  targetCPUUtilizationPercentage: 80
  # targetMemoryUtilizationPercentage: 80

nodeSelector: {}

tolerations: []

affinity: {}

排查与解决步骤 #

• 检查Cube API日志：执行kubectl logs <cube-api-pod-name>查看Pod日志，重点找生成模型时的错误信息，比如Snowflake元数据查询失败、权限不足、内存溢出等。
• 确认开发模式状态：CUBEJS_DEV_MODE必须设置为true才能启用数据模型生成功能，检查环境变量中该参数的实际取值是否正确。
• 验证Snowflake权限：确保Cube使用的Snowflake角色拥有目标数据表的元数据读取权限（如DESCRIBE TABLE、SHOW TABLES），即使能查看表，元数据读取可能需要额外权限。
• 检查资源使用情况：用kubectl top pod <cube-api-pod-name>查看Pod的CPU和内存占用，若资源耗尽会导致进程无响应。当前API实例内存限制为3Gi，若数据表数量多、结构复杂，可临时调高内存限制测试。
• 统一Cube版本：配置中存在版本不一致问题：image.tag为v1.2.31，cube_images.cubejs为v1.2.32，cubeApi.image用了latest。版本不兼容可能引发功能异常，建议所有组件统一使用固定版本（如v1.2.32）。
• 测试网络连通性：在Cube API Pod内测试与Snowflake的连通性，比如执行curl https://<your-snowflake-account>.snowflakecomputing.com，确保网络无阻塞。

内容的提问来源于stack exchange，提问作者Fabio