Deploy the cache service with Kubernetes #

This topic covers deploying a minimally customized cache service in standalone mode with the cache service Helm chart. This optional deployment is only recommended if the preferred embedded mode is not sufficient for your usage.

Overview #

To use Hive materialized views or table scan redirections in SEP, the cache service must first be deployed and enabled. The cache service must be deployed and running, and materialized views enabled in order to use materialized views in data products.

Configure the cache service #

There are several top-level nodes in the cache service Helm chart that you must modify for a minimum cache service configuration:

• config:
• resources:
• database:
• expose:

If you are using TLS, this must also be considered. This section covers getting started with these four configuration steps. Our reference documentation provides details about the content of the cache service Helm chart, including yaml sections not discussed here.

As with SEP, we strongly suggest that you initially deploy the cache service with the minimum configuration described in this topic, and ensure that it deploys and is accessible before making any additional customizations described in our reference documentation.

Before you begin #

Get the latest starburst-cache-service Helm chart as described in our installation guide with the configured registry access.

Configure service accounts and locators #

You must define the service accounts and locators to be used by the cache service:

config:
  config.properties: |
    service-database.user=alice
    service-database.password=test123
    service-database.jdbc-url=jdbc:mysql://mysql-server:13306/cachesvc
    starburst.user=bob
    starburst.jdbc-url=jdbc:trino://coordinator:8080

Configure resources #

The following values must be defined in the resources: node of the cache service Helm chart:

• CPU resources for requests and limits - The defaults are sufficient for most environments; however, they must work with the instance type you are using.
• Memory resources for requests and limits - The defaults are sufficient for most environments; however, they must work with the instance type you are using.

Configure the PostgreSQL backing database #

The configuration properties for the PostgreSQL database are found in the database: top-level node. You can use a self-managed, existing external database instance, or the default PostgreSQL database internal to this service. We strongly suggest using the default internal database. Use the type: node to select the type of database:

database:
  type: "[internal|external]"

As a minimal customization, you must ensure that the following are set correctly for your environment:

    databaseName: "cacheservice"
    databaseUser: "cacheservice"
    databasePassword: "CacheServicePass1234"

You must also configure volume: persistence options, if desired, as well as the resources: for the backing database itself in the database: node. For a complete list of available backing database properties, see our reference documentation.

Configure TLS (optional) #

If your organization uses TLS, you must enable and configure your cache service to work with it. The most straightforward way to handle TLS is to terminate TLS at the load balancer or ingress, using a signed certificate. We strongly suggest this method, which method requires no additional configuration in the cache service.

If you choose not handle TLS using that methods, you can instead configure it in the expose: top-level node of the HMS Helm chart:

expose:
  type: "[clusterIp|nodePort|loadBalancer|ingress]"

You must refer to our reference documentation for full details on configuring each of these types. The default expose: type is clusterIp. However, this is not suitable for production environments. If you need help choosing which type is best, refer to the expose: documentation for SEP.

Deploy the cache service #

When the cache service is configured, run the following command to deploy it. In this example, the minimal values YAML file with the registry credentials named registry-access.yaml is used along with the cache-service-values.yaml containing the cache service customizations. Replace 4XX.0.0 with the Helm chart version of the desired SEP release as documented on the versions page:

$ helm upgrade cache-service starburst/starburst-cache-service \
    --install \
    --version 4XX.0.0 \
    --values ./registry-access.yaml \
    --values ./cache-service-values.yaml

Next steps #

• Complete your cache service configuration
• Enable materialized views
• [Optional] Enable table scan redirections