tyk-oss provides the default deployment of the Tyk Open Source stack. It includes the following components:
  • Tyk Gateway: An open source Enterprise API Gateway, supporting REST, GraphQL, TCP and gRPC protocols.
  • Tyk Pump: An analytics purger that moves the data generated by your Tyk gateways to any back-end storage.

​
What components are deployed with Tyk OSS Chart?

By default, this chart installs following components as subcharts on a Kubernetes cluster using the Helm package manager.
ComponentEnabled by DefaultFlag
Tyk Gatewaytruen/a
Tyk Pumpfalseglobal.components.pump
Tyk Operatorfalseglobal.components.operator
To enable or disable each component, change the corresponding enabled flag. Also, you can set the version of each component through image.tag. You could find the list of version tags available from Docker hub. For quick start guide, please see Quick Start with Tyk OSS Helm Chart.

​
Prerequisites

​
Tyk OSS Installations

​
Installing the Chart

To install the chart from the Helm repository in namespace tyk with the release name tyk-oss: First, add our Helm repo and get default values: 
    helm repo add tyk-helm https://helm.tyk.io/public/helm/charts/
    helm repo update
    helm show values tyk-helm/tyk-oss > values.yaml
For further documentation relating to helm command usage, please refer to the helm docs. See Configuration section for the available config options and modify your local values.yaml file accordingly. Then install the chart: 
helm install tyk-oss tyk-helm/tyk-oss -n tyk --create-namespace -f values.yaml

​
Uninstalling the Chart

helm uninstall tyk-oss -n tyk
This removes all the Kubernetes components associated with the chart and deletes the release.

​
Upgrading Chart

helm upgrade tyk-oss tyk-helm/tyk-oss -n tyk -f values.yaml

​
Configuration

To list all configurable options with detailed comments: 
helm show values tyk-helm/tyk-oss > values.yaml
You can update any value in your local values.yaml file and use -f [filename] flag to override default values during installation. Alternatively, you can use --set flag to set it in Tyk installation. To configure Tyk components, users can utilize both config files and environment variables. Notably, environment variables take precedence over config files. To maintain simplicity and consistency, the Tyk Helm Charts deploy components with an empty config file while setting container environment variables based on user-defined values. This approach ensures seamless integration with Kubernetes practices, allowing for efficient management of configurations. For a comprehensive overview of available configurations, please refer to the configuration documentation.

​
Setting Environment Variables

Should any environment variables not be set by the Helm Chart, users can easily add them under the extraEnvs section within the charts for further customization. Values set under extraEnvs would take precedence over all configurations. Example of setting extra environment variable to gateway: 
tyk-gateway:
  gateway:
    extraEnvs:
    - name: TYK_GW_LOGLEVEL
      value: debug
An example is listed below for setting extra environment variable using ConfigMap data, using gateway: 
tyk-gateway:
  gateway:
    extraEnvs:
    - name: CONFIG_USERNAME
      valueFrom:
        configMapKeyRef: 
          name: backend-user
          key: backend-username
An example is listed below for setting extra environment variable using secret data, using gateway: 
tyk-gateway:
  gateway:
    extraEnvs:
    - name: SECRET_USERNAME
      valueFrom:
        secretKeyRef: 
          name: backend-user
          key: backend-username
In the above example, an extra environment variable SECRET_USERNAME will be added to the Gateway container, with a value of backend-username associated with the secret backend-user. It is useful if you want to access secret data from Tyk Gateway configuration file (tyk.conf) or API definitions.

​
Set Redis Connection Details (Required)

Tyk uses Redis for distributed rate-limiting and token storage. You may use the Bitnami chart to install or Tyk’s simple-redis chart for POC purpose. Set the following values after installing Redis:
NameDescription
global.redis.addrsRedis addresses
global.redis.passRedis password in plain text
global.redis.passSecret.nameIf global.redis.pass is not provided, you can store it in a secret and provide the secret name here
global.redis.passSecret.keyNamekey name to retrieve Redis password from the secret
Recommended: via Bitnami chart For Redis you can use these rather excellent charts provided by Bitnami. Copy the following commands to add it: 
helm upgrade tyk-redis oci://registry-1.docker.io/bitnamicharts/redis -n tyk --create-namespace --install --version 19.0.2
Please make sure you are installing Redis versions that are supported by Tyk. Please refer to Tyk docs to get list of supported versions.
Follow the notes from the installation output to get connection details and password. 
  Redis(TM) can be accessed on the following DNS names from within your cluster:

    tyk-redis-master.tyk.svc.cluster.local for read/write operations (port 6379)
    tyk-redis-replicas.tyk.svc.cluster.local for read-only operations (port 6379)

  export REDIS_PASSWORD=$(kubectl get secret --namespace tyk tyk-redis -o jsonpath="{.data.redis-password}" | base64 --decode)
