Helm


View on GitHub

A Helm chart is available and is the recommended way to install in Kubernetes. Only Helm v3 is supported.


helm repo add lensesio https://helm.repo.lenses.io
helm repo update

Use helm to install Lenses, with default values:

helm install lenses lensesio/lenses --namespace lenses --create-namespace

The official Helm chart is available on GitHub. Use charts/lenses/values.yaml as a reference for the full list of available parameters and features.

Lenses Provision 

Starting from version 5.0 Lenses provision operation has 2 primary methods:

More information on the sidecar container pattern in Kubernetes: manage multiple pods

For a detailed list of deprecated fields in Helm value, from previous versions, visit: Helm Deprecated Fields

Lenses Wizard Only Mode 

To avoid provisioning via the sidecar container method, we can simply disable it using:

lenses:
  provision:
    enabled: false

Then we can follow the Lenses UI Wizard Mode, after Lenses is deployed. Lenses UI Wizard Guide

Lenses Sidecar Provision 

Lenses provision method is using a sidecar container, co-located with the lenses application container, in the same pod. The sidecar container is using dynamic configuration commands, via the Lenses CLI to provision lenses with the required information, at container startup.


All connection urls and additional options are now moved inside lenses.provision field and include options such as: License, Kafka brokers, Zookeepers, Schema Registries, Kafka Connect Clusters and their security and metrics options.


Both Lenses CLI and the lenses.provision Helm values field, depend on a common provision.yaml structure. You can find details in Lenses Provision Yaml which is required reading to help with configuring the field lenses.provision.yaml. Field lenses.provision.yaml can accept either normal yaml syntax, or stringified yaml input.

Also to help clarifying what are the lenses.provision limitations, find more details in: Provision CLI - GitOps Limitations


Some important sections of lenses.provision.yaml 


Example:

lenses:
  provision:
    enabled: true

    yaml:
      license:
        fileRef:
          inline: "[LICENSE FILE CONTENTS]"

      connections:
        kafka: # Constant connection name
          templateName: Kafka
          tags: ["production", "cluster-1"] # required, even if empty array
          configurationObject:
            protocol: SASL_SSL
            kafkaBootstrapServers:
              - SASL_SSL://my-cluster-1:9096
              - SASL_SSL://my-cluster-2:9096
              - SASL_SSL://my-cluster-3:9096

        custom-connect-cluster:
          templateName: KafkaConnect
          tags: ["production", "cluster-1", "lenses-processors"] # required, even if empty array
          configurationObject:
            workers:
              - https://my-custom-connect-cluster:8083
            metricsPort: 8084
            metricsSsl: true
            metricsType: JMX

Default admin user 

The security user contains the default username and password for the super administrator. See how to secure your admin account. For more details visit values.yaml

Example:

lenses:
  security:
    defaultUser:
      username: admin
      password: admin

Lenses Storage & Persistence 

There are two ways to configure a Lenses Database Storage

  • An H2 embedded database on the local filesystem - (quick start and default option)
  • Postgresql database - (production recommended option)

For more information, on how to configure Lenses database, see Persistent Storage

For the local filesystem option and also if you use Data Policies module, in order to persist H2 data and your data policies rules, you have to set up Lenses with a Kubernetes Persistent Volume in Helm values, using persistence field. You can find more details in Persistence

Example:

persistence:
  enabled: true
  accessModes:
    - ReadWriteOnce
  size: 5Gi

For the Postgresql option, you can enable it using field lenses.storage.postgres.enabled and also configure database connection details using fields under lenses.storage.postgres For more information, on how to configure Postgresql as Lenses database, see Postgresql

Example:

lenses:
  storage:
    postgres:
      enabled: true
      host:
      port: # optional, defaults to 5432
      username: # use "external" to manage it using secrets
      password: # use "external" to manage it using secrets
      database:
      schema: # optional, defaults to public schema


      # Set the username for postgres connection
      # Use the value "external" to bypass the Helm validation and handle the username externally.
      # The common use case for using "external" is to take the actual value from a Kubernetes Secret resource already deployed.
      # To do so, add the following definition under 'lenses.additionalEnv' key:
      # - name: LENSES_STORAGE_POSTGRES_USERNAME
      #   valueFrom:
      #     secretKeyRef:
      #       name: [SECRET_RESOURCE_NAME]
      #       key: [SECRET_RESOURCE_KEY]

      # Set the password for postgres connection
      # Use the value "external" to bypass the Helm validation and handle the password externally.
      # The common use case for using "external" is to take the actual value from a Kubernetes Secret resource already deployed.
      # To do so, add the following definition under 'lenses.additionalEnv' key:
      # - name: LENSES_STORAGE_POSTGRES_PASSWORD
      #   valueFrom:
      #     secretKeyRef:
      #       name: [SECRET_RESOURCE_NAME]
      #       key: [SECRET_RESOURCE_KEY]

Lenses Provision Secrets 

From version 5.0 onwards, secrets to be created and managed by the Helm release, that are passed as connection info to Lenses, e.g. Kafka brokers certificates, are moved inside lenses.provision.secrets and automatically mounted to the provision sidecar container. To include them in values.yaml inline pass them as entries under lenses.provision.secrets.data.

To be able to consume these secrets, they have to be declared as file references with fileRef.filePath inside lenses.provision.yaml. Since all secrets under lenses.provision.secrets are mounted under /mnt/provision-secrets, the filenames absolute paths should be located under this location.

Example:

lenses:
  provision:
    enabled: true

    yaml:
      license:
        fileRef:
          filePath: /mnt/provision-secrets/license.json
      connections:
        kafka: # Constant connection name
          templateName: Kafka
          tags: ["production", "cluster-1"] # required, even if empty array
          configurationObject:
            kafkaBootstrapServers:
              - SSL://your.kafka.broker.0:9093
              - SSL://your.kafka.broker.1:9093
              - SSL://your.kafka.broker.2:9093
            protocol: SSL
            sslTruststore:
              fileRef:
                filePath: /mnt/provision-secrets/kafka.truststore.jks
            sslTruststorePassword: "truststorePassword"
            sslKeystore:
              fileRef:
                filePath: /mnt/provision-secrets/kafka.keystore.jks
            sslKeystorePassword: "keystorePassword"
            sslKeyPassword: "keyPassword"

    secrets:
      # Base64 encoded
      data:
        license.json: |-
                    ewogICJpbmRleF9uYW1lIjogIIHsKICAgICAgI..==
        kafka.keystore.jks: |-
                    /u3+7QAAAAIAAAACAAAAAgAGY2Fyb290...==
        kafka.truststore.jks: |-
                    /u3+7QAAAAIAAAABAAAAAgAGY2Fyb290...==

Lenses Provision Sidecar container configuration 

You can also customize provision sidecar container options, such as passing a customized private Lenses CLI image etc. This is also used as a tool to avoid having secrets inline in lenses.provision.secrets and using existing secrets in the namespace where Lenses is deployed to. These can be mounted under lenses.sidecar.additionalVolumeMounts as in the example below. You also need to declare existing secrets in additionalVolumes and similarly to Lenses Provision Secrets consume them, they need to be declared as file references with fileRef.filePath inside lenses.provision.yaml.

Example:

lenses:
  provision:
    enabled: true

    yaml:
      license:
        fileRef:
          filePath: /mnt/lenses-license/license.json
      connections:
        kafka: # Constant connection name
          templateName: Kafka
          tags: ["production", "cluster-1"] # required, even if empty array
          configurationObject:
            kafkaBootstrapServers:
              - SSL://your.kafka.broker.0:9093
              - SSL://your.kafka.broker.1:9093
              - SSL://your.kafka.broker.2:9093
            protocol: SSL
            sslTruststore:
              fileRef:
                filePath: /data/lenses-super-secrets/kafka.truststore.jks
            sslTruststorePassword: "sslTruststorePassword"
            sslKeystore:
              fileRef:
                filePath: /data/lenses-super-secrets/kafka.keystore.jks
            sslKeystorePassword: "keystorePassword"
            sslKeyPassword: "keyPassword"

    sidecar:
      image:
        repository: lensesio/lenses-cli
        pullPolicy: IfNotPresent
        # registrySecretKey:

      # Additional volume mounts to load additional files from pre-existing volumes, secrets or vault secrets to use in provisioning
      # Use it in conjuction with additionalVolumes
      additionalVolumeMounts:
        - name: lenses-license
          mountPath: "/mnt/lenses-license"
        - name: lenses-super-secrets
          mountPath: "/data/lenses-super-secrets"

additionalVolumes:
  - name: lenses-license
    secret:
      secretName: lenses-license
  - name: lenses-super-secrets
    secret:
      secretName: lenses-super-secrets

Streaming SQL options 

To configure Streaming SQL options for Lenses use the lenses.sql field. For more details visit values.yaml

Example:

lenses:
  sql:
    mode: KUBERNETES
    heap: 900M
    memLimit: 1152M
    memRequest: 128M
    ssl:
      trustStoreFileData: |-

      keyStoreFileData: |-

      trustStorePassword:
      keyStorePassword:
      keyPassword:

Lenses HTTPS (TLS) 

lenses.tls contains tls options for configuring Lenses with TLS termination. For more details visit values.yaml

Example:

lenses:
  tls:
    enabled: true
    # base64 encoded keystore data
    # openssl base64 < keystore.jks | tr -d '\n'
    keyStoreFileData: |-
            /u3+7QAAAAIAAAACAAAAAgAGY2Fyb290...==
    # base64 keystore password
    # echo "$password" | tr -d '\n' | base64
    keyStorePassword: |-
            YWRtaW4xMjM0
    # base64 encoded truststore data
    # openssl base64 < truststore.jks | tr -d '\n'
    trustStoreFileData: |-
            /u3+7QAAAAIAAAABAAAAAgAGY2Fyb290...==
    # base64 truststore password
    # echo "$password" | tr -d '\n' | base64
    trustStorePassword: |-
            YWRtaW4xMjM0
    # base64 key password
    # echo "$password" | tr -d '\n' | base64
    keyPassword: |-
            YWRtaW4xMjM0
    clientAuth: false

Single Sign On ( SAML 2.0 ) 

Users can authenticate via SSO (Single Sign On) using the SAML 2.0 protocol using one of the supported integrations. To use SSO remember to also enable TLS. For more details visit values.yaml

Example:

lenses:
  security:
    saml:
      enabled: true
      baseUrl: "https://lenses-prod.eastus2.cloudapp.azure.com"
      provider: "azure"
      keyStoreFileData: |-
                YmFzZTY0IG9mIGtleXN0b3JlIA==
      keyStorePassword: "password"
      keyPassword: "password"
      metadataFileData: |-
                LUlkUCBiYXNlNjQgWE1MIGZpbGUgY29udGVudC0=

Additional Sidecar containers 

With sidecar containers configuration you may deploy supporting additional containers such as data extractors/generators, etc. alongside Lenses container and provision sidecar. You can read more about sidecars. For more details visit values.yaml

# Simple example
sidecarContainers:
  - name: sidecar-example
    image: alpine
    command: ["sh", "-c", "watch datetime"]