This chart provides a full Tyk Installation (API Management Dashboard and API Gateways with Analytics) for Kubernetes with an ingress controller and service-mesh injector.
This means that a single Tyk installation can be used for both "north-south" inbound traffic from the internet to protect and promote your services, as well as internal east-west traffic, enabling you to secure your services in any way you see fit, including mutual TLS.
It also means that you can bring the full features set of the Tyk API Gateway to your internal and external services from a single control plane.
Prerequisites
- Redis installed in the cluster or reachable from K8s
- MongoDB installed in the cluster, or reachable from inside K8s
MongoDB is not required for Tyk Community Edition or Hybrid Gateways
To get started quickly, you can use these rather excellent Redis and MongoDB charts to get going:
helm repo add stable https://kubernetes-charts.storage.googleapis.com
helm repo update
kubectl create namespace tyk-ingress
helm install tyk-mongo stable/mongodb --set "replicaSet.enabled=true" -n tyk-ingress
(follow notes from the installation output to get connection details)
helm install tyk-redis stable/redis -n tyk-ingress
(follow notes from the installation output to get connection details)
Important Note regarding TLS: This helm chart assumes TLS is being used by default, so the gateways will listen on port 443 and load up a dummy certificate. You can set your own default certificate by replacing the files in the certs/ folder.
Warning: This is highly experimental, technical support is not available.
To install, first modify the values_community_edition.yaml file to add redis details:
helm install tyk-ce -f ./values_community_edition.yaml ./tyk-headless -n tyk-ingress
Warning: Tyk Service Mesh capability is not currently supported with Tyk CE
To install, first modify the values.yaml file to add redis and mongo details, and add your license:
helm install tyk-pro -f ./values.yaml ./tyk-pro -n tyk-ingress
Follow the instructions in the Notes that follow the installation to install the controller for Service Mesh sidecar injection.
The Tyk Identity Broker (TIB) is a microservice portal that provides a bridge between various Identity Management Systems such as LDAP, Social OAuth (e.g. GPlus, Twitter, GitHub), legacy Basic Authentication providers, to your Tyk installation (https://tyk.io/docs/concepts/tyk-components/identity-broker/).
Once you have installed Gateway and Dashboard component you can configure tib.conf and profile.json, you can read about how to configure them here https://github.com/TykTechnologies/tyk-identity-broker#how-to-configure-tib, and use helm upgrade command to install TIB.
This chart implies there's a ConfigMap with a profiles.json definition in it. Please use tib.configMap.profiles value to set the name of this ConfigMap (tyk-tib-profiles-conf by default).
To install, first modify the values_hybrid.yaml file to add redis details, your RPC key, API key and Dashboard URL:
helm install -f ./values_hybrid.yaml ./tyk-hybrid
Follow the instructions in notes to install the ingress controller. Sidecar injection support is coming soon!
This Helm chart installs Tyk as a segmented Gateway service with an external load balancer, this means that the gateways that get deployed are tagged with the ingress tag. Tagged gateways like this will only load APIs that have also been tagged as ingress.
The reason gateways are sharded is so that the dashboard and the Tyk K8s controller can target different services to different gateways, i.e. services that are exposed to the internet should be routed in the ingress gateways, while service-mesh sidecars need to handle private service definitions which are created programatically, and should not be loaded into the public-facing gateways.
While we recommend the unlimited node Tyk license for Kubernetes deployments, it's still possible to use limited licenses by changing the gateway resource kind to Deployment and setting the replica count to the node limit. For example, use the following options for a single node license: --set gateway.kind=Deployment --set gateway.replicaCount=1 or similar if modifying the values.yaml.
Note, however, there may be intermittent issues on the new pods during the rolling update process, when the total number of online gateway pods is more than the license limit.
You can set a tag for your exposed services in the API Designer, under the "Advanced Options" tab, the section called Segment Tags (Node Segmentation) allows you to add new tags. To make an API public, simply add ingress to this section, click the "Add" button, and save the API.
If you are using an ingress spec, then the Tyk k8s controller will do this for you.
If you are using the latest chart, you can set the enableSharding value in the values.yaml to false.
If you are running an older chart that does not have this value, then you can disable node sharding beforehand by editing the tyk-pro/configs/tyk_mgmt.conf file, simply set the value db_app_conf_options.node_is_segmented to false.
Please Note Doing this means that the service mesh sidecar injector and its related generated APIs will not work correctly, as those services will also be loaded by your ingress gateways.
To enable the ingress controller, simply add the ingress class defintiion to your ingress annotations:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: cafe-ingress
annotations:
kubernetes.io/ingress.class: tyk
spec:
rules:
- host: cafe.example.comBy default Tyk will create an open API (no security enabled), however you can set any property in the API Definition using the following annotations (remember that all annotations are treated as strings):
bool.service.tyk.io/{path}: value: Set a value to"true"or"false"string.service.tyk.io/{path}: value: Set a value that is a string literal, e.g. "name"num.service.tyk.io/{path}: value: Set a value that is a number (assumes an int)object.service.tyk.io/{path}: value: Set a whole json object
Here's an example:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: cafe-ingress
annotations:
kubernetes.io/ingress.class: tyk
bool.service.tyk.io/use-keyless": "false"
string.service.tyk.io/proxy.target-url": "http://foo.bar/bazington"
num.service.tyk.io/cache_options.cache-timeout": "20"
object.service.tyk.io/version_data.versions.Default.extended-paths": '{"hard_timeouts":[{"path":"{all}","method":"GET","timeout":60,"fromDashboard":true}]}'
spec:
rules:
- host: cafe.example.com
http:
paths:
- path: /tea
backend:
serviceName: tea-svc
servicePort: 80
- path: /coffee
backend:
serviceName: coffee-svc
servicePort: 80You can also directly modify the service in your Tyk Dasboard, though if the ingress is recreated, the changes may not be retained.
When an ingress is removed, the services will be removed from the API Gateway as well.
It's quite likely that you will not want to overload your ingress specifications with annotations that set specific values in your API Definition. To make adding APIs much more flexible, you can make use of a single template.service.tyk.io/ annotation to specify the name of a template to use when deploying your service to the gateway.
This can be extremely useful if you want to standardise on certain types of service, e.g. "open-public", "closed-public" and "closed-jwt-internal", where you apply different auth scehemes, IP white lists and more complex re-usable specifications such as IDP provider details and secrets that you don;t want to re-code into each definition.
Templates currently must have a .json filetype to be loaded into the controller and parsed.
To use templates, you will need to re-deploy the tyk-k8s container and add volume mounts for your templates:
### --- deployment-tyk-k8s.yaml
### --- there's other stuff up here
spec:
{{ if .Values.rbac }}serviceAccountName: tyk-k8s {{ end }}
containers:
- name: tyk-k8s
image: "{{ .Values.tyk_k8s.image.repository }}:{{ .Values.tyk_k8s.image.tag }}"
imagePullPolicy: {{ .Values.tyk_k8s.image.pullPolicy }}
workingDir: "/opt/tyk-k8s"
command: ["/opt/tyk-k8s/tyk-k8s", "start"]
ports:
- containerPort: 443
volumeMounts:
- name: tyk-k8s-conf
mountPath: /etc/tyk-k8s
- name: webhook-certs
mountPath: /etc/tyk-k8s/certs
### Custom templates:
- name: tyk-k8s-templates
mountPath: /etc/tyk-k8s-templates
resources:
{{ toYaml .Values.resources | indent 12 }}
volumes:
- name: tyk-k8s-conf
configMap:
name: tyk-k8s-conf
items:
- key: tyk_k8s.yaml
path: tyk-k8s.yaml
### Custom templates:
- name: tyk-k8s-templates
configMap:
name: token-auth
items:
- key: token-auth.json # these should be real filenames ending .json
path: token-auth.jsonYou will also need to update the config file for tyk-k8s:
### configmap-tyk-k8s.yaml
Tyk:
url: "{{ .Values.tyk_k8s.dash_url }}"
secret: "{{ .Values.tyk_k8s.dash_key }}"
org_id: "{{ .Values.tyk_k8s.org_id }}"
# Add this line
templates: "/etc/tyk-k8s-templates" Templates are added as config maps, to convert an API definition to a template, simply encapsulate it in template tags, like this:
{{ define "tokenAuth"}}
{
"name": "{{.Name}}{{ range $i, $e := .GatewayTags }} #{{$e}}{{ end }}",
...
}
{{ end }}
Once you have created them, add the to the namespace as config maps:
kubectl create configmap token-auth --from-file=token-auth.json --namespace {namespace}
Once these template configMaps have been added, and your tyk-k8s service is running, you can set up your service definitions very easily by adding a single annotation:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: cafe-ingress
annotations:
kubernetes.io/ingress.class: tyk
template.service.tyk.io: tokenAuth
spec:
rules:
- host: cafe.example.com
http:
paths:
- path: /tea
backend:
serviceName: tea-svc
servicePort: 80
- path: /coffee
backend:
serviceName: coffee-svc
servicePort: 80For a sample template, please see the token auth template in the controller repository.
Tyk supports the TLS section for the ingress controller. If you set a TLS entry with a secret, the controller will retrieve the certificate from K8s and load it into the encrypted certificate store in Tyk and dynamically load it into the ingress. You can manage the certificate from within Tyk Dashboard.
TLS can also be disabled by setting gateway.tls option to false. In this case the gateway will run with HTTP listener. This is useful, e.g. in case TLS is terminated externally (such as on a cloud provider's load balancer).
The service mesh injector will create two services:
- An inbound service for the container - this is only loaded into the sidecar for the service and handles all inbound requests for the service from the mesh
- The mesh endpoint, this is the route that is circulated to all sidecars as the route to the service in (1)
Setting up a service to use the injector is very simple, simply add the inject annotation to your Deployment:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: sleep
spec:
replicas: 1
template:
metadata:
annotations:
injector.tyk.io/inject: "true"
injector.tyk.io/route: "/sleep"
labels:
app: sleep
spec:
containers:
- name: sleep
image: tutum/curl
command: ["/bin/sleep","infinity"]
imagePullPolicy: IfNotPresentBy default, the injector will create the service route on /{pod.Name}, however you can specify the route to advertise using the injector.tyk.io/route instruction, this will set the proxy.listen_path in the Tyk API Definition.
By default the service is open (as with the ingress), however you can use the same service annotations as the ingress to set options on the created service. Note: The changes only affect the inbound service, not the mesh service. This means rate limits, quotas, and security policies are applied in the inbound side-car as opposed to the sender side-car.