Tyk Stack Chart
Last updated: 22 minutes read.
The tyk-stack
chart provides the default deployment of Tyk Self Managed on a Kubernetes cluster. It will deploy all required Tyk components with the settings provided in the values.yaml file.
What components are deployed with Tyk Stack Chart?
It includes:
- 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 nodes to any back-end. Furthermore, it has all the required modifications to easily connect to Tyk Cloud or Multi Data Center (MDCB) control plane.
- Tyk Dashboard, a license based component that provides a graphical management interface and analytics platform for Tyk.
- Tyk Developer Portal, a full-fledged CMS-like system for API providers to publish, monetize and drive the adoption of APIs.
By default, this chart installs the following components as sub-charts on a Kubernetes cluster using the Helm package manager.
Component | Enabled by Default | Flag |
---|---|---|
Tyk Gateway | true | n/a |
Tyk Dashboard | true | n/a |
Tyk Pump | false | global.components.pump |
Tyk Enterprise Developer Portal | false | global.components.devPortal |
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 can find the list of version tags available from Docker hub.
For quick start guide, please see Quick Start with Helm Chart and PostgreSQL or Quick Start with Helm Chart and MongoDB.
Prerequisites
- Kubernetes 1.19+
- Helm 3+
- Redis should already be installed or accessible by the gateway and dashboard.
- MongoDB or PostgreSQL should already be installed or accessible by dashboard. Please consult the list of supported versions that are compatible with Tyk.
Note
If you want to enable Tyk Developer Portal, please use PostgreSQL. MongoDB is not supported in Developer Portal.
Tyk Stack Installations
Installing The Chart
To install the chart from Helm repository in namespace tyk
with the release name tyk-stack
:
helm repo add tyk-helm https://helm.tyk.io/public/helm/charts/
helm repo update
helm show values tyk-helm/tyk-stack > values.yaml
For further documentation relating to helm command usage, please refer to the helm docs.
At a minimum, modify values.yaml for the following settings:
If you would like to use Developer Portal, an additional license is required:
Then just run:
helm install tyk-stack tyk-helm/tyk-stack -n tyk --create-namespace -f values.yaml
Uninstalling The Chart
helm uninstall tyk-stack -n tyk
This removes all the Kubernetes components associated with the chart and deletes the release.
Upgrading Chart
helm upgrade tyk-stack tyk-helm/tyk-stack -n tyk -f values.yaml
Configuration
To list all configurable options with detailed comments:
helm show values tyk-helm/tyk-stack > 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. See Using Helm for examples.
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:
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. 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
Note
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.
Warning
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
.
Set Mongo or PostgresSQL Connection Details (Required)
If you have already installed MongoDB or PostgreSQL, you can set the connection details in the global.mongo
and global.postgres
sections of the values.yaml file respectively.
If not, you can use these rather excellent charts provided by Bitnami to install MongoDB or PostgreSQL:
Mongo Installation
helm install tyk-mongo bitnami/mongodb --set "replicaSet.enabled=true" -n tyk --version 15.1.3
Note
Bitnami MongoDB image is not supported on darwin/arm64 architecture.
Then follow notes from the installation output to get connection details and update them in values.yaml
file.
Note
Please make sure you are installing MongoDB versions that are supported by Tyk. Please refer to Tyk docs to get list of supported versions.
Note
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 the node to be drained, then this action will be prevented due to the the replica count being 1.
Increase the replica count in the helm chart deployment to a minimum of 2 to remedy this issue.
Configure global.mongo.mongoURL
and global.storageType
as below. You should replace password in the connection string with the MONGODB_ROOT_PASSWORD you obtain from the installation output notes.
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:[email protected]:27017/tyk_analytics?authSource=admin
# 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
# Connection URL can also be set using a secret. Provide the name of the secret and key below.
# connectionURLSecret:
# name: ""
# keyName: ""
# Enables SSL for MongoDB connection. MongoDB instance will have to support that.
# Default value: false
useSSL: false
# Choose the storageType for Tyk. [ "mongo", "postgres" ]
storageType: &globalStorageType mongo
PostgresSQL Installation
helm install tyk-postgres bitnami/postgresql --set "auth.database=tyk_analytics" -n tyk --version 12.12.10
Follow the notes from the installation output to get connection details.
Note
Please make sure you are installing PostgreSQL versions that are supported by Tyk. Please refer to Tyk docs to get list of supported versions.
global:
# PostgreSQL connection string parameters.
postgres:
# host corresponds to the host name of postgreSQL
host: tyk-postgres-postgresql.tyk.svc
# port corresponds to the port of postgreSQL
port: 5432
# user corresponds to the user of postgreSQL
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 postgreSQL
database: tyk_analytics
# sslmode corresponds to if postgreSQL 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: ""
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. 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.
Tyk Dashboard and Developer Portal Admin
If Tyk Dashboard bootstrapping is enabled, the admin user will be created according to the global.adminUser
field.
All admin credentials can also be set through Kubernetes secret.
Note
Once global.adminUser.useSecretName
is declared, it takes precedence over global.adminUser.firstName
,
global.adminUser.lastName
, global.adminUser.email
and global.adminUser.password
.
If global.adminUser.useSecretName
is in use, please add all keys mentioned below to the secret.
Tyk Dashboard Admin First Name
It can be configured via global.adminUser.firstName
as a plain text or Kubernetes secret which includes adminUserFirstName
key in it. Then, this secret must be referenced via global.adminUser.useSecretName
.
Tyk Dashboard Admin Last Name
It can be configured via global.adminUser.lastName
as a plain text or Kubernetes secret which includes adminUserLastName
key in it. Then, this secret must be referenced via global.adminUser.useSecretName
.
Tyk Dashboard and Developer Portal Admin Email
It can be configured via global.adminUser.email
as a plain text or Kubernetes secret which includes adminUserEmail
key in it. Then, this secret must be referenced via global.adminUser.useSecretName
.
Tyk Dashboard and Developer Portal Admin Password
It can be configured via global.adminUser.password
as a plain text or Kubernetes secret which includes adminUserPassword
key in it. Then, this secret must be referenced via global.adminUser.useSecretName
.
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.
AdminSecret
The global.secrets.AdminSecret
field sets a secret for Admin API.
It can be configured via global.secrets.AdminSecret
as a plain text or Kubernetes secret which includes AdminSecret
key in it. Then, this secret must be referenced via global.secrets.useSecretName
.
global:
secrets:
useSecretName: "mysecret" # where mysecret includes `AdminSecret` key with the desired value.
Note
Once global.secrets.useSecretName
is declared, it takes precedence over global.secrets.APISecret
and global.secrets.AdminSecret
.
Dashboard License
In order to refer Tyk Dashboard license using a Kubernetes secret, please use global.secrets.useSecretName
, where the secret should contain a key called DashLicense
.
Tyk Developer Portal License
In order to refer Tyk Developer Portal license using a Kubernetes secret, please use
tyk-dev-portal.useSecretName
, where the secret should contain a key called DevPortalLicense
.
Tyk Developer Portal Admin Password
In order to refer Tyk Developer Portal’s admin password using a Kubernetes secret,
please use global.adminUser.useSecretName
, where the secret should contain a key called adminUserPassword
.
Tyk Developer Portal Storage Connection String
In order to refer Tyk Developer Portal connection string to the selected database using a Kubernetes secret, please use tyk-dev-portal.useSecretName
, where the secret should contain a key called
DevPortalStorageConnectionString
.
Note
If tyk-dev-portal.useSecretName
is in use, please add all keys mentioned to the secret.
Tyk Developer Portal AWS S3 Access Key ID
In order to refer to the Tyk Developer Portal AWS S3 Access Key ID using a Kubernetes secret, please use tyk-dev-portal.useSecretName
, where the secret should contain a key called DevPortalAwsAccessKeyId
.
Note
If tyk-dev-portal.useSecretName
is in use, please add all keys mentioned to the secret.
Tyk Developer Portal AWS S3 Secret Access Key
In order to refer Tyk Developer Portal connection string to the selected database through Kubernetes secret,
please use tyk-dev-portal.useSecretName
, where the secret should contain a key called
DevPortalAwsSecretAccessKey
.
Note
If tyk-dev-portal.useSecretName
is in use, please add all keys mentioned to the secret.
Redis Password
Redis password can also be provided via a secret. Store the Redis password in a Kubernetes secret and refer to this secret as follows:
global:
redis:
passSecret:
name: "yourSecret"
keyName: "redisPassKey"
MongoDB or PostgreSQL connection strings
Storage connection strings can also be provided via a secret. Store the connection string in Kubernetes secret and refer to this secret via global.{mongo,postgres}.connectionURLSecret.name
and global.{mongo,postgres}.connectionURLSecret.keyName
field, as follows:
- MongoDB:
global:
mongo:
connectionURLSecret:
name: "yourSecret"
keyName: "mongoConnectionURLkey"
- PostgreSQL:
global:
postgres:
connectionStringSecret:
name: "yourSecret"
keyName: "postgreConnectionURLkey"
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
.
Gateway Configurations
This section explains how to configure the tyk-gateway
section for updating the Gateway version, enabling TLS, enabling autoscaling etc.
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:
- Create a TLS secret using your cert and key pair.
- Set
global.tls.gateway
to true. - Set
tyk-gateway.gateway.tls.useDefaultTykCertificate
to false. - 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 the values.yaml
file 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.
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.
Sharding
Configure the gateways to load APIs with specific tags only by enabling tyk-gateway.gateway.sharding.enabled
, and set tags
to comma separated lists of matching tags.
# Sharding gateway allows you to selectively load APIs to specific gateways.
# If enabled make sure you have at least one gateway that is not sharded.
# Also be sure to match API segmentation tags with the tags selected below.
sharding:
enabled: true
tags: "edge,dc1,product"
Deploy additional gateway groups
The tyk-stack
chart manages one Gateway deployment in the same namespace as Tyk Dashboard. You can flexibly deploy additional gateways using tyk-gateway
component chart. With gateway sharding, it is useful for:
- Deploying Gateways in different networks,
- Deploying Gateways with different resources and autoscaling parameters,
- Allow different teams to manage their own Gateway instances in their own namespace.
Here is an example configuration for tyk-gateway
values.yaml
.
global:
redis:
addrs:
- tyk-redis-master.tyk-stack.svc:6379 # New Gateway groups should connect to the same Redis
pass: "xxxxxxx"
gateway:
# If this option is set to true, it will enable polling the Tyk Dashboard service for API definitions
useDashboardAppConfig:
enabled: true
# Set it to the URL to your Dashboard instance (or a load balanced instance)
# The URL needs to be formatted as: http://dashboard_host:port
# It is used to set TYK_GW_DBAPPCONFOPTIONS_CONNECTIONSTRING
dashboardConnectionString: "http://dashboard-svc-tyk-tyk-dashboard.tyk-stack.svc:3000"
# This option is required if Policy source is set to Tyk Dashboard (`service`).
# Set this to the URL of your Tyk Dashboard installation.
# The URL needs to be formatted as: http://dashboard_host:port.
# It is used to set TYK_GW_POLICIES_POLICYCONNECTIONSTRING
policyConnectionString: "http://dashboard-svc-tyk-tyk-dashboard.tyk-stack.svc:3000"
...
# Sharding gateway allows you to selectively load APIs to specific gateways.
# If enabled make sure you have at least one gateway that is not sharded.
# Also be sure to match API segmentation tags with the tags selected below.
sharding:
enabled: true
tags: "gw-dmz"
...
# analyticsEnabled property is used to enable/disable analytics.
# If set to empty or nil, analytics will be enabled/disabled based on `global.components.pump`.
analyticsEnabled: "true"
# used to decide whether to send the results back directly to Tyk without a hybrid pump
# if you want to send analytics to control plane instead of pump, change analyticsConfigType to "rpc"
analyticsConfigType: ""
Run the following command to deploy additional Gateways in namespace another-namespace
.
helm install another-gateway tyk-helm/tyk-gateway --namespace another-namespace -f values.yaml
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.
Pump Configurations
To enable Pump, set global.components.pump
to true, and configure below inside tyk-pump
section.
Pump | Configuration |
---|---|
Prometheus Pump (Default) | Add the value prometheus to the tyk-pump.pump.backend entry, 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 . |
Mongo Selective Pump | Add mongo-selective to tyk-pump.pump.backend , and add connection details for mongo under global.mongo . |
Mongo Aggregate Pump | Add mongo-aggregate to tyk-pump.pump.backend , and add connection details for mongo under global.mongo . |
Postgres Pump | Add postgres to tyk-pump.pump.backend , and add connection details for postgres under global.postgres . |
Postgres Aggregate Pump | Add postgres-aggregate 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 or "" |
Other Pumps | Add the required environment variables in tyk-pump.pump.extraEnvs |
Note
For additional information on Tyk Pump configurations, refer to the Setup Dashboard Analytics documentation.
To explore the list of supported backends for Tyk Pump, please visit Pump Backends.
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.
# prometheusPump configures Tyk Pump to expose Prometheus metrics.
# Please add "prometheus" to .Values.pump.backend in order to enable Prometheus Pump.
prometheusPump:
# host represents the host without port, where Tyk Pump serve the metrics for Prometheus.
host: ""
# port represents the port where Tyk Pump serve the metrics for Prometheus.
port: 9090
# path represents the path to the Prometheus collection. For example /metrics.
path: /metrics
# customMetrics allows defining custom Prometheus metrics for Tyk Pump.
# It accepts a string that represents a JSON object. For instance,
#
# customMetrics: '[{"name":"tyk_http_requests_total","description":"Total of API requests","metric_type":"counter","labels":["response_code","api_name","method","api_key","alias","path"]}, { "name":"tyk_http_latency", "description":"Latency of API requests", "metric_type":"histogram", "labels":["type","response_code","api_name","method","api_key","alias","path"] }]'
customMetrics: ""
# If you are using prometheus Operator, set the fields in the section below.
prometheusOperator:
# enabled determines whether the Prometheus Operator is in use or not. By default,
# it is disabled.
# Tyk Pump can be monitored with PodMonitor Custom Resource of Prometheus Operator.
# If enabled, PodMonitor resource is created based on .Values.pump.prometheusPump.prometheusOperator.podMonitorSelector
# for Tyk Pump.
enabled: false
# podMonitorSelector represents a podMonitorSelector of your Prometheus resource. So that
# your Prometheus resource can select PodMonitor objects based on selector defined here.
# Please set this field to the podMonitorSelector field of your monitoring.coreos.com/v1
# Prometheus resource's spec.
#
# You can check the podMonitorSelector via:
# kubectl describe prometheuses.monitoring.coreos.com <PROMETHEUS_POD>
podMonitorSelector:
release: prometheus-stack
Mongo pump
To enable Mongo pump, add mongo
to tyk-pump.pump.backend
, and add connection details for mongo under global.mongo
. See Mongo Installation section above.
By default, it will enable Mongo Aggregate, Mongo Graph Pump and Mongo Selective Pump.
SQL pump
To enable SQL pump, add postgres
to tyk-pump.pump.backend
, and add connection details for postgres under global.postgres
. See PostgresSQL Installation section above.
By default, it will enable Postgres Aggregate, Postgres Graph Aggregate, SQL Pump and SQL graph pump.
Uptime Pump
Uptime Pump can be configured by setting pump.uptimePumpBackend
in values.yaml file. It supports the following values
- mongo: Used to set Mongo Pump for uptime analytics. Mongo Pump should be enabled.
- postgres: Used to set Postgres Pump for uptime analytics. Postgres Pump should be enabled.
- empty: Used to disable uptime analytics.
# uptimePumpBackend configures uptime Tyk Pump. ["", "mongo", "postgres"].
# Set it to "" for disabling uptime Tyk Pump. By default, uptime pump is disabled.
uptimePumpBackend: ""
Other Pumps
To setup other backends for pump, refer to this document and add the required environment variables in pump.extraEnvs
Tyk Dashboard Configurations
Tyk Dashboard License (Required)
Tyk Dashboard License is required. It can be set up in global.license.dashboard
or through secret global.secrets.useSecretName
. The secret should contain a key called DashLicense.
global:
license:
# The license key needed by Tyk Dashboard to work.
#
# NOTE: If you do not want to store license as a plain text in the file, you can use a Kubernetes secret
# that stores the dashboard license. Please see `.global.secrets.useSecretName`.
dashboard: ""
Enabling Dashboard TLS
Assuming that TLS certificates for the Tyk Dashboard are available in the Kubernetes Secret tyk-dashboard-tls
,
follow these steps to enable TLS:
- Set
global.tls.dashboard
totrue
. - Set
tyk-dashboard.dashboard.tls.secretName
to the name of the Kubernetes secret containing TLS certificates for the Tyk Dashboard, in this case,tyk-dashboard-tls
. - Define certificate configurations in
tyk-dashboard.dashboard.tls.certificates
, which generatesTYK_DB_HTTPSERVEROPTIONS_CERTIFICATES
for the Tyk Dashboard.
Optional Steps, if needed:
- Modify the secret mount path on the Tyk Dashboard Pod via
tyk-dashboard.dashboard.tls.certificatesMountPath
. - If necessary, either enable
insecureSkipVerify
viatyk-dashboard.dashboard.tls.certificates
, or mount CA information throughtyk-dashboard.dashboard.extraVolumes
andtyk-dashboard.dashboard.extraVolumeMounts
. - If the
tyk-bootstrap
chart is used to bootstrap the Tyk Dashboard, ensure that it has certificates to send requests to the Tyk Dashboard or enableinsecureSkipVerify
in thetyk-bootstrap
chart. - If the Tyk Gateway connects to the Tyk Dashboard, confirm that the Tyk Gateway has appropriate certificates for connecting to the Tyk Dashboard
Tyk Bootstrap Configurations
To enable bootstrapping, set global.components.bootstrap
to true
. It would run tyk-k8s-bootstrap to bootstrap tyk-stack
and to create Kubernetes secrets that can be utilized in Tyk Operator and Tyk Developer Portal.
Note
During bootstrapping, admin user needs to reset its password. It may be denied by Dashboard OPA rules if OPA was enabled. Please disable OPA during the initial bootstrapping or set Dashboard configuration TYK_DB_SECURITY_ALLOWADMINRESETPASSWORD to true.
Bootstrapped Environments
If Tyk is already bootstrapped, the application will bypass the creation of the Tyk Organization and Admin User, proceeding directly with the creation of Kubernetes Secrets.
Given that the Kubernetes Secrets require values for TYK_AUTH
and TYK_ORG
, it is essential to provide these values through the respective environment variables, called TYK_K8SBOOTSTRAP_TYK_ADMIN_AUTH
for TYK_AUTH
and TYK_K8SBOOTSTRAP_TYK_ORG_ID
for TYK_ORG
.
Ensure that these environment variables are set appropriately to postInstall
hook for bootstrapped environments.
Tyk Developer Portal Configurations
To enable Tyk Developer Portal, set global.components.devPortal
to true, and configure below inside tyk-dev-portal
section.
Tyk Developer Portal License (Required)
Tyk Developer Portal License is required. It can be set up in tyk-dev-portal.license
or through secret global.secrets.useSecretName
. The secret should contain a key called DevPortalLicense
.
tyk-dev-portal:
# Tyk Developer Portal license.
license: ""
Tyk Developer Portal Database
Note
SQLite support will be deprecated from Tyk 5.7.0. To avoid disrupution, please transition to PostgreSQL, MongoDB or one of the listed compatible alternatives.
By default, Tyk Developer Portal use sqlite3
to store portal metadata. If you want to use other SQL Database, please modify the section below.
tyk-dev-portal:
database:
# This selects the SQL dialect to be used
# The supported values are mysql, postgres and sqlite3
dialect: "sqlite3"
connectionString: "db/portal.db"
enableLogs: false
maxRetries: 3
retryDelay: 5000
Storage Settings
Tyk Developer Portal supports different storage options for storing the portal’s CMS assets such as images, theme files and Open API Specification files. Please see the Developer Portal storage settings page for all the available options.
If you use the file system as storage, please set tyk-dev-portal.storage.type
to fs
, and configure tyk-dev-portal.storage.persistence
to mount an existing persistent volume to Tyk Developer Portal.
If you use AWS S3 as storage, please set tyk-dev-portal.storage.type
to s3
, and configure tyk-dev-portal.storage.s3
section with credentials to access AWS S3 bucket.
If you use database as storage, please set tyk-dev-portal.storage.type
to db
, and configure the tyk-dev-portal.database
section with database connection details.
tyk-dev-portal:
# Sensitive configuration of Portal could be set using k8s secret
# You can set following fields:
# - DevPortalLicense - Sets LicenseKey for Developer Portal
# - DevPortalStorageConnectionString - Sets connectionString for Developer Portal
# - DevPortalAwsAccessKeyId - Sets AWS S3 Access Key ID
# - DevPortalAwsSecretAccessKey - Sets AWS S3 Secret Access Key
useSecretName: ""
# The hostname to bind the Developer Portal to.
hostName: tyk-dev-portal.org
# Developer Portal license.
license: ""
# Developer portal can be deployed as StatefulSet or as Deployment
kind: StatefulSet
storage:
# User can set the storage type for portal.
# Supported types: fs, s3, db
type: "db"
# Configuration values for using s3 as storage for Tyk Developer Portal
# In case you want to provide the key ID and access key via secrets please
# refer to the existing secret inside the helm chart or the
# .Values.useSecretName field
s3:
awsAccessKeyid: your-access-key
awsSecretAccessKey: your-secret-key
region: sa-east-1
endpoint: https://s3.sa-east-1.amazonaws.com
bucket: your-portal-bucket
acl: private
presign_urls: true
persistence:
mountExistingPVC: ""
storageClass: ""
accessModes:
- ReadWriteOnce
size: 8Gi
annotations: {}
labels: {}
selector: {}
database:
# This selects the SQL dialect to be used
# The supported values are mysql, postgres and sqlite3
dialect: "sqlite3"
connectionString: "db/portal.db"
enableLogs: false
maxRetries: 3
retryDelay: 5000
Other Configurations
Other Developer Portal configurations can be set by using environment variables with extraEnvs
fields, e.g.:
tyk-dev-portal:
extraEnvs:
- name: PORTAL_LOG_LEVEL
value: debug
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 Stack 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.