Skip to content

Latest commit

 

History

History
 
 

tyk-single-dc

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Tyk single dc

tyk-single-dc provides the default deployment of Tyk Pro on single data center. It will deploy all required Tyk components with the settings provided in the values.yaml file.

It includes:

  • the 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 GUI management interface and analytics platform for Tyk

Introduction

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

Component Enabled by Default Flag
Tyk Gateway true n/a
Tyk Pump true global.components.pump
Tyk Dashboard true global.components.dashboard

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.

Prerequisites

Installing the Chart

To install the chart from Git repository in namespace tyk with the release name tyk-single-dc:

helm repo add tyk-helm https://helm.tyk.io/public/helm/charts/
helm repo update
helm show values tyk-helm/tyk-single-dc > values-single-dc.yaml --devel

*If you use the Bitnami chart for Redis installation, the DNS name of your Redis as set by Bitnami is tyk-redis-master.tyk.svc.cluster.local:6379.

You can update them in your local values-single-dc.yaml file under global.redis.addr and global.redis.pass.

Alternatively, you can use --set flag to set it in Tyk installation. For example --set global.redis.pass=$REDIS_PASSWORD

*All the values above are just examples, please input the values specific for your deployment.

Then just run:

helm install tyk-single-dc tyk-helm/tyk-single-dc -n tyk --create-namespace -f values-single-dc.yaml --devel

Uninstalling the Chart

helm uninstall tyk-single-dc -n tyk

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

Upgrading Chart

helm upgrade tyk-single-dc tyk-helm/tyk-single-dc -n tyk --devel

Configuration

To get all configurable options with detailed comments:

helm show values tyk-helm/tyk-single-dc > values-single-dc.yaml --devel

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.

Note:

  • Set redis connection details first at .Values.global.redis
  • Set mongo connection details second at .Values.global.mongo
  • If used, the Tyk Dashboard also requires a license to be set at .Values.global.license.dashboard

Set Redis connection details (Required)

Tyk uses Redis for distributed rate-limiting and token storage. You may set global.redis.addr and global.redis.pass with redis connection string and password respectively.

If you do not already have redis installed, you may use these charts provided by Bitnami

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install tyk-redis bitnami/redis -n tyk --create-namespace --set image.tag=6.2.13

Follow the notes from the installation output to get connection details and password. The DNS name of your Redis as set by Bitnami is tyk-redis-master.tyk.svc.cluster.local:6379 (Tyk needs the name including the port)

Set Mongo or PostgresSQL connection details (Required)

If you have already installed mongo/postgresSQL, you can set the connection details in global.mongo and global.postgres section of values file respectively.

If not, you can use these rather excellent charts provided by Bitnami to install mongo/postgres:

Mongo Installation

helm install tyk-mongo bitnami/mongodb --version {HELM_CHART_VERSION} --set "replicaSet.enabled=true" -n tyk

PostgresSQL Installation

helm install tyk-postgres bitnami/postgresql --set "auth.database=tyk_analytics" -n tyk

Follow the notes from the installation output to get connection details.

NOTE: Please make sure you are installing mongo/postgres versions that are supported by Tyk. Please refer to Tyk docs to get list of supported versions.

Enable gateway autoscaling

This chart allows for easy configuration of autoscaling parameters. To simply enable autoscaling it's enough to add --set tyk-gateway.gateway.autoscaling.enabled=true. That will enable Horizontal Pod Autoscaler resource with default parameters (avg. CPU load at 60%, scaling between 1 and 3 instances). To customize those values you can add --set tyk-gateway.gateway.autoscaling.averageCpuUtilization=75 or use values.yaml file:

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

Gateway Configurations

Configure below inside tyk-gateway section.

Enabling TLS

We have provided an easy way of enabling TLS via the global.tls.gateway flag. Setting this value to true will automatically enable TLS using the certificate provided under tyk-gateway/certs/cert.pem.

