> ## Documentation Index > Fetch the complete documentation index at: https://tyk.io/docs/llms.txt > Use this file to discover all available pages before exploring further. # Tyk Open Source Chart > Explains the Tyk Open Source Chart `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](https://kubernetes.io/) cluster using the [Helm](https://helm.sh/) package manager. | Component | Enabled by Default | Flag | | :----------- | :----------------- | :------------------------- | | Tyk Gateway | true | n/a | | Tyk Pump | false | global.components.pump | | Tyk Operator | false | global.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](https://hub.docker.com/u/tykio). For quick start guide, please see [Quick Start with Tyk OSS Helm Chart](/5.9/apim/open-source/installation#quick-start-with-helm-chart). ## Prerequisites * [Kubernetes 1.19+](https://kubernetes.io/docs/setup/) * [Helm 3+](https://helm.sh/docs/intro/install/) * [Redis](/5.9/tyk-configuration-reference/redis-cluster-sentinel) should already be installed or accessible by the gateway. ## 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: ```bash theme={null} 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](https://helm.sh/docs/helm/). See [Configuration](/5.9/#configuration) section for the available config options and modify your local `values.yaml` file accordingly. Then install the chart: ```bash theme={null} helm install tyk-oss tyk-helm/tyk-oss -n tyk --create-namespace -f values.yaml ``` ### Uninstalling the Chart ```bash theme={null} helm uninstall tyk-oss -n tyk ``` This removes all the Kubernetes components associated with the chart and deletes the release. ### Upgrading Chart ```bash theme={null} helm upgrade tyk-oss tyk-helm/tyk-oss -n tyk -f values.yaml ``` ## Configuration To list all configurable options with detailed comments: ```bash theme={null} 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](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/). 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](https://helm.sh/docs/chart_best_practices/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](/5.9/tyk-oss-gateway/configuration). ### 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: ```yaml theme={null} tyk-gateway: gateway: extraEnvs: - name: TYK_GW_LOGLEVEL value: debug ``` An example is listed below for setting extra [environment variable using ConfigMap data](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#define-container-environment-variables-using-configmap-data), using gateway: ```yaml theme={null} 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](https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/#define-container-environment-variables-using-secret-data), using gateway: ```yaml theme={null} 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](/5.9/tyk-configuration-reference/kv-store). ### Set Redis Connection Details (Required) Tyk uses Redis for distributed rate-limiting and token storage. You may use the [Bitnami chart](https://github.com/bitnami/charts/tree/main/bitnami/redis) to install or Tyk's `simple-redis` chart for POC purpose. Set the following values after installing Redis: | Name | Description | | :-------------------------------- | :-------------------------------------------------------------------------------------------------- | | `global.redis.addrs` | Redis addresses | | `global.redis.pass` | Redis password in plain text | | `global.redis.passSecret.name` | If global.redis.pass is not provided, you can store it in a secret and provide the secret name here | | `global.redis.passSecret.keyName` | key name to retrieve Redis password from the secret | ***Recommended: via *Bitnami* chart*** For Redis you can use these rather excellent charts provided by [Bitnami](https://github.com/bitnami/charts/tree/main/bitnami/redis). Copy the following commands to add it: ```bash theme={null} 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](/5.9/tyk-self-managed/install#redis). 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](https://artifacthub.io/packages/helm/tyk-helm/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](https://github.com/bitnami/charts/tree/main/bitnami/redis) or [Official Redis installation guides](https://redis.io/docs/install/) 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. ```bash theme={null} 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](https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/#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](/5.9/tyk-oss-gateway/configuration#secret) 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`. ```yaml theme={null} 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: ```yaml theme={null} 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. ```yaml theme={null} # 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](https://hub.docker.com/u/tykio). Please check [Tyk Release notes](/5.9/developer-support/release-notes/gateway) 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. ```yaml theme={null} 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: ```yaml theme={null} 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: ```yaml theme={null} 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. ```yaml theme={null} 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](/5.9/tyk-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`: ```yaml theme={null} 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](/5.9/tyk-oss-gateway/configuration) 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. | Pump | Configuration | | :------------------------ | :--------------------------------------------------------------------------------------------------------------------------- | | Prometheus Pump (Default) | Add `prometheus` to `tyk-pump.pump.backend`, and add connection details for prometheus under `tyk-pump.pump.prometheusPump`. | | Mongo Pump | Add `mongo` to `tyk-pump.pump.backend`, and add connection details for mongo under `global.mongo`. | | SQL Pump | Add `postgres` to `tyk-pump.pump.backend`, and add connection details for postgres under `global.postgres`. | | Uptime Pump | Set `tyk-pump.pump.uptimePumpBackend` to `'mongo'` or `'postgres'` | | Other Pumps | Add 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](/5.9/api-management/tyk-pump#setup-prometheus-pump) 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: ```bash theme={null} 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](/5.9/api-management/dashboard-configuration#supported-database). 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`: ```yaml theme={null} 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: # 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: ```bash theme={null} 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](/5.9/api-management/dashboard-configuration#supported-database). 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`: ```yaml theme={null} 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](https://github.com/TykTechnologies/tyk-pump/blob/master/README.md#pumps--back-ends-supported) 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](/5.9/tyk-stack/tyk-operator/installing-tyk-operator) 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](/5.9/tyk-stack/tyk-operator/installing-tyk-operator).