The Redis address as set by Bitnami is tyk-redis-master.tyk.svc.cluster.local:6379 You can reference the password secret generated by Bitnami chart by --set global.redis.passSecret.name=tyk-redis and --set global.redis.passSecret.keyName=redis-password, or just set global.redis.pass=$REDIS_PASSWORD Evaluation only: via simple-redis chart Another option for Redis, to get started quickly, is to use our simple-redis chart.
Please note that these provided charts must never be used in production or for anything but a quick start evaluation only. Use Bitnami Redis or Official Redis installation guides in any other case. We provide this chart, so you can quickly deploy Tyk gateway, but it is not meant for long term storage of data.
helm install redis tyk-helm/simple-redis -n tyk
The Tyk Helm Chart can connect to simple-redis in the same namespace by default. You do not need to set Redis address and password in values.yaml.

​
Protect Confidential Fields with Kubernetes Secrets

In the values.yaml file, some fields are considered confidential, such as APISecret, connection strings, etc. Declaring values for such fields as plain text might not be desired for all use cases. Instead, for certain fields, Kubernetes secrets can be referenced and the chart will define container environment variables using Secret data. This section describes how to use Kubernetes secrets to declare confidential fields. APISecret The global.secrets.APISecret field configures a header value used in every interaction with Tyk Gateway API. It can be configured via global.secrets.APISecret as a plain text or Kubernetes secret which includes APISecret key in it. Then, this secret must be referenced via global.secrets.useSecretName. 
global:
    secrets:
        APISecret: CHANGEME
        useSecretName: "mysecret" # where mysecret includes `APISecret` key with the desired value.
Redis Password Redis password can also be provided via a secret. Store Redis password in Kubernetes secret and refer to this secret via global.redis.passSecret.name and global.redis.passSecret.keyName field, as follows: 
global:  
  redis:
     passSecret:
       name: "yourSecret"
       keyName: "redisPassKey"
Tyk Operator License It can be configured via global.license.operator as a plain text or Kubernetes secret which includes OperatorLicense key in it. Then, this secret must be referenced via global.secrets.useSecretName. Note: If you are using global.secrets.useSecretName, you must configure the operator license in the referenced Kubernetes secret. global.license.operator will not be used in this case.

​
Create a Kubernetes Secret for Tyk Operator

When operatorSecret.enabled is set to true, tyk-oss chart will create a Kubernetes Secret named tyk-operator-conf in the same namespace. It can be used by Tyk Operator to connect to Gateway to manage Tyk API resources. 
# operatorSecret controls if a secret needed to connect to Operator will be created
operatorSecret:
  # enabled if set to true creates secret
  enabled: true
  # OSS doesn't have concept of OrgID. But we need to support some features (eg. basic auth key) in OSS
  # You can set it to any arbitary value
  orgID: "orgid"

​
Gateway Configurations

Configure below inside tyk-gateway section.

​
Update Tyk Gateway Version

Set version of gateway at tyk-gateway.gateway.image.tag. You can find the list of version tags available from Docker hub. Please check Tyk Release notes carefully while upgrading or downgrading.

​
Enabling TLS

Enable TLS We have provided an easy way to enable TLS via the global.tls.gateway flag. Setting this value to true will automatically enable TLS using the certificate provided under tyk-gateway/certs/. Configure TLS secret If you want to use your own key/cert pair, please follow the following steps:
  1. Create a TLS secret using your cert and key pair.
  2. Set global.tls.gateway to true.
  3. Set tyk-gateway.gateway.tls.useDefaultTykCertificate to false.
  4. Set tyk-gateway.gateway.tls.secretName to the name of the newly created secret.
Add Custom Certificates To add your custom Certificate Authority(CA) to your containers, you can mount your CA certificate directly into /etc/ssl/certs folder. 
   extraVolumes: 
     - name: self-signed-ca
       secret:
         secretName: self-signed-ca-secret
   extraVolumeMounts: 
     - name: self-signed-ca
       mountPath: "/etc/ssl/certs/myCA.pem"
       subPath: myCA.pem

​
Enabling gateway autoscaling

You can enable autoscaling of the gateway by --set tyk-gateway.gateway.autoscaling.enabled=true. By default, it will enable the Horizontal Pod Autoscaler resource with target average CPU utilization at 60%, scaling between 1 and 3 instances. To customize those values you can modify the tyk-gateway section of values.yaml, as shown below: 
tyk-gateway:
  gateway:
    autoscaling:
      enabled: true
      minReplicas: 3
      maxReplicas: 30
