tyk-data-plane
chart provides the default deployment of a Tyk data plane for Tyk Self Managed MDCB or Tyk Cloud users. It will deploy the data plane components that remotely connect to a MDCB control plane.
Component | Enabled by Default? | Flag |
---|---|---|
Tyk Gateway | true | n/a |
Tyk Pump | true | global.components.pump |
image.tag
. You can find the list of version tags available from Docker hub.
For a quick start guide, please see deploy hybrid gateway.
global.remoteControlPlane
’s userApiKey
, orgId
, and connectionString
respectively.global.remoteControlPlane
’s userApiKey
, orgId
, and connectionString
respectively.
tyk-dp
with the release name tyk-data-plane
, issue the following commands:
values.yaml
file accordingly. Then install the chart by issuing the following command below:
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.
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:
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.
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 |
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 --set global.redis.pass=$REDIS_PASSWORD
.
simple-redis
in the same namespace by default. You do not need to set Redis address and password in values.yaml
.
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
.
orgId
, userApiKey
, and groupID
) can be set via
Kubernetes secret.
Instead of explicitly setting them in the values file, just create a Kubernetes secret including orgId
, userApiKey
and groupID
keys and refer to it in global.remoteControlPlane.useSecretName
.
orgId
, userApiKey
and groupID
keys in it:global.remoteControlPlane.useSecretName
.global.redis.passSecret.name
and global.redis.passSecret.keyName
field, as follows:
tyk-gateway
section.
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.
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:
global.tls.gateway
to true.tyk-gateway.gateway.tls.useDefaultTykCertificate
to false.tyk-gateway.gateway.tls.secretName
to the name of the newly created secret.--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.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:
global.servicePorts.gateway
.
Ingress
An Ingress resource is created if tyk-gateway.gateway.ingress.enabled
is set to true.
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.
tyk-gateway.gateway.sharding.enabled
, and set tags
to comma separated lists of matching tags.
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.
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.
For further details for configuring Tyk Gateway, please consult the Tyk Gateway Configuration Options guide.
global.components.pump
to true, and configure as detailed 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 . |
Hybrid Pump (Default) | Add hybrid to tyk-pump.pump.backend , and add remoteControlPlane details under global.remoteControlPlane . |
Other Pumps | Add the required environment variables in tyk-pump.pump.extraEnvs |
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.
hybrid
to tyk-pump.pump.backend
, and add remoteControlPlane details under global.remoteControlPlane
.
tyk-pump.pump.extraEnvs