The default_storage parameter in values.yaml controls the default storage class for all persistent volumes created by the Helm chart.

For a component like BookKeeper, which requires stateful storage, we need to override the default_storage class when the BookKeeper Persistent Volume Claims (PVCs) are created.

There are two ways to override default_storage:

The default values will create a ClusterIP for all components. ClusterIPs are only accessible within the Kubernetes cluster. The easiest way to work with Pulsar is to log into the bastion host (assuming it is in the pulsar namespace):

kubectl exec $(kubectl get pods -l component=bastion -o jsonpath="{.items[*].metadata.name}" -n pulsar) -it -n pulsar — /bin/bash

Once you are logged into the bastion, you can run Pulsar admin commands:

For external access, you can use a load balancer. Here is an example set of values to use for load balancer on the proxy:

If you are using a load balancer on the proxy, you can find the IP address using:

kubectl get service -n pulsar

Or if you would rather go directly to the broker:

kubectl port-forward -n pulsar $(kubectl get pods -n pulsar -l component=broker -o jsonpath='{.items[0].metadata.name}') 8080:8080

kubectl port-forward -n pulsar $(kubectl get pods -n pulsar -l component=broker -o jsonpath='{.items[0].metadata.name}') 6650:6650

The Pulsar Admin Console is installed in your cluster by enabling the console with this values setting:

The Pulsar Admin Console will be automatically configured to connect to the Pulsar cluster.

By default, the Pulsar Admin Console has authentication disabled. You can enable authentication with these settings:

To learn more about using the Pulsar Admin Console, see Admin Console Tutorial.

To port forward the proxy admin and Pulsar ports to your local machine:

kubectl port-forward -n pulsar $(kubectl get pods -n pulsar -l component=proxy -o jsonpath='{.items[0].metadata.name}') 8080:8080

kubectl port-forward -n pulsar $(kubectl get pods -n pulsar -l component=proxy -o jsonpath='{.items[0].metadata.name}') 6650:6650

Or if you would rather go directly to the broker:

kubectl port-forward -n pulsar $(kubectl get pods -n pulsar -l component=broker -o jsonpath='{.items[0].metadata.name}') 8080:8080

kubectl port-forward -n pulsar $(kubectl get pods -n pulsar -l component=broker -o jsonpath='{.items[0].metadata.name}') 6650:6650

To access Pulsar Admin Console on your local machine, forward port 80:

You can enable a full Prometheus stack (Prometheus, Alertmanager, Grafana) from [kube-prometheus](https://github.com/prometheus-operator/kube-prometheus). This includes default Prometheus rules and Grafana dashboards for Kubernetes.

In an addition, this chart can deploy Grafana dashboards for Pulsar as well as Pulsar-specific rules for Prometheus.

To enable the Prometheus stack, use the following setting in your values file:

To enable the Grafana dashboards, modify the following setting:

To enable the Kubernetes default rules, use the following setting:

Tiered storage (offload to blob storage) can be configured in the storageOffload section of the values.yaml file. Instructions for AWS S3 and Google Cloud Storage are provided in the file.

In addition, you can configure any S3 compatible storage. There is explicit support for Tardigrade, which is a provider of secure, decentralized storage. You can enable the Tardigarde S3 gateway in the extra configuration. The instructions for configuring the gateway are provided in the tardigrade section of the values.yaml file.

If you enable Pulsar SQL, the cluster provides Trino access to the data stored in BookKeeper (and tiered storage, if enabled). Trino is exposed on the service named <release>-sql.

The easiest way to access the Trino command line is to log into the bastion host and then connect to the Trino service port, like this:

bin/pulsar sql --server pulsar-sql:8081

Where the value for the server option should be the service name plus port. Once you are connected, you can enter Trino commands. Example:

To access Pulsar SQL from outside the cluster, you can enable the ingress option which will expose the Trino port on hostname. We have tested with the Traefik ingress, but any Kubernetes ingress should work. You can then run SQL queries using the Trino CLI and monitoring Trino using the built-in UI (point browser to the ingress hostname). Authentication is not enabled on the UI, so you can log in with any username.

It is recommended that you match the Trino CLI version to the version running as part of Pulsar SQL.

The Trino CLI supports basic authentication, so if you enabled that on the Ingress (using annotations), you can have secure Trino access. Example:

The Helm chart has the following optional dependencies:

The chart can enable token-based authentication for your Pulsar cluster. For information on token-based authentication in Pulsar, see Pulsar token authentication admin documentation.

For authentication to work, the token-generation keys need to be stored in Kubernetes secrets along with some default tokens (for superuser access).

The chart includes tooling to automatically create the necessary secrets or you can do this manually.

Use the following settings to enable automatic generation of the secrets and enable token-based authentication:

When the provision container is enabled, it will check if the required secrets exist. If they don’t exist, it will generate new token keys and use those keys to generate the default set of tokens.

The name of the key secrets are:

Using these keys, it will generate tokens for each role listed in superUserRoles. Based on the default settings, the following secrets will be created to store the tokens:

A number of values need to be stored in secrets prior to enabling token-based authentication.