Built-in rules include tyk-gateway.gateway.autoscaling.averageCpuUtilization for CPU utilization (set by default at 60%) and tyk-gateway.gateway.autoscaling.averageMemoryUtilization for memory (disabled by default). In addition to that you can define rules for custom metrics using tyk-gateway.gateway.autoscaling.autoscalingTemplate list: 
tyk-gateway:
  gateway:
    autoscaling:
      autoscalingTemplate:
        - type: Pods
          pods:
            metric:
              name: nginx_ingress_controller_nginx_process_requests_total
            target:
              type: AverageValue
              averageValue: 10000m

​
Accessing Gateway

Service port Default service port of gateway is 8080. You can change this at global.servicePorts.gateway. Ingress An Ingress resource is created if tyk-gateway.gateway.ingress.enabled is set to true. 
tyk-gateway:
  gateway:
    ingress:
      # if enabled, creates an ingress resource for the gateway
      enabled: true

      # specify ingress controller class name
      className: ""

      # annotations for ingress
      annotations: {}

      # ingress rules
      hosts:
        - host: tyk-gw.local
          paths:
            - path: /
              pathType: ImplementationSpecific

      # tls configuration for ingress
      #  - secretName: chart-example-tls
      #    hosts:
      #      - chart-example.local
      tls: []
Control Port Set tyk-gateway.gateway.control.enabled to true will allow you to run the Gateway API on a separate port and protect it behind a firewall if needed.

​
Mounting APIs, Policies, and Middleware

By default, the Gateway stores API configurations at /mnt/tyk-gateway/apps inside the Gateway container. There are a a few challenges:
  • Multiple gateways do not share app configs
  • The configuration is not persistent. i.e. it will not be retained whenever a pod restarts.
The same applies to security policies and middleware too, which are stored at /mnt/tyk-gateway/policies and /mnt/tyk-gateway/middleware respectively. This can be solved by instantiating a Persistent Volume as shared storage for the gateway instances. As each gateway is reloaded, they would get the API configurations from the same storage, solving the synchronisation issue between gateways. Also, the storage is persistent and can be designed to be resilient to cluster failure, thus your API configurations can be maintained after pod restart. You can configure persistent volume for APIs, Policies, and middleware using extraVolumes and extraVolumeMounts: 
    extraVolumes:
    - name: tyk-app-storage
      persistentVolumeClaim:
        claimName: tyk-app-claim
    - name: tyk-policies-storage
      persistentVolumeClaim:
        claimName: tyk-policies-claim
    - name: tyk-middleware-storage
      persistentVolumeClaim:
        claimName: tyk-middleware-claim

    extraVolumeMounts: 
    - name: tyk-app-storage
      mountPath: /mnt/tyk-gateway/apps
    - name: tyk-policies-storage
      mountPath: /mnt/tyk-gateway/policies
    - name: tyk-middleware-storage
      mountPath: /mnt/tyk-gateway/middleware
For further details for configuring Tyk Gateway, consult the Tyk Gateway Configuration Options guide.

​
OpenTelemetry

To enable OpenTelemetry for Gateway set gateway.opentelemetry.enabled flag to true. It is disabled by default. You can also configure connection settings for it’s exporter. By default grpc exporter is enabled on localhost:4317 endpoint. To enable TLS settings for the exporter, you can set gateway.opentelemetry.tls.enabled to true.

​
Liveness and readiness probes

Gateway liveness probes can be customised via gateway.livenessProbe field. All fields from PodLivenessProbe object can be added here. If set to empty or nil, the default health check on /health will be performed. Gateway readiness probes can be customised via gateway.readinessProbe field. All fields from PodReadinessProbe object can be added here. If set to empty or nil, the default health check on /health will be performed.

​
Pump Configurations

To enable Pump, set global.components.pump to true, and configure below inside tyk-pump section.
PumpConfiguration
Prometheus Pump (Default)Add prometheus to tyk-pump.pump.backend, and add connection details for prometheus under tyk-pump.pump.prometheusPump.
Mongo PumpAdd mongo to tyk-pump.pump.backend, and add connection details for mongo under global.mongo.
SQL PumpAdd postgres to tyk-pump.pump.backend, and add connection details for postgres under global.postgres.
Uptime PumpSet tyk-pump.pump.uptimePumpBackend to 'mongo' or 'postgres'
Other PumpsAdd the required environment variables in tyk-pump.pump.extraEnvs

​
Prometheus Pump

