Skip to main content
The chart creates the Kubernetes resources that expose Tembo. Your cluster’s controllers turn them into load balancers, DNS records and certificates.

​
What the chart creates

With ingress.host: tembo.example.com:
  • The internal Services carry their DNS name in an external-dns.kubernetes.io/hostname annotation.
  • The Postgres and Redis Services exist only with the bundled data stores and compute.mode: controller.
  • Previews are on by default from chart 0.6.0, with Tembo releases later than 0.2.892. To turn them off, set sandbar.enabled: false.

​
What you set up

​
1. An Ingress controller

It turns both Ingresses into load balancers, so users and webhooks can reach Tembo. Set ingress.className and any ingress.annotations your controller needs. The previews’ Ingress gets the same ones. On AWS or GKE, turn on ingress.aws or ingress.gcp instead of writing annotations. Both take the same settings, and the chart turns them into that cloud’s configuration:

​
2. DNS

Every name in the table must resolve to its load balancer: browsers find Tembo by name, and agent hosts find Sandbar, Postgres and Redis by name.
  • With external-dns: it reads the Ingresses’ hosts and the Services’ annotations and creates the records.
  • Without it: create the records yourself once the load balancers exist (kubectl -n tembo get ingress,svc).
The internal names only need to resolve from your VPC.

​
3. TLS certificates

Tembo is served over HTTPS, so you need two certificates:
  • tembo.example.com
  • *.previews.tembo.example.com. A *.example.com certificate doesn’t cover it.
Your load balancer can provide them (for example ACM on AWS). Otherwise, cert-manager can issue them into Secrets:
  • Name the app’s Secret in ingress.tls.secretName. The previews’ Secret is always tembo-previews-tls. On GKE, only previews need one.
  • Add a cert-manager.io/cluster-issuer annotation to ingress.annotations.
  • Wildcards need a ClusterIssuer that uses DNS-01.
If the previews certificate is missing, only previews fail. The web app and API keep working.

​
Examples

ingress.aws and ingress.gcp need a chart released after 0.6.0. Before it, GKE used ingress.gke.enabled.

​
EKS

We use the AWS Load Balancer Controller (EKS Auto Mode), external-dns and ACM.
  • Load balancers: ingress.aws makes each Ingress an internet-facing ALB with an HTTPS redirect, and sets its health checks. On EKS Auto Mode, internal load balancers need the eks.amazonaws.com/nlb class. The module’s Helm values set it for Postgres and Redis, and Sandbar uses the same one.
  • Certificates: request ACM certificates for tembo.example.com and *.previews.tembo.example.com in the cluster’s region. The ALB finds them by name, or list their ARNs in ingress.aws.certificates. It can’t use Kubernetes Secrets, so cert-manager doesn’t apply here.

​
GKE

We use GKE’s built-in Ingress, external-dns and cert-manager, with a Let’s Encrypt ClusterIssuer that solves DNS-01 in Cloud DNS.
  • Load balancers: ingress.gcp sets up both Ingresses for GKE, with health checks and the HTTPS redirect. To serve on a reserved IP, add a kubernetes.io/ingress.global-static-ip-name annotation.
  • Certificates: GKE gives tembo.example.com a Google-managed certificate. Those can’t be wildcards, so cert-manager issues *.previews.tembo.example.com into tembo-previews-tls. Use your ClusterIssuer’s name in the annotation.

​
Need Help?

If you run into any issues, contact support@tembo.io.