Configuring Helm for Production

This guide provides instructions for configuring the Polaris Helm chart for a production environment. For full list of chart values, see the main Helm chart documentation.

The default Helm chart values are suitable for development and testing, but they are not recommended for production. Following are the key areas to consider for production deployment.

Persistence#

By default, the Polaris Helm chart uses an in-memory metastore, which is not suitable for production. A persistent backend must be configured to ensure data is not lost when pods restart.

To use a persistent backend, persistence.type must be set to relational-jdbc, and a Kubernetes secret containing the database connection details must be provided.

persistence:
  type: relational-jdbc
  relationalJdbc:
    secret:
      name: "polaris-persistence-secret" # A secret containing db credentials
      username: "username"
      password: "password"
      jdbcUrl: "jdbcUrl"

Resource Management#

For a production environment, it is crucial to define resource requests and limits for the Polaris pods. Resource requests ensure that pods are allocated enough resources to run, while limits prevent them from consuming too many resources on the node.

Resource requests and limits can be set in the values.yaml file:

resources:
  requests:
    memory: "8Gi"
    cpu: "4"
  limits:
    memory: "8Gi"
    cpu: "4"

Adjust these values based on expected workload and available cluster resources.

Pod Priority#

In a production environment, it is advisable to set a priorityClassName for the Polaris pods. This ensures that the Kubernetes scheduler gives them higher priority over less critical workloads, and helps prevent them from being evicted from a node that is running out of resources.

First, a PriorityClass must be created in the cluster. For example:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: polaris-high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for Polaris service pods only."

Then, the priorityClassName can be set in the values.yaml file:

priorityClassName: "polaris-high-priority"

Authentication#

In a multi-replica production environment, all Polaris pods must share the same token signing keys. The default chart generates random keys for each pod, which will cause token validation failures.

To use a shared set of keys, a Kubernetes secret to store an RSA key pair or a symmetric key must first be created.

RSA Key Pair#

authentication:
  tokenBroker:
    type: rsa-key-pair
    secret:
      name: "polaris-rsa-key-pair-secret" # A secret containing the RSA key pair
      rsaKeyPair:
        publicKey: "public.pem"
        privateKey: "private.pem"

Symmetric Key#

authentication:
  tokenBroker:
    type: symmetric-key
    secret:
      name: "polaris-symmetric-key-secret" # A secret containing the symmetric key
      symmetricKey:
        secretKey: "symmetric.key"

Scaling#

For high availability, multiple replicas of the Polaris server can be run. This requires a persistent backend to be configured as described above.

Static Replicas#

replicaCount must be set to the desired number of pods.

replicaCount: 3

Autoscaling#

autoscaling can be enabled to define the minimum and maximum number of replicas, and CPU or memory utilization targets.

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 5
  targetCPUUtilizationPercentage: 80
  targetMemoryUtilizationPercentage: 80

Pod Topology Spreading#

For better fault tolerance, topologySpreadConstraints can be used to distribute pods across different nodes, racks, or availability zones. This helps prevent a single infrastructure failure from taking down all Polaris replicas.

Here is an example that spreads pods across different zones and keeps the number of pods in each zone from differing by more than one:

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: "DoNotSchedule"