If you want to use your own key/cert pair, you must follow the following steps:

  1. Create a tls secret using your cert and key pair.
  2. Set global.tls.gateway to true.
  3. Set global.tls.useDefaultTykCertificate to false.
  4. Set gateway.tls.secretName to the name of the newly created secret.

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 pump.backend, and add connection details for prometheus under pump.prometheusPump.
Mongo Pump Add mongo to pump.backend, and add connection details for mongo under .mongo.
SQL Pump Add postgres to pump.backend, and add connection details for postgres under .postgres.
Uptime Pump Set pump.uptimePumpBackend to 'mongo' or 'postgres' or ''
Other Pumps Add the required environment variables in pump.extraEnvs

Prometheus Pump

Add prometheus to pump.backend, and add connection details for prometheus under pump.prometheusPump.

We also support monitoring using Prometheus Operator. All you have to do is set pump.prometheusPump.prometheusOperator.enabled to true. This will create a PodMonitor resource for your Pump instance.

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 Mongo you can use these rather excellent charts provided by Bitnami:

helm install tyk-mongo bitnami/mongodb --version {HELM_CHART_VERSION} --set "replicaSet.enabled=true" -n tyk

(follow notes from the installation output to get connection details and update them in values.yaml file)

NOTE: Here is list of supported MongoDB versions. Please make sure you are installing mongo helm chart that matches these version.

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.

 # 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.cluster.local:27017/tyk_analytics
    # mongoURL: mongodb://mongo.tyk.svc.cluster.local: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
    mongoURL: <MongoDB address>

    # 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

(follow notes from the installation output to get connection details and update them in values.yaml file)

# Set postgres connection details if you want to configure postgres pump.
# Postgres connection string parameters.
postgres:
    host: tyk-postgres-postgresql.tyk.svc.cluster.local
    port: 5432
    user: postgres
    password:
    database: tyk_analytics
    sslmode: disable

Uptime Pump

Uptime Pump can be configured by setting pump.uptimePumpBackend in values.yaml file. It supports 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 set up other backends for pump, refer to this document and add the required environment variables in pump.extraEnvs

Dashboard

The Tyk Dashboard can be configured by modifying the values under "tyk-dashboard" section of the values.yaml file The chart is provided with sane defaults such that the only hard requirement is the license which needs to be put under .Values.global.license.dashboard in order for the bootstrapping process to work.

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 Kubernetes by itself configures values based on the referred secret.

This section describes how to use Kubernetes secrets to declare confidential fields.

Tyk Dashboard Admin

If Tyk Dashboard bootstrapping is enabled, Tyk Dashboard admin will be bootstrapped according to 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.

Warning

If global.adminUser.useSecretName is in use, please add all keys mentioned below to the secret.

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.

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.

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.

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

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

`AdminSecret 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 `useSecretName` 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 through Kubernetes secret, please use global.secrets.useSecretName, where the secret should contain a key called DashLicense.

Enterprise Portal License

In order to refer Tyk Enterprise Portal license through Kubernetes secret, please use global.secrets.useSecretName, where the secret should contain a key called EnterprisePortalLicense.

Enterprise Portal Admin Password

In order to refer Tyk Enterprise Portal's admin password through Kubernetes secret, please use global.adminUser.useSecretName, where the secret should contain a key called adminUserPassword.

Enterprise Portal Storage Connection String

In order to refer Tyk Enterprise Portal connection string to the selected database through Kubernetes secret, please use global.secrets.useSecretName, where the secret should contain a key called EnterprisePortalStorageConnectionString.

Warning

If global.secrets.useSecretName is in use, please add all keys mentioned above to the secret.

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.

global:
  remoteControlPlane:
    useSecretName: "foo-secret"

where foo-secret should contain orgId, userApiKey and groupID keys in it.

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"

MongoDB or Postgres 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: "redisPassKey"
  • Postgres:
global:
  postgres:
    connectionURLSecret:
       name: "yourSecret"
       keyName: "redisPassKey"