Configuration, environment and Pod overrides

The HBase Stacklet definition also supports overriding configuration properties, environment variables and Pod specs, either per role or per role group, where the more specific override (role group) has precedence over the less specific one (role).

Overriding operator-set properties can interfere with the operator and can lead to problems.

Configuration properties

For a role or role group, at the same level of config, you can specify: configOverrides for the following files:

  • hbase-site.xml

  • hbase-env.sh

  • security.properties

hdfs-site.xml is not listed here, the file is always taken from the referenced HDFS cluster. If you want to modify it, take a look at HDFS configuration overrides.

For example, if you want to set the hbase.rest.threads.min to 4 and the HBASE_HEAPSIZE to two GB adapt the restServers section of the cluster resource like so:

restServers:
  roleGroups:
    default:
      config: {}
      configOverrides:
        hbase-site.xml:
          hbase.rest.threads.min: "4"
        hbase-env.sh:
          HBASE_HEAPSIZE: "2G"
      replicas: 1

Just as for the config, you can specify this at role level as well:

restServers:
  configOverrides:
    hbase-site.xml:
      hbase.rest.threads.min: "4"
    hbase-env.sh:
      HBASE_HEAPSIZE: "2G"
  roleGroups:
    default:
      config: {}
      replicas: 1

All override property values must be strings. The properties are formatted and escaped correctly into the XML file, respectively inserted as is into the hbase-env.sh file.

For a full list of configuration options we refer to the HBase configuration documentation.

The security.properties file

The security.properties file is used to configure JVM security properties. It is very seldom that users need to tweak any of these, but there is one use-case that stands out, and that users need to be aware of: the JVM DNS cache.

The JVM manages it’s own cache of successfully resolved host names as well as a cache of host names that cannot be resolved. Some products of the Stackable platform are very sensible to the contents of these caches and their performance is heavily affected by them. As of version 3.4.12, Apache Hbase performs poorly if the positive cache is disabled. To cache resolved host names, and thus speeding up Hbase queries you can configure the TTL of entries in the positive cache like this:

  masters:
    configOverrides:
      security.properties:
        networkaddress.cache.ttl: "5"
        networkaddress.cache.negative.ttl: "0"
  regionServers:
    configOverrides:
      security.properties:
        networkaddress.cache.ttl: "10"
        networkaddress.cache.negative.ttl: "0"
  restServers:
    configOverrides:
      security.properties:
        networkaddress.cache.ttl: "30"
        networkaddress.cache.negative.ttl: "0"
The operator configures DNS caching by default as shown in the example above.

For details on the JVM security see https://docs.oracle.com/en/java/javase/11/security/java-security-overview1.html

Environment variables

The HBaseCluster Stacklet does not support environment variable overrides with the envOverrides key like other Stacklets, but you can set environment variables in the hbase-env.sh file as described in the previous section.

Pod overrides

The HBase Stacklet and operator also support Pod overrides, allowing you to override any property that you can set on a Kubernetes Pod. Read the Pod overrides documentation to learn more about this feature.

JVM argument overrides

Stackable operators automatically determine the set of needed JVM arguments, such as memory settings or trust- and keystores. Using JVM argument overrides you can configure the JVM arguments according to the concepts page.

One thing that is different for HBase, is that all heap-related arguments will be passed in via the env variable HBASE_HEAPSIZE, all the other ones via HBASE_OPTS, HBASE_MASTER_OPTS, HBASE_REGIONSERVER_OPTS and HBASE_REST_OPTS. The HBASE_HEAPSIZE variable is documented as follows in the HBase FAQs:

Set the HBASE_HEAPSIZE environment variable in $HBASE_HOME/conf/hbase-env.sh if your install needs to run with a larger heap. HBASE_HEAPSIZE is like HADOOP_HEAPSIZE in that its value is the desired heap size in MB. The surrounding '-Xmx' and 'm' needed to make up the maximum heap size java option are added by the hbase start script (See how HBASE_HEAPSIZE is used in the $HBASE_HOME/bin/hbase script for clarification).

Looking at bin/hbase, you can actually add the m suffix to make the unit more clear, the script will detect this here and work correctly.

Because of this, it is not possible to change -XmS and -XmX via JVM argument overrides. You need to envOverride HBASE_HEAPSIZE instead.