Add prometheus to tyk-pump.pump.backend, and add connection details for Prometheus under tyk-pump.pump.prometheusPump. We also support monitoring using Prometheus Operator. All you have to do is set tyk-pump.pump.prometheusPump.prometheusOperator.enabled to true. This will create a PodMonitor resource for your Pump instance. See Configure Tyk Pump to expose analytics data to Prometheus for a step-by-step guide on setting up Prometheus Pump on Kubernetes.

​
Mongo Pump

If you are using the MongoDB pumps in the tyk-oss installation you will require MongoDB installed for that as well. To install MongoDB you can use these rather excellent charts provided by Bitnami: 
helm install tyk-mongo bitnami/mongodb --set "replicaSet.enabled=true" -n tyk --version 15.1.3
Bitnami MongoDB image is not supported on darwin/arm64 architecture.
Please make sure you are installing MongoDB versions that are supported by Tyk. Please refer to Tyk docs to get list of supported versions.
Follow notes from the installation output to get connection details and update them in the values.yaml file. Important Note regarding MongoDB: This helm chart enables the PodDisruptionBudget for MongoDB with an arbiter replica-count of 1. If you intend to perform system maintenance on the node where the MongoDB pod is running and this maintenance requires for the node to be drained, this action will be prevented due the replica count being 1. Increase the replica count in the helm chart deployment to a minimum of 2 to remedy this issue. Add the following configuration under the global section in values.yaml: 
global:
 # Set mongo connection details if you want to configure mongo pump.
 mongo:
   # The mongoURL value will allow you to set your MongoDB address.
   # Default value: mongodb://mongo.{{ .Release.Namespace }}.svc:27017/tyk_analytics
   # mongoURL: mongodb://mongo.tyk.svc:27017/tyk_analytics
   # If your MongoDB has a password you can add the username and password to the url
   # mongoURL: mongodb://root:pass@tyk-mongo-mongodb.tyk.svc:27017/tyk_analytics?authSource=admin
   mongoURL: <MongoDB address>

   # mongo-go driver is supported for Tyk 5.0.2+.
   # We recommend using the `mongo-go` driver if you are using MongoDB 4.4.x+.
   # For MongoDB versions prior to 4.4, please use the `mgo` driver.
   # Since Tyk 5.3 the default driver is mongo-go.
   driver: mongo-go

   # Enables SSL for MongoDB connection. MongoDB instance will have to support that.
   # Default value: false
   # useSSL: false

​
SQL Pump

If you are using the SQL Pumps in the tyk-oss installation you will require PostgreSQL installed for that as well. To install PostgreSQL you can use these rather excellent charts provided by Bitnami: 
helm install tyk-postgres bitnami/postgresql --set "auth.database=tyk_analytics" -n tyk --version 12.12.10
Please make sure you are installing PostgreSQL versions that are supported by Tyk. Please refer to Tyk docs to get list of supported versions.
Follow the notes from the installation output to get connection details and update them in values.yaml file. Add the following configuration under the global section in values.yaml: 
global:
  # Postgres connection string parameters.
  postgres:
    # host corresponds to the host name of postgres
    host: tyk-postgres-postgresql.tyk.svc
    # port corresponds to the port of postgres
    port: 5432
    # user corresponds to the user of postgres
    user: postgres
    # password corresponds to the password of the given postgres user in selected database
    password:
    # database corresponds to the database to be used in postgres
    database: tyk_analytics
    # sslmode corresponds to if postgres runs in sslmode (https)
    sslmode: disable
    # Connection string can also be set using a secret. Provide the name of the secret and key below.
    # connectionStringSecret:
    #   name: ""
    #   keyName: ""

​
Uptime Pump

Uptime Pump can be configured by setting tyk-pump.pump.uptimePumpBackend in values.yaml file. It supports the following values
  1. mongo: Used to set Mongo Pump for uptime analytics. Mongo Pump should be enabled.
  2. postgres: Used to set Postgres Pump for uptime analytics. Postgres Pump should be enabled.
  3. empty: Used to disable uptime analytics.

​
Other Pumps

To setup other backends for pump, refer to this document and add the required environment variables in tyk-pump.pump.extraEnvs

​
Tyk Operator Configurations

Tyk Operator is a licensed component that requires a valid key for operation. Please refer to the Tyk Operator Installation Guide for detailed information on the installation and upgrade processes. Prior to installing Tyk Operator, ensure that a valid license key is provided by setting global.license.operator field in values.yaml file. You can set license key via a Kubernetes secret using global.secrets.useSecretName field. The secret should contain a key called OperatorLicense. In order to enable installing Tyk Operator along-side Tyk OSS installation, please set global.components.operator to true. All other configurations related to Tyk Operator are available under tyk-operator section of values.yaml file.
Tyk Operator needs a cert-manager to be installed. Ensure that cert-manager is installed as described in the official documentation: Installing Tyk Operator.