The previous installation of Hive on MR3 on Kubernetes assumes that Metastore along with its MySQL database runs as an external component. Alternatively we can run Metastore as a Pod so that the administrator user needs to provide only a MySQL database for Metastore. The resultant Kubernetes cluster is depicted in the following diagram:


Configuring the Metastore Pod

There are several yaml files that the user should update manually in accordance with kubernetes/ as well as Kubernetes cluster settings.


This file creates a governing Service required for the StatefulSet for Metastore. The user should use the same port number specified by the environment variable HIVE_METASTORE_PORT in kubernetes/

  - name: tcp
    port: 9850


This file creates a Role for a Metastore Pod. The name of the Role resource (metastore-role) is read in, so there is no need to update this file.


This file creates a Pod for running Metastore. The user should update several sections in this file according to Kubernetes cluster settings.

In the spec/template/spec/containers section:

  • The image field should match the Docker image specified by DOCKER_HIVE_IMG in kubernetes/

  • The resources/requests and resources/limits specify the resources to to be allocated to a Metastore Pod.

  • The ports/containerPort field should match the port number specified in metastore-service.yaml.

          - image:
                cpu: 2
                memory: 16Gi
                cpu: 2
                memory: 16Gi
            - containerPort: 9850
              protocol: TCP

In the spec/template/spec/volumes section:

  • The configMap/name field under conf-k8s-volume should match the name specified by CONF_DIR_CONFIGMAP in kubernetes/

  • The secret/secretName field under key-k8s-volume should match the name specified by KEYTAB_SECRET in kubernetes/

          - name: conf-k8s-volume
              name: hivemr3-conf-configmap
          - name: key-k8s-volume
              secretName: hivemr3-keytab-secret

In the spec/template/spec/hostAliases section:

  • HIVE_DATABASE_HOST in kubernetes/ (not in already specifies the host where the database for Metastore is running. If it uses a host unknown to the default DNS, the user should add its alias. The following example adds a host name red0 that is unknown to the default DNS.
          - ip: ""
            - "red0"

Connecting Metastore to an existing MySQL database

For using an existing MySQL database, we assume that the MySQL connector specified in HIVE_MYSQL_DRIVER in (not in kubernetes/ is compatible with the MySQL database before creating the Docker image. If HIVE_MYSQL_DRIVER is not set in, the user should manually place a MySQL connector jar file inside the Metastore Pod using either a PersistentVolume or a hostPath volume. For details, see Troubleshooting.

Then update HIVE_METASTORE_HOST in kubernetes/


Here hivemr3-metastore-0 is the unique name of the Pod that will be running Metastore, and hivemr3 is the namespace.

Next update kubernetes/conf/hive-site.xml as necessary to configure Metastore. In particular, check the following configuration keys relevant to security:

  • hive.metastore.pre.event.listeners or metastore.pre.event.listeners
  • hive.server2.enable.doAs

Make sure that the configuration key javax.jdo.option.ConnectionDriverName matches the MySQL connection jar file by setting it to either com.mysql.jdbc.Driver or com.mysql.cj.jdbc.Driver.

  <!-- <value>com.mysql.jdbc.Driver</value> -->

In order to run Metastore, the user can execute the script kubernetes/

$ kubernetes/ 
service/metastore created

Executing the script kubernetes/ starts a Metastore Pod (of the unique name hivemr3-metastore-0) in a moment:

$ kubectl get -n hivemr3 pods
NAME                  READY   STATUS    RESTARTS   AGE
hivemr3-metastore-0   1/1     Running   0          37s

Now the user can run HiveServer2 by executing the script kubernetes/

Initializing schema

In order to initialize schema when starting Metastore, update kubernetes/yaml/metastore.yaml as follows:

        args: ["start", "--init-schema"]

After starting Metastore by executing kubernetes/, the user may want to restore kubernetes/yaml/metastore.yaml so as not to inadvertently initialize schema again:

        args: ["start"]

When initializing schema, Metastore reads the environment variable HIVE_WAREHOUSE_DIR in mr3-run/kubernetes/ and stores the path to the data warehouse in the MySQL database. Once the path to the data warehouse is registered in Metastore, the user can update it only by directly accessing the MySQL database. Hence setting HIVE_WAREHOUSE_DIR to a new path and running HiveServer2 has no effect.

Since the date warehouse is shared by all the components of Hive on MR3, its path should be globally valid in every Pod. For example, HIVE_WAREHOUSE_DIR=hdfs://red0:8020/tmp/hive is okay because it points to a globally valid location (namely, directory /tmp/hive on HDFS running on red0). If not, the user may not be able to create new databases or tables depending on whether or not Metastore can create new directories under the path. For example, if we set HIVE_WAREHOUSE_DIR to /foo/bar where Metastore has no write permission inside its Pod, the user cannot create new databases or tables. If Metastore happens to have write permission on /foo/bar, the user can create new databases and tables.

Stopping Metastore

In order to stop Metastore, delete StatefulSet for Metastore.

$ kubectl -n hivemr3 delete statefulset hivemr3-metastore