Skip to main content
Version: 23.1

Kubernetes deployment

This guide assumes that all prerequisites have been met. Please visit the corresponding Prerequisites page for your infrastructure provider.

You may also use this guide for deployments to other cloud platforms (e.g. Oracle Kubernetes Engine), however it is up to you to satisfy any prerequisites for those platforms. Use at your own risk.

Deploy Tower

Create a namespace

Create a namespace to group the Tower resources within your K8s cluster.

  1. Create the namespace (e.g. tower-nf):

    kubectl create namespace tower-nf
  2. Switch to the namespace:

    kubectl config set-context --current --namespace=tower-nf

Configure container registry credentials

Nextflow Tower is distributed as a collection of Docker containers available through the Seqera Labs container registry cr.seqera.io. Contact support to get your container access credentials. Once you have received your credentials, grant your cluster access to the registry using these steps:

  1. Retrieve the name and secret values from the JSON file you received from Seqera Labs support.

  2. Create a Kubernetes Secret, using the name and secret retrieved in step 1, with this command:

    kubectl create secret docker-registry cr.seqera.io \
    --docker-server=cr.seqera.io \
    --docker-username='/\<YOUR NAME\>/' \
    --docker-password='<YOUR SECRET>'

    Note: The credential name contains a dollar $ character. To prevent the Linux shell from interpreting this value as an environment variable, wrap it in single quotes.

  3. The following snippet configures the Tower cron service and the Tower frontend and backend to use the Secret created in step 2 (see tower-cron.yml and tower-svc.yml):

imagePullSecrets:
- name: "cr.seqera.io"

This parameter is already included in the templates linked above — if you use a name other than cr.seqera.io for the Kubernetes Secret, update this value accordingly in the configuration files.

Tower ConfigMap

configmap.yml
    "docs/enterprise/_templates/k8s/configmap.yml"
  1. Download and configure configmap.yml as per the configuration page.

  2. Deploy the configmap to your cluster:

    kubectl apply -f configmap.yml

The configmap.yml manifest includes both tower.env and tower.yml. These files are made available to the other containers through volume mounts.

Redis

redis.aks.yml
  "docs/enterprise/_templates/k8s/redis.aks.yml"
redis.eks.yml
  "docs/enterprise/_templates/k8s/redis.eks.yml"
redis.gke.yml
  "docs/enterprise/_templates/k8s/redis.gke.yml"

Download the appropriate manifest for your infrastructure:

Deploy to your cluster:

kubectl apply -f redis.*.yml

You may also be able to use a managed Redis service such as Amazon Elasticache or Google Memorystore, however we do not explicitly support these services, and Tower is not guaranteed to work with them. Use at your own risk.

If you do use an externally managed Redis service, make sure to update configmap.yml accordingly:

TOWER_REDIS_URL: redis://<redis private IP>:6379

Tower cron service

tower-cron.yml
  "docs/enterprise/_templates/k8s/tower-cron.yml"
  1. Download the manifest:
  1. Deploy to your cluster:
kubectl apply -f tower-cron.yml

This container will create the required database schema the first time it is instantiated. This process can take a few minutes to complete and must be finished before you instantiate the Tower backend. Make sure this container is in the READY state before proceeding to the next step.

Tower frontend and backend

tower-svc.yml
 "docs/enterprise/_templates/k8s/tower-svc.yml"

Download the manifest:

Deploy to your cluster:

kubectl apply -f tower-svc.yml

Tower ingress

An ingress is used to make Tower publicly accessible, load balance traffic, terminate SSL/TLS, and offer name-based virtual hosting. The included ingress will create an external IP address and forward HTTP traffic to the Tower frontend.

ingress.aks.yml
  "docs/enterprise/_templates/k8s/ingress.aks.yml"
ingress.eks.yml
  "docs/enterprise/_templates/k8s/ingress.eks.yml"
ingress.gke.yml
  "docs/enterprise/_templates/k8s/ingress.gke.yml"

Download the appropriate manifest and configure it according to your infrastructure:

Deploy to your cluster:

kubectl apply -f ingress.*.yml

See the Kubernetes documentation on Ingress for more information. If you don't need to make Tower externally accessible, you can also use a NodePort or a LoadBalancer service to make it accessible within your intranet.

Additionally, see the relevant documentation for configuring an Ingress on each cloud provider:

Check status

Finally, make sure that all services are up and running:

kubectl get pods

Test the application

To make sure that Tower is properly configured, follow these steps:

  1. Log in to Tower.

  2. Create an organization.

  3. Create a workspace within that organization.

  4. Create a new Compute Environment. Refer to Compute Environments for detailed instructions.

  5. Select Quick Launch from the Launchpad tab in your workspace.

  6. Enter the repository URL for the nf-core/rnaseq pipeline (https://github.com/nf-core/rnaseq).

  7. In the Config profiles dropdown, select the test profile.

  8. In the Pipeline parameters textarea, change the output directory to a sensible location based on your Compute Environment:

    # save to S3 bucket
    outdir: s3://<your-bucket>/results

    # save to scratch directory (Kubernetes)
    outdir: /scratch/results
  9. Select Launch.

    You'll be transitioned to the Runs tab for the workflow. After a few minutes, you'll see the progress logs in the Execution log tab for that workflow.

Optional addons

Database console

dbconsole.yml
  "docs/enterprise/_templates/k8s/dbconsole.yml"

The included dbconsole.yml can be used to deploy a simple web frontend to the Tower database. It is not required but it can be useful for administrative purposes.

  1. Deploy the database console:

    kubectl apply -f dbconsole.yml
  2. Port-forward the database console to your local machine:

    kubectl port-forward deployment/dbconsole 8080:8080

    The database console will be available in your browser at http://localhost:8080.

High availability

When configuring Tower for high availability, it should be noted that:

  • The cron service may only have a single instance

  • The backend service can be run in multiple replicas

  • The frontend service is replicable, however in most scenarios it is not necessary