Tyk Data Plane Chart

The 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.

What components are deployed with Tyk Data Plane Chart?

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.

Furthermore, it has all the required modifications to easily connect to Tyk Cloud or Multi Data Center (MDCB) control plane.

Supported MDCB versions

By default, this chart installs following components as subcharts on a Kubernetes cluster using the Helm package manager.

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 a quick start guide, please see deploy hybrid gateway.

Prerequisites

• Kubernetes 1.19+
• Helm 3+
• Redis should already be installed or accessible by the gateway.
• Connection details to remote control plane. See the section below for how to obtain them from Tyk Cloud.

Obtain your Remote Control Plane Connection Details from Tyk Cloud

You can easily obtain your remote control plane connection details on Tyk Cloud.

1. Go to Deployment tab and create a Hybrid data plane configuration. You can also select from an existing one.
2. Copy Key, Org ID, and Data Planes Connection String (MDCB) as global.remoteControlPlane’s userApiKey, orgId, and connectionString respectively.

Tyk Data Plane Chart Installations

Installing the Chart

To install the chart from the Helm repository in namespace tyk with the release name tyk-data-plane, issue the following commands:

    helm repo add tyk-helm https://helm.tyk.io/public/helm/charts/
    helm repo update
    helm show values tyk-helm/tyk-data-plane > values.yaml

For further documentation relating to helm command usage, please refer to the helm docs.

Consult the Configuration section for the available configuration options and modify your local values.yaml file accordingly. Then install the chart by issuing the following command below:

    helm install tyk-data-plane tyk-helm/tyk-data-plane -n tyk --create-namespace -f values.yaml

Uninstalling the Chart

helm uninstall tyk-data-plane -n tyk

This removes all the Kubernetes components associated with the chart and deletes the release.

Upgrading Chart

helm upgrade tyk-data-plane tyk-helm/tyk-data-plane -n tyk

Configuration

To list all configurable options with detailed comments, issue the following command:

helm show values tyk-helm/tyk-data-plane > 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:

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

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 --set global.redis.pass=$REDIS_PASSWORD.

helm install --set global.redis.passSecret.name=tyk-redis --set global.redis.passSecret.keyName=redis-password tyk-data-plane tyk-helm/tyk-data-plane

or

export REDIS_PASSWORD=$(kubectl get secret --namespace tyk tyk-redis -o jsonpath="{.data.redis-password}" | base64 --decode)

helm install --set global.redis.pass=$REDIS_PASSWORD tyk-data-plane tyk-helm/tyk-data-plane

Evaluation only: via simple-redis chart

Another option for Redis, to get started quickly, is to use our simple-redis chart.

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.

Remote Control Plane Configuration

All configurations regarding remote control plane (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.

1. Create a secret that contains orgId, userApiKey and groupID keys in it:

kubectl create secret generic foo-secret -n tyk --from-literal=orgId=[ORGID] --from-literal=userApiKey=[APIKEY]--from-literal=groupID=[GROUPID]

2. Refer to it in global.remoteControlPlane.useSecretName.

global:
  remoteControlPlane:
    useSecretName: "foo-secret"

Redis Password

The 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 MDCB Synchroniser (Optional)

If control plane MDCB has enabled Synchroniser feature, the following fields should be set accordingly:

global:
  mdcbSynchronizer:
      enabled: true
      keySpaceSyncInterval: 10

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 CA 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 utilisation at 60%, scaling between 1 and 3 instances. To customise 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.

    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"

For further details for configuring Tyk Gateway, please consult the Tyk Gateway Configuration Options guide.

Pump Configurations

To enable Pump, set global.components.pump to true, and configure as detailed below inside tyk-pump section.

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.

Hybrid Pump

Add hybrid to tyk-pump.pump.backend, and add remoteControlPlane details under global.remoteControlPlane.

  # Set remoteControlPlane connection details if you want to configure hybrid pump.
  remoteControlPlane:
      # connection string used to connect to an MDCB deployment. For Tyk Cloud users, you can get it from Tyk Cloud Console and retrieve the MDCB connection string.
      connectionString: ""
      # orgID of your dashboard user
      orgId: ""
      # API key of your dashboard user
      userApiKey: ""
      # needed in case you want to have multiple data-planes connected to the same redis instance
      groupID: ""
      # enable/disable ssl
      useSSL: true
      # Disables SSL certificate verification
      sslInsecureSkipVerify: true

  # hybridPump configures Tyk Pump to forward Tyk metrics to a Tyk Control Plane.
  # Please add "hybrid" to .Values.pump.backend in order to enable Hybrid Pump.
  hybridPump: 
    # Specify the frequency of the aggregation in minutes or simply turn it on by setting it to true
    enableAggregateAnalytics: true
    # Hybrid pump RPC calls timeout in seconds.
    callTimeout: 10
    # Hybrid pump connection pool size.
    poolSize: 5

Other Pumps

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