The module lifecycle stage: Preview
The module has requirements for installation

HiveMetastore

A named resource that allows you to create the final configuration and serves as the source of truth for the state of a specific deployed Hive Metastore service.

HiveMetastoreClassName

The class name that will be associated with a specific resource.
A service cannot be deployed without a created HiveMetastoreClass.

spec:
  hivemetastoreClassName: default

Instance

This section describes the resources of the service being created.
It must pass validation according to the sizingPolicy of the corresponding class:

spec:
  instance:
    memory:
      size: "4Gi"
    cpu:
      cores: 2
      coreFraction: "25%"

Fields:

  • memory.size — memory size for the Hive Metastore instance.
  • cpu.cores — number of CPU cores.
  • cpu.coreFraction — multiplier for CPU requests relative to CPU limits.

Supported Hive Metastore versions

The currently supported Hive Metastore version is 4.2.0.

Our container images for running Hive Metastore are based on the distroless architecture.

External connections

Hive Metastore can be configured to connect to various external services, such as databases and object stores, using the externalConnections section in the YAML specification.

spec:
  externalConnections:
    database:
      type: Postgres
      postgres:
        mode: Secret
        secretName: pg-creds
    objectStore:
      type: S3
      s3:
        endpoint: minio.minio:9000
        bucket: data-lake
        region: ru-east-1
        prefix: directory
        usePathStyle: true
        credentials:
          mode: Secret
          secretName: s3-creds

Database connection

Hive Metastore supports PostgreSQL as an external database server.

Two connection parameter management modes are supported:

  • Secret — connection parameters are stored in a Kubernetes Secret. This is the recommended mode.
  • Plain — connection parameters are specified directly in the HiveMetastore resource.

Secret mode for PostgreSQL

database:
  type: Postgres
  postgres:
    mode: Secret
    secretName: pg-creds

In this mode:

  • database credentials are stored in a Kubernetes Secret;
  • the secretName field must reference an existing Secret with connection parameters;
  • the host, port, database, username, and password fields must not be specified in spec.

Secret example:

apiVersion: v1
kind: Secret
metadata:
  name: pg-creds
type: Opaque
stringData:
  host: postgresql.postgresql
  port: "5432"
  database: my-database
  username: my-user
  password: plain-text-password

Plain mode for PostgreSQL

database:
  type: Postgres
  postgres:
    mode: Plain
    host: postgresql.postgresql
    port: 5432
    database: my-database
    username: my-user
    password: plain-text-password

In this mode:

  • host — PostgreSQL server address: Service, Ingress, FQDN, or IP;
  • port — database port;
  • database — database name for Hive Metastore tables;
  • username — username for database connection;
  • password — user password;
  • the secretName field must not be specified.

Security warning.
Plain mode exposes sensitive credentials in the YAML manifest. Use it only when necessary and ensure proper access control.

TLS for PostgreSQL connection

TLS for PostgreSQL connection can be configured in the externalConnections.database.postgres.tls section.

database:
  type: Postgres
  postgres:
    mode: Secret
    secretName: pg-creds
    tls:
      mode: CustomCertificate
      insecureSkipVerify: false
      caCertSecretName: postgres-ca

TLS parameters:

  • mode — TLS configuration management mode.
    • CertManager — cert-manager is used.
    • CustomCertificate — a custom CA certificate from a Secret is used.
  • insecureSkipVerify — disables server TLS certificate verification.
    • Default value: true.
    • For production, it is recommended to use false and provide a CA certificate.
  • caCertSecretName — name of the Secret with the CA certificate for verifying the PostgreSQL TLS certificate.
  • certManager — cert-manager settings.

If caCertSecretName is specified, the certManager section must not be specified.
If certManager is specified, the caCertSecretName field must not be specified.

PostgreSQL TLS with a custom CA certificate

database:
  type: Postgres
  postgres:
    mode: Secret
    secretName: pg-creds
    tls:
      mode: CustomCertificate
      insecureSkipVerify: false
      caCertSecretName: postgres-ca

Example Secret with a CA certificate:

apiVersion: v1
kind: Secret
metadata:
  name: postgres-ca
type: Opaque
stringData:
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

PostgreSQL TLS with cert-manager

database:
  type: Postgres
  postgres:
    mode: Secret
    secretName: pg-creds
    tls:
      mode: CertManager
      insecureSkipVerify: false
      certManager:
        issuerName: postgres-issuer
        dnsNames:
          - postgresql.postgresql
        usages:
          - client auth

certManager parameters:

  • issuerName — cert-manager Issuer name;
  • dnsNames — list of DNS names to include in the certificate;
  • usages — list of certificate usages.

S3 object store configuration

Hive Metastore can store external table data in an S3-compatible object store.

objectStore:
  type: S3
  s3:
    endpoint: minio.minio:9000
    bucket: data-lake
    region: ru-east-1
    prefix: directory
    usePathStyle: true
    credentials:
      mode: Secret
      secretName: s3-creds

Configuration parameters:

  • endpoint — S3 service address: Service, Ingress, FQDN, or IP;
  • bucket — bucket name for storing data;
  • region — S3 storage region;
  • prefix — path prefix inside the bucket;
  • usePathStyle — enables path-style bucket addressing.
    • Default value: true.

S3 credentials

Two S3 credential management modes are supported:

  • Secret — credentials are stored in a Kubernetes Secret. This is the recommended mode.
  • Plain — credentials are specified directly in the HiveMetastore resource.

Secret mode for S3

objectStore:
  type: S3
  s3:
    endpoint: minio.minio:9000
    bucket: data-lake
    region: ru-east-1
    prefix: directory
    usePathStyle: true
    credentials:
      mode: Secret
      secretName: s3-creds

In this mode:

  • the secretName field must reference an existing Secret;
  • the accessKey and secretKey fields must not be specified in spec.

Secret example:

apiVersion: v1
kind: Secret
metadata:
  name: s3-creds
type: Opaque
stringData:
  accessKey: access-key-here
  secretKey: secret-key-here

Plain mode for S3

objectStore:
  type: S3
  s3:
    endpoint: minio.minio:9000
    bucket: data-lake
    region: ru-east-1
    prefix: directory
    usePathStyle: true
    credentials:
      mode: Plain
      accessKey: access-key-here
      secretKey: secret-key-here

In this mode:

  • accessKey — S3 access key;
  • secretKey — S3 secret key;
  • the secretName field must not be specified.

Security warning.
Plain mode exposes access keys in the YAML manifest. For production, it is recommended to use Secret mode.

TLS for S3 connection

TLS for S3 connection can be configured in the externalConnections.objectStore.s3.tls section.

objectStore:
  type: S3
  s3:
    endpoint: minio.minio:9000
    bucket: data-lake
    region: ru-east-1
    prefix: directory
    usePathStyle: true
    credentials:
      mode: Secret
      secretName: s3-creds
    tls:
      mode: CustomCertificate
      insecureSkipVerify: false
      caCertSecretName: s3-ca

TLS parameters:

  • mode — TLS configuration management mode.
    • CertManager — cert-manager is used.
    • CustomCertificate — a custom CA certificate from a Secret is used.
  • insecureSkipVerify — disables S3 server TLS certificate verification.
    • Default value: true.
    • For production, it is recommended to use false and provide a CA certificate.
  • caCertSecretName — name of the Secret with the CA certificate for verifying the S3 TLS certificate.
  • certManager — cert-manager settings.

If caCertSecretName is specified, the certManager section must not be specified.
If certManager is specified, the caCertSecretName field must not be specified.

S3 TLS with a custom CA certificate

objectStore:
  type: S3
  s3:
    endpoint: minio.minio:9000
    bucket: data-lake
    credentials:
      mode: Secret
      secretName: s3-creds
    tls:
      mode: CustomCertificate
      insecureSkipVerify: false
      caCertSecretName: s3-ca

Example Secret with a CA certificate:

apiVersion: v1
kind: Secret
metadata:
  name: s3-ca
type: Opaque
stringData:
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

S3 TLS with cert-manager

objectStore:
  type: S3
  s3:
    endpoint: minio.minio:9000
    bucket: data-lake
    credentials:
      mode: Secret
      secretName: s3-creds
    tls:
      mode: CertManager
      insecureSkipVerify: false
      certManager:
        issuerName: s3-issuer
        dnsNames:
          - minio.minio
        usages:
          - client auth

certManager parameters:

  • issuerName — cert-manager Issuer name;
  • dnsNames — list of DNS names to include in the certificate;
  • usages — list of certificate usages.

Hive Metastore server-side TLS

Hive Metastore supports server-side TLS configuration through the spec.tls section.

Server-side TLS defines how TLS certificates for the Hive Metastore service itself are managed.

Two modes are supported:

  • CertManager — the certificate is issued and managed by cert-manager.
  • CustomCertificate — a custom TLS certificate from a Kubernetes Secret is used.

If the tls section is not specified, the default mode is CertManager.

Server-side TLS with cert-manager

In CertManager mode, the certManager section must be specified.

Exactly one of the following fields must be set:

  • clusterIssuerName;
  • issuerName.

Example with ClusterIssuer:

spec:
  tls:
    mode: CertManager
    certManager:
      clusterIssuerName: letsencrypt-prod

Example with namespaced Issuer:

spec:
  tls:
    mode: CertManager
    certManager:
      issuerName: hivemetastore-issuer

Parameters:

  • clusterIssuerName — cert-manager ClusterIssuer name;
  • issuerName — cert-manager Issuer name in the service namespace.

The clusterIssuerName and issuerName fields cannot be specified at the same time.

Server-side TLS with a custom certificate

In CustomCertificate mode, the customCertificate section must be specified.

spec:
  tls:
    mode: CustomCertificate
    customCertificate:
      serverTLSSecret: hivemetastore-server-tls
      serverCASecret: hivemetastore-server-ca

Parameters:

  • serverTLSSecret — name of a kubernetes.io/tls Secret with the tls.crt and tls.key keys;
  • serverCASecret — name of a Secret with the ca.crt key.

The certificate from serverTLSSecret must contain SAN entries with the DNS names of the Hive Metastore service.
Otherwise, clients with full TLS verification will reject the connection.

TLS Secret example:

apiVersion: v1
kind: Secret
metadata:
  name: hivemetastore-server-tls
type: kubernetes.io/tls
data:
  tls.crt: BASE64_ENCODED_CERT
  tls.key: BASE64_ENCODED_KEY

Example Secret with a CA certificate:

apiVersion: v1
kind: Secret
metadata:
  name: hivemetastore-server-ca
type: Opaque
stringData:
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

Status

The status of the Managed Hive Metastore service is reflected in the HiveMetastore resource.

Main status sections:

  • conditions — current state of the service and configuration application stages;
  • certificate — information about TLS certificates used by the service and external connections.

Status example:

status:
  certificate:
    client:
      Postgres:
        ttl: '3624'
      S3:
        ttl: '3624'
    server:
      ttl: '89'
  conditions:
    - lastTransitionTime: '2026-06-02T11:58:49Z'
      message: 'Service available: 1/1 replicas ready'
      observedGeneration: 1
      reason: ServiceAvailable
      status: 'True'
      type: Available

Conditions

The conditions structure shows the current state of the service.

Significant condition types:

  • Available — indicates whether the required number of replicas is running according to the deployment strategy.
  • ConfigurationValid — indicates whether the configuration has passed all validations of the associated HiveMetastoreClass.
  • LastValidConfigurationApplied — indicates whether the last valid configuration has been successfully applied at least once.
  • ScaledToLastValidConfiguration — indicates whether the number of running replicas matches the last valid configuration.

Condition fields:

  • type — condition type.
  • status — condition state. Possible values: True, False, Unknown.
  • reason — short machine-readable reason for the current state.
  • message — human-readable description of the current state.
  • lastTransitionTime — time when the condition state last changed.
  • observedGeneration — resource generation for which the state was calculated.

Example of a successful state:

conditions:
  - lastTransitionTime: '2026-06-02T11:58:49Z'
    message: 'Service available: 1/1 replicas ready'
    observedGeneration: 1
    reason: ServiceAvailable
    status: 'True'
    type: Available

A False status indicates an issue at one of the stages or incomplete state synchronization.
For such a state, the reason and message fields contain an explanation.

Example:

conditions:
  - lastTransitionTime: '2025-09-23T14:53:33Z'
    message: Syncing
    observedGeneration: 1
    reason: Syncing
    status: 'False'
    type: LastValidConfigurationApplied
  - lastTransitionTime: '2025-09-23T14:54:58Z'
    message: Not all the instances are running still waiting for 1 to become ready
    observedGeneration: 1
    reason: ScalingInProgress
    status: 'False'
    type: ScaledToLastValidConfiguration

Certificate status

The status.certificate section contains information about TLS certificates used by Hive Metastore.

status:
  certificate:
    client:
      Postgres:
        ttl: '3624'
      S3:
        ttl: '3624'
    server:
      ttl: '89'

Section structure:

  • certificate.server — information about the Hive Metastore server-side TLS certificate.
  • certificate.client — information about client TLS certificates for external connections.
  • certificate.client.Postgres — certificate used for connecting to PostgreSQL.
  • certificate.client.S3 — certificate used for connecting to S3.
  • ttl — remaining certificate lifetime. The value is returned by the operator as a string.
  • failed — indicates an error during certificate issuing, renewal, or validation. The field may be absent if no error has been recorded.

Example certificate status without errors:

certificate:
  client:
    Postgres:
      ttl: '3624'
    S3:
      ttl: '3624'
  server:
    ttl: '89'

Example certificate status with an error:

certificate:
  client:
    Postgres:
      failed: true
      ttl: '0'
  server:
    failed: false
    ttl: '89'

If failed is set to true, check the following:

  • existence of the specified Secrets;
  • correctness of Secret keys, for example ca.crt, tls.crt, tls.key;
  • certManager or customCertificate settings;
  • conditions in status.conditions, especially the reason and message fields.

Usage examples

Basic usage in Secret mode

  1. Create the hivemetastore namespace.
kubectl create namespace hivemetastore
  1. Create a Secret with PostgreSQL connection parameters.
apiVersion: v1
kind: Secret
metadata:
  name: pg-creds
  namespace: hivemetastore
type: Opaque
stringData:
  host: postgresql.postgresql
  port: "5432"
  database: my-database
  username: my-user
  password: plain-text-password
  1. Create a Secret with S3 credentials.
apiVersion: v1
kind: Secret
metadata:
  name: s3-creds
  namespace: hivemetastore
type: Opaque
stringData:
  accessKey: access-key-here
  secretKey: secret-key-here
  1. Create the HiveMetastore resource.
kubectl apply -f managed-services_v1alpha1_hivemetastore_with_secret_mode.yaml -n hivemetastore
apiVersion: managed-services.deckhouse.io/v1alpha1
kind: HiveMetastore
metadata:
  name: hivemetastore-sample
spec:
  hivemetastoreClassName: default
  externalConnections:
    database:
      type: Postgres
      postgres:
        mode: Secret
        secretName: pg-creds
    objectStore:
      type: S3
      s3:
        endpoint: minio.minio:9000
        bucket: data-lake
        region: ru-east-1
        prefix: directory
        usePathStyle: true
        credentials:
          mode: Secret
          secretName: s3-creds
  instance:
    memory:
      size: "4Gi"
    cpu:
      cores: 2
      coreFraction: "25%"
  1. Wait until the instance is created and all conditions are set to True.
kubectl get hivemetastore hivemetastore-sample -n hivemetastore -o wide -w

Plain mode

In Plain mode, sensitive data is specified directly in the configuration.

apiVersion: managed-services.deckhouse.io/v1alpha1
kind: HiveMetastore
metadata:
  name: hivemetastore-sample
spec:
  hivemetastoreClassName: default
  externalConnections:
    database:
      type: Postgres
      postgres:
        mode: Plain
        host: postgresql.postgresql
        port: 5432
        database: my-database
        username: my-user
        password: plain-text-password
    objectStore:
      type: S3
      s3:
        endpoint: minio.minio:9000
        bucket: data-lake
        region: ru-east-1
        prefix: directory
        usePathStyle: true
        credentials:
          mode: Plain
          accessKey: access-key-here
          secretKey: secret-key-here
  instance:
    memory:
      size: "4Gi"
    cpu:
      cores: 2
      coreFraction: "25%"

This mode is convenient for development and testing, but it should be used with caution in production due to security considerations.

Secret mode

In Secret mode, sensitive information is stored in Kubernetes Secrets.

apiVersion: managed-services.deckhouse.io/v1alpha1
kind: HiveMetastore
metadata:
  name: hivemetastore-sample
spec:
  hivemetastoreClassName: default
  externalConnections:
    database:
      type: Postgres
      postgres:
        mode: Secret
        secretName: pg-creds
    objectStore:
      type: S3
      s3:
        endpoint: minio.minio:9000
        bucket: data-lake
        region: ru-east-1
        prefix: directory
        usePathStyle: true
        credentials:
          mode: Secret
          secretName: s3-creds
  instance:
    memory:
      size: "4Gi"
    cpu:
      cores: 2
      coreFraction: "25%"

Before applying this configuration, create the corresponding Secrets.

For database credentials:

apiVersion: v1
kind: Secret
metadata:
  name: pg-creds
type: Opaque
stringData:
  host: postgresql.postgresql
  port: "5432"
  database: my-database
  username: my-user
  password: plain-text-password

For object store credentials:

apiVersion: v1
kind: Secret
metadata:
  name: s3-creds
type: Opaque
stringData:
  accessKey: access-key-here
  secretKey: secret-key-here

Using server-side TLS with cert-manager

apiVersion: managed-services.deckhouse.io/v1alpha1
kind: HiveMetastore
metadata:
  name: hivemetastore-sample
spec:
  hivemetastoreClassName: default
  tls:
    mode: CertManager
    certManager:
      clusterIssuerName: letsencrypt-prod
  externalConnections:
    database:
      type: Postgres
      postgres:
        mode: Secret
        secretName: pg-creds
    objectStore:
      type: S3
      s3:
        endpoint: minio.minio:9000
        bucket: data-lake
        region: ru-east-1
        prefix: directory
        usePathStyle: true
        credentials:
          mode: Secret
          secretName: s3-creds
  instance:
    memory:
      size: "4Gi"
    cpu:
      cores: 2
      coreFraction: "25%"

Using server-side TLS with a custom certificate

apiVersion: managed-services.deckhouse.io/v1alpha1
kind: HiveMetastore
metadata:
  name: hivemetastore-sample
spec:
  hivemetastoreClassName: default
  tls:
    mode: CustomCertificate
    customCertificate:
      serverTLSSecret: hivemetastore-server-tls
      serverCASecret: hivemetastore-server-ca
  externalConnections:
    database:
      type: Postgres
      postgres:
        mode: Secret
        secretName: pg-creds
    objectStore:
      type: S3
      s3:
        endpoint: minio.minio:9000
        bucket: data-lake
        region: ru-east-1
        prefix: directory
        usePathStyle: true
        credentials:
          mode: Secret
          secretName: s3-creds
  instance:
    memory:
      size: "4Gi"
    cpu:
      cores: 2
      coreFraction: "25%"

Using TLS for external connections

Example configuration with TLS for PostgreSQL and S3:

apiVersion: managed-services.deckhouse.io/v1alpha1
kind: HiveMetastore
metadata:
  name: hivemetastore-sample
spec:
  hivemetastoreClassName: default
  externalConnections:
    database:
      type: Postgres
      postgres:
        mode: Secret
        secretName: pg-creds
        tls:
          mode: CustomCertificate
          insecureSkipVerify: false
          caCertSecretName: postgres-ca
    objectStore:
      type: S3
      s3:
        endpoint: minio.minio:9000
        bucket: data-lake
        region: ru-east-1
        prefix: directory
        usePathStyle: true
        credentials:
          mode: Secret
          secretName: s3-creds
        tls:
          mode: CustomCertificate
          insecureSkipVerify: false
          caCertSecretName: s3-ca
  instance:
    memory:
      size: "4Gi"
    cpu:
      cores: 2
      coreFraction: "25%"