---
title: "Installation using Helm"
description: ""
url: "https://docs.itrsgroup.com/docs/geneos/7.11.0/administration/orchestrated-environments/installation-using-helm/index.html"
---
## Overview

This guide takes you through the deployment process of deploying Geneos containers in Kubernetes and OpenShift environments using Helm.

Helm is a package manager for Kubernetes. Helm uses a packaging format called charts. A chart is a collection of files that describe a related set of Kubernetes resources.

Charts are created as files laid out in a particular directory tree. They can be packaged into versioned archives to be deployed. ITRS provides updated Helm charts with each Geneos release.

For more information about Helm, see the [Official Helm docs](https://helm.sh/docs/).


**Note**


If you deploy to **Amazon EKS Fargate-only** clusters, see [Amazon EKS Fargate compatibility](https://docs.itrsgroup.com/docs/geneos/7.11.0/administration/orchestrated-environments/aws-eks-fargate-compatibility/index.html). Fargate requires `mode: StatefulSet` for Netprobe, API-based log collection, and EFS-backed persistent volumes instead of EBS (`gp2`/`gp3`).



## Helm prerequisites

This section provides the prerequisites for installing using Helm, you must also ensure your system meets the general prerequisites for installation in a orchestrated environment.

For more info, see [Data collection in an orchestrated environment](https://docs.itrsgroup.com/docs/geneos/7.11.0/collection/data-collection-in-orchestrated-environments/data-collection-in-orchestrated-env/index.html).

### Add the ITRS repository

To add the ITRS repository, run the following command:

```
helm repo add itrs https://helm.itrsgroup.com
```


**Note**

 There is no access control or authentication required to access the ITRS Helm repository. 


### Create a registry secret

Before deploying Helm charts, you must add a registry secret so that you can use the ITRS Docker repository. To do this, use the following command:

```
kubectl create secret docker-registry itrsdocker \
 --docker-server=https://docker.itrsgroup.com \
 --docker-username=USERNAME \
 --docker-password=PASSWORD \
 -n NAMESPACE

```

### Kubernetes monitoring

To perform Kubernetes log monitoring, you must have a Docker container configured with JSON logging.

### Kubernetes Role-Based Access Control requirements for Netprobe

The Netprobe runs using a service account that requires certain Role-Based Access Control (RBAC) permissions in order to collect metrics. The required service account, roles, and role bindings are automatically created during installation. The Netprobe Helm chart will automatically create the `ClusterRole` and `ClusterRoleBinding` with `get/list/watch` access to `node` and `node/proxy` resources. However, it is possible to disable the automatic creation of a service account and supply your own service account and roles.

The Netprobe Helm chart will also create the following resources depending on Netprobe configuration:

- If the Netprobe is configured to collect metrics for all namespaces, the `ClusterRole` will also have `get/list/watch` access to the following resources in all namespaces:
  - `deployments`
  - `daemonsets`
  - `statefulsets`
  - `pods`
  - `pods/log`
  - `resourcequotas`
  - `replicasets`
  - `jobs`
  - `events`
- If the Netprobe is configured to collect metrics for a specific namespace only, a `Role` and `RoleBinding` with `get/list/watch` access to the following resources will be created in each of the target namespaces:
  - `deployments`
  - `daemonsets`
  - `statefulsets`
  - `pods`
  - `pods/log`
  - `resourcequotas`
  - `replicasets`
  - `jobs`
  - `events`


**Note**


When `metrics.events.useCoreEventsApi` is `false` (default), the generated role must grant `get/list/watch` on the `events` resource in the `events.k8s.io` API group. This permission is not required when `metrics.events.useCoreEventsApi` is `true`.



## Helm deployments

This section provides general information that applies to all Helm deployments of Geneos components.

### Create a namespace

To create the `geneos` namespace, use the following command:

```
kubectl create namespace geneos
```

### Helm chart versions

Helm charts use `a.b.c+x.y.z` versioning to align with Geneos product releases, where:

  - `a.b.c` is the Helm chart version number
  - `x.y.z` is the Geneos release version

Helm follows semantic versioning (SemVer), which allows additional labels, such as build metadata, to be appended by a plus sign (+).

To search for all available Helm chart versions, use the following command:

```
helm search repo itrs --versions
```

### Install a Helm chart

#### Install the latest version 

To install the latest version of a Helm chart, run the following command:

```
helm install -f <configuration_filename> -n <namespace> <release_name> itrs/<chart_name>
```

For example:

```
helm install -f config.yaml -n geneos netprobe itrs/netprobe
```

#### Install a specific version 

To install a specific version, use the `--version` flag to indicate the specific Helm chart version:

```
helm install -f config.yaml -n geneos netprobe itrs/netprobe --version a.b.c+x.y.z
```

For example:

```
helm install -f config.yaml -n geneos netprobe itrs/netprobe --version 7.8.0+7.8.0
```

#### Install the latest major version 

This is a flexible option that allows you to install the latest Helm chart version within the specified major version.

For example:

```
helm install netprobe itrs/netprobe --version "~7.0.0"
```

This command installs the latest version 7 Helm chart available. The version constraint ensures that only version 7 charts are considered, so if version 8.0.0 becomes available, it will not be installed.

#### Install the latest minor version

This is a more restrictive option that allows you to install the latest Helm chart version within the specified minor version.

For example:

```
helm install netprobe itrs/netprobe --version "~7.8.0"
```

This command installs the latest version 7.8.x Helm chart available. The version constraint ensures that only version 7.8.x charts are considered, so if version 7.9.0 becomes available, it will not be installed.


**Note**

 Helm automatically creates the service accounts and roles. For more information, see [Kubernetes RBAC Requirements](#kubernetes-role-based-access-control-requirements-for-netprobe). 


### Helm installation best practices

In the `values.yml` file of the Geneos Helm charts, no version is explicitly specified:

```yaml
image:
  repository: "docker.itrsgroup.com/netprobe"
  # tag: ""  # Let chart version determine this automatically
  pullPolicy: IfNotPresent
```

It is recommended to specify version ranges instead of pointing to an exact version.

#### Using exact version vs. version range constraints

The `--version` flag can be used with either an exact version or a version range constraint:

- Exact version (for example, `--version 7.8.0+7.8.0`):
  - This installs a specific, fixed version useful when you need to pin to a particular version for consistency.
- Version range constraint (for example, `--version "~7.0.0"`):
  - This uses the tilde (`~`) operator to match a range of versions and install the latest version within the specified range. This is recommended for automatic patch updates while maintaining version boundaries.

Using version range constraints allows for:

- Cleaner `values.yaml` file so you can focus on configuration, not version management.
- Consistent versioning, where the chart version drives image version automatically.
- Less maintenance, allowing you to set the version range once to get compatible updates.

For more information on version range constraints, see the [Helm dependencies documentation](https://helm.sh/docs/chart_best_practices/dependencies).

## Netprobe deployments

This section provides information specific to Netprobe deployments.

One Netprobe or Collection Agent chart can be configured to connect to multiple Gateways and run in the same cluster.

The Helm chart determines which collection image version is used during installation based on the configuration settings. By default, the image tag in the YAML file is blank, and the Collection Agent runs an unprivileged image as a non-root user.

```
agent:
  image:
    repository: docker.itrsgroup.com/collection/collection-agent
    tag: ""
    pullPolicy: IfNotPresent
```

To use an image with elevated file permissions, enable either log collection or persistence, or both, in the YAML file. This will start a Collection Agent image that has elevated file permissions. The word `privileged` in the image name indicates this. For example:

```
collection-agent:
    Container ID:  docker://c73f663032997adada3f8a66d8c7b626639afa43d65f1aece4edec7e44ff3ea1
    Image: docker.itrsgroup.com/collection/collection-agent:3.3.1-jre11-privileged-r0
```

The chart uses the `privileged` Collection Agent image when any of the following apply:

1. Filesystem log collection is enabled.
2. Outbound routing is enabled.
3. Persistence and agent StorePersistence are enabled.

Otherwise, the chart uses the default `unprivileged` image.

The following configurations are supported:

- [DaemonSet deployment](#daemonsetdeployment)
- [Non-DaemonSet deployment](#non-daemonsetdeployment)
- [Monitor specific namespaces](#monitor-specific-namespaces)
- [Amazon EKS Fargate](https://docs.itrsgroup.com/docs/geneos/7.11.0/administration/orchestrated-environments/aws-eks-fargate-compatibility/index.html)

To get a list of all configuration options, run:

```
helm show values itrs/netprobe
```

You can create a `config.yaml` file from these options for your use case. The sections below provide minimal examples that you can adapt.

### DaemonSet deployment

You can deploy Netprobe as a DaemonSet to all matching nodes. This mode supports log collection and is the default deployment mode. Each DaemonSet pod collects metrics and logs for the pods on that node only. An additional StatefulSet is launched to collect metrics and events that are not node-specific, such as `ResourceQuotas`.


**Important**


DaemonSet deployment is not supported on Amazon EKS Fargate-only clusters. Fargate does not schedule DaemonSet pods. For Fargate, use [Non-DaemonSet deployment](#non-daemonsetdeployment) with `mode: StatefulSet`. For more information, see [Amazon EKS Fargate](https://docs.itrsgroup.com/docs/geneos/7.11.0/administration/orchestrated-environments/aws-eks-fargate-compatibility/index.html).



To install a Netprobe as a DaemonSet and monitor full metrics and events across all namespaces, use the following `config.yaml` file:

```
cluster: myCluster

gateways:
- host: "10.1.1.1"
  port: 7039

netprobe:
  resources:
    limits:
      cpu:  "1"
      memory: "1Gi"
    requests:
      cpu: "500m"
      memory: "768Mi"

agent:
  resources:
    limits:
      cpu:  "1"
      memory: "1Gi"
    requests:
      cpu: "500m"
      memory: "768Mi"
```

### Non-DaemonSet deployment

You can deploy a Netprobe in one pod and collect metrics for the entire cluster.

Starting with Geneos 7.3, a non-DaemonSet deployment supports log collection by reading logs through the Kubernetes API. For more information, see [Log collection via the Kubernetes API](#log-collection-via-the-kubernetes-api).


**Note**


Recommended for Amazon EKS Fargate. Set `mode: StatefulSet` and use API-based log collection. Fargate does not support DaemonSet mode, filesystem log collection, `hostPath`, privileged containers, or EBS-backed PVCs. For more information, see [Netprobe Helm chart compatibility](https://docs.itrsgroup.com/docs/geneos/7.11.0/administration/orchestrated-environments/aws-eks-fargate-compatibility/index.html#netprobe-helm-chart-compatibility) in AWS EKS Fargate compatibility.



To install a Netprobe to monitor full metrics and events in all namespaces, without using a DaemonSet, use the following `config.yaml` file:

```
mode: StatefulSet
cluster: myCluster

gateways:
- host: "10.1.1.1"
  port: 7039

netprobe:
  resources:
    limits:
      cpu:  "1"
      memory: "1Gi"
    requests:
      cpu: "500m"
      memory: "768Mi"

agent:
  resources:
    limits:
      cpu:  "1"
      memory: "1Gi"
    requests:
      cpu: "500m"
      memory: "768Mi"
```

### Monitor specific namespaces

By default, metrics are collected for all namespaces but you can configure your Netprobe deployment to monitor specific namespaces.

To install a DaemonSet with full metrics, events, and log collection for specific namespaces, use the following `config.yaml` file:

```
mode: DaemonSet
cluster: myCluster

gateways:
- host: "10.1.1.1"
  port: 7039

namespaces:
- ns1
- ns2

netprobe:
  resources:
    limits:
      cpu:  "1"
      memory: "1Gi"
    requests:
      cpu: "500m"
      memory: "768Mi"

agent:
  resources:
    limits:
      cpu:  "1"
      memory: "1Gi"
    requests:
      cpu: "500m"
      memory: "768Mi"
```

### Log collection via the Kubernetes API

When the Collection Agent reads logs through the Kubernetes API instead of from the host file system, it doesn't require host log directory mounts and can run as a non-root user.

This mode is recommended for:

- Clusters that enforce the Restricted Pod Security Standard
- Non-DaemonSet deployments
- Amazon EKS Fargate-only clusters (required; filesystem log collection is not available on Fargate)
- Environments where you want to avoid using the `privileged` Collection Agent image

To enable this mode, set `logs.readMode` to `api`. When API log collection is enabled, the Helm chart:

- Uses the `unprivileged` Collection Agent image (`collection-agent:<version>` without the `privileged` suffix).
- Skips the `hostPath` mounts for `/var/log/containers`, `/var/log/pods`, and `/var/lib/docker/containers`.
- Adds `get` and `list` permissions for the `pods/log` resource to the generated `ClusterRole` (or per-namespace `Role` when `namespaces` is set).

#### Configuration options

The following values control log collection in API mode:

| Value | Effect |
| --- | --- |
| `logs.enabled: true` | Adds the `KubernetesLogCollector` to the agent configuration. |
| `logs.readMode: api` | Reads container logs through the Kubernetes API. |
| `daemonSet.pvc.enabled: true` | Configures the Netprobe DaemonSet to use a shared persistent volume claim (PVC); otherwise, the DaemonSet pods use `hostPath` volumes. |
| `daemonSet.pvc.storageClassName: <your_storage_class>` | Specifies the `StorageClass` for the DaemonSet PVC. The `StorageClass` must support the `ReadWriteMany` access mode. |
| `persistence.enabled: true` | Stores the log read position cursor (`log_reference`) on a persistent volume. Log collection resumes from the last read position after a pod is replaced. Use this option if your environment can't tolerate gaps or duplicate log lines. |
| `persistence.enabled: false` | Stores the cursor in an `emptyDir` volume. The cursor is lost when the pod is replaced. Use this option if persistent storage is unavailable or unnecessary. |
| `persistence.storageClassName: <your_storage_class>` | Specifies the `StorageClass` for the persistent volume claim. On Amazon EKS Fargate, use an EFS-backed StorageClass provisioned by the EFS CSI driver. Do not use `gp2` or `gp3` EBS-backed StorageClasses. Fargate pods cannot attach EBS volumes. |
| `agent.disableStorePersistence: true` | Forces the workflow store-and-forward queues to in-memory mode, even when `persistence.enabled: true`. Use this option to keep the `unprivileged` image when persistence is enabled only to retain the log collector position. |


**Note**


On Amazon EKS Fargate, API log collection and outbound routing require persistent storage backed by Amazon EFS (EFS CSI driver + EFS StorageClass or static PV). See [Persistent storage on Fargate](https://docs.itrsgroup.com/docs/geneos/7.11.0/administration/orchestrated-environments/aws-eks-fargate-compatibility/index.html#persistent-storage-on-fargate).



### Installation with a trusted certificate authority

To install a Netprobe in your cluster with a trusted certificate authority, perform the following steps:

1. Add your trusted certificate authority to your secrets by running:

    ```command
    kubectl create secret generic -n <namespace> root-ca --from-file=root-ca.crt="rootCA.pem"
    ```

    where `rootCA.pem` is your trusted certificate authority.

2. Use the following `config.yaml` file to install a Netprobe that uses the trusted certificate authority and connects to a Gateway using a secure protocol.

    ```yaml
    cluster: myCluster

    gateways:
    - host: "10.1.1.1"
      port: 7039
      secure: true

    netprobe:
      tls:
        certificateChainSecret: root-ca

      resources:
        limits:
          cpu:  "1"
          memory: "1Gi"
        requests:
          cpu: "500m"
          memory: "768Mi"

    agent:
      resources:
        limits:
          cpu:  "1"
          memory: "1Gi"
        requests:
          cpu: "500m"
          memory: "768Mi"
    ```

## Gateway deployments

This section provides information specific to Gateway deployments.


**Note**


On Amazon EKS Fargate, if `persistence.enabled: true`, use an EFS-backed StorageClass for Gateway PVCs. EBS-backed StorageClasses (`gp2`, `gp3`) are not supported on Fargate pods. For more information, see [Amazon EKS Fargate](https://docs.itrsgroup.com/docs/geneos/7.11.0/administration/orchestrated-environments/aws-eks-fargate-compatibility/index.html).



To fetch list of all possible configuration options, run:

```
helm show values itrs/gateway --version a.b.c+x.y.z
```

You can construct a `config.yaml` file using these options to fit your use case. The sections below provide minimal examples that you can adapt.

### Insecure installation

To install a Gateway in your cluster, without TLS security, use the following `config.yaml` file:

```
licenceDaemon:
  host: localhost
  port: 7041
  secure: false

persistence:
  enabled: true
  size: 1Gi

tls:
  enabled: false

resources:
  limits:
    cpu:  "1"
    memory: "1Gi"
  requests:
    cpu: "500m"
    memory: "768Mi"
```

### Secure installation

To install a Gateway in your cluster, with TLS security, perform the following steps:

1. Add your `tls.key` and `tls.cert` files to your secrets by running:

    ```command
    kubectl create secret tls -n <namespace> gw-tls --key="tls.key" --cert="tls.crt"
    ```

2. Optionally, you can also specify a trusted certificate authority for the Gateway. Run the following command to add your trusted certificate authority to your secrets:

    ```command
    kubectl create secret generic -n <namespace> root-ca --from-file=root-ca.crt="rootCA.pem"
    ```

    where `rootCA.pem` is your your trusted certificate authority.

3. Deploy the Gateway to a specified namespace by running:

    ```command
    helm install -f config.yaml -n <namespace> gateway itrs/gateway --version a.b.c+x.y.z
    ```

 The following is an example of a `config.yaml` file where the TLS certificate and private key are specified.

  ```yaml
    licenceDaemon:
      host: localhost
      port: 7041
      secure: false

    persistence:
      enabled: true
      size: 1Gi

    tls:
      enabled: true
      secret: "gw-tls"
      
    resources:
      limits:
        cpu:  "1"
        memory: "1Gi"
      requests:
        cpu: "500m"
        memory: "768Mi"
  ```

  The following is an example of a `config.yaml` file where the TLS certificate, private key, and trusted certificate authority are specified.

  ```yaml
    licenceDaemon:
      host: localhost
      port: 7041
      secure: false

    persistence:
      enabled: true
      size: 1Gi

    tls:
      enabled: true
      secret: "gw-tls"
      certificateChainSecret: "root-ca"

    resources:
      limits:
        cpu:  "1"
        memory: "1Gi"
      requests:
        cpu: "500m"
        memory: "768Mi"
  ```

### Installation with a setup file

To install a Gateway in your cluster with an initial setup file, use the following command:

```
helm install -f <configuration_filename> --set-file setup.file=<setup_file> -n <namespace> <release_name> itrs/gateway --version a.b.c+x.y.z
```

For example:

```
helm install -f config.yaml --set-file setup.file=gateway.setup.xml -n geneos gateway itrs/gateway --version a.b.c+x.y.z
```


**Note**

  If `persistence.enabled` is set to `true` and there is a saved setup file in the persistent volume, the saved setup file will be used instead of the specified setup file.

The setup file should not define the Gateway name.



### Connecting to ITRS Analytics

To install a Gateway that connects to ITRS Analytics, follow these steps:

1. Go to the Gateway directory and generate an API key file by running the following command:

    ```
    ./gateway2.linux_64 -store-app-key app-key.txt <client_id> <client_secret> obcerv
    ```

2. Create a `secret` containing your API key file by running:

    ```
    kubectl create secret generic app-key --from-file=app-key=app-key.txt -n geneos
    ```

3. In the Helm configuration file, set `setup.appKeySecret` to the name of the `secret` containing the API key file and `setup.obcerv.url` to the ITRS Analytics URL. For example:

    ```
    licenceDaemon:
      host: localhost
      port: 7041
      secure: false

    persistence:
      enabled: true
      size: 1Gi

    tls:
      enabled: false

    resources:
      limits:
        cpu:  "1"
        memory: "1Gi"
      requests:
        cpu: "500m"
        memory: "768Mi"

    setup:
      appKeySecret: app-key
      obcerv:
        url: https://obcerv.example.com
    ```

4. Deploy the Gateway to a specified namespace by running:

    ```
    helm install -f <configuration_filename> -n <namespace> gateway itrs/gateway --version a.b.c+x.y.z
    ```

## Web Dashboard deployments

This section provides information specific to Web Dashboard deployments.

To fetch a list of all possible configuration options, run:

```command
helm show values itrs/web-server --version a.b.c+x.y.z
```

You can construct a `config.yaml` file using these options to fit your use case. The sections below provide minimal examples that you can adapt.

### Installation with an Ingress

To install a Web Dashboard in your cluster and allow external access through an Ingress resource, configure the `ingress` section of the Helm configuration file.

For example, this configuration will install a Web Dashboard and create an Ingress resource that uses an Ingress-Nginx controller:

```yaml
ingress:
  enabled: true
  externalHostname: example.com
  ingressClassName: nginx
  path: /geneos-dashboard
```

The base URL of the Web Dashboard service will be at `<protocol>://example.com/geneos-dashboard`. The `protocol` is either http or https, depending on the setting of your Kubernetes cluster.

### Enabling basic authentication

To install a Web Dashboard in your cluster with basic authentication enabled, follow these steps:

1. Create a generic secret for each user by running the following command:

    ```command
    kubectl create secret generic -n <namespace> <secret_name> --from-literal=password=<password>
    ```

    The password for the user should be stored at the `password` key of the generic secret.

2. Add an `authentication` section to the Helm configuration file.

    - Set the `authentication.mode` setting to `basic`.
    - Configure the `authentication.users` setting based on the allowed users.

    For example, the following configuration will allow two users, `user` and `admin`, to log in to the Web Dashboard.

      ```yaml
        ingress:
          enabled: true
          externalHostname: example.com
          ingressClassName: nginx
          path: /geneos-dashboard

        authentication:
          mode: basic
          basic:
            users:
            - name: user
              passwordSecret: user-password-secret
              roles: [ ROLE_USER ]
            - name: admin
              passwordSecret: admin-password-secret
              roles: [ ROLE_USER, ROLE_SUPERVISOR ]
      ```

  The passwords for `user` and `admin` are contained in the `user-password-secret` and `admin-password-secret` secrets, respectively.

### Enabling ITRS Analytics Keycloak authentication

To install a Web Dashboard in your cluster using ITRS Analytics Keycloak as the authentication method, follow these steps:

1. Create a configuration file for the `geneos-clients` Helm chart.

    In the `internal.iam.redirectUri` setting, define a list of URIs where the Web Dashboard may be possibly located.

    
**Note**

  The **Valid redirect URIs** setting of the `geneos-ui` client of ITRS Analytics Keycloak will be set to the value of this setting. 


    For example, the following `geneos-clients` Helm configuration file will enable ITRS Analytics Keycloak to allow login to Web Dashboards at `https://localhost` and at `https://iax-domain.com`.

    ```yaml
    internal:
      iam:
        redirectUri:
        - https://localhost:*
        - https://iax-domain.com/*
    ```

2. Create another configuration file for the `web-server` Helm chart.
  
    - Set the `authentication.mode` setting to `iax`.
    - Configure the `authentication.sso` setting:
      - `dashboardUserGroups` - list of user groups or roles allowed to access the **Dashboards** and **Slideshows** sections of the Web Dashboard
      - `configUserGroups` - list of user groups or roles allowed to access the **Config** section of the Web Dashboard

    For example:

    ```yaml
    ingress:
      enabled: true
      externalHostname: iax-domain.com
      ingressClassName: nginx
      path: /geneos-dashboard

    authentication:
      mode: iax
      sso:
        dashboardUserGroups: [ admin , user ]
        configUserGroups: [ admin ]
    ```

3. Use the configuration files created to install the `geneos-clients` and `web-server` Helm charts in the same cluster and namespace containing the ITRS Analytics Helm charts.

    For example:

    ```bash
    helm install -f config-geneos-clients.yaml -n itrs geneos-clients itrs/geneos-clients --version a.b.c+x.y.z
    helm install -f config-web-server.yaml -n itrs web-server itrs/web-server --version a.b.c+x.y.z
    ```

### Enabling TLS certificate authentication

To allow the Web Dashboard to log in to a Gateway using a TLS certificate, follow these steps:

1. Create a TLS secret containing the private key and certificate that the Web Dashboard will use to log in to the Gateway. This certificate must be trusted by the Gateway.

    ```command
    kubectl create secret tls -n <namespace> web-server-geneos-auth-tls --key="tls.key" --cert="tls.pem"
    ```

2. In the Helm configuration file, set the `tls.geneosAuthenticationSecret` field to the name of the created TLS secret. For example:

    ```yaml
    ingress:
      enabled: true
      externalHostname: example.com
      ingressClassName: nginx

    tls:
      geneosAuthenticationSecret: web-server-geneos-auth-tls
    ```

Refer to [Web Dashboard SSL certificate authentication](https://docs.itrsgroup.com/docs/geneos/7.11.0/visualization/web-dashboard/index.html#ssl-certificate-authentication) for more information.


**Note**

 When deploying the Web Dashboard using Helm, you do not need to manually add the private key and certificate to the keystore and configure the `security.properties` file. These are automatically completed during the Helm installation process. 


## Helpful commands

### Check liveness endpoint

Kubernetes has a mechanism to check the liveness of the component using the following command:

```
curl http://<np host>:<np port>/liveness
```

The command uses an `http` protocol if the port is insecure, and an `https` protocol if the port is secure.

If the component is alive, the command above will return a `200` code. Otherwise, it will return a `503` code, and will restart the container running the component.

### List configuration options

To see the complete list of available configuration options, run:

```
helm show values itrs/<chart_name> --version a.b.c+x.y.z
```

### Check chart information

To check the status and version of your Helm charts, run:

```
helm ls
```

The output will look similar to:

```
ubuntu@ip-192-168-18-189:~$ helm ls
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
netprobe        default         1               2021-08-26 18:55:28.328483978 +0800 PST deployed        netprobe-5.7.6  5.7.2
```

To check detailed chart information, run:

```
helm show chart itrs/<chart_name> --version a.b.c+x.y.z
```

The output will look similar to:

```
apiVersion: v2
appVersion: 5.10.0
description: ITRS Geneos Gateway
name: gateway
type: application
version: 5.10.0-beta.5
```