StackDependenciesKubernetes

Kubernetes

Last updated: Jul 1, 2026


Rationale

Kubernetes is the system we use for hosting, deploying and managing our applications. It allows us to serve and scale our applications in an easy, secure and automated way.

The main reasons why we chose it over other alternatives are:

Alternatives

The following alternatives were considered but not chosen for the following reasons:

  • AWS ECS: It is a serverless service for running containers. It is expensive as only one container exists within an entire physical machine. It does not support extensions. It is platform-bounded. It is not open source.
  • AWS Fargate: It is a serverless service for running containers without administering the infrastructure upon which they run. It is expensive as only one container exists within an entire physical machine. It does not support extensions. It is platform-bounded. It is not open source.
  • AWS EC2: It is a service for cloud computing. AWS EKS actually uses it for setting up cluster workers. It does not support extensions. It is platform-bounded. It is not open source.
  • HashiCorp Nomad: Currently, no cloud provider supports it, which means that having to manage both managers and workers is required. It takes a simpler approach to orchestrating applications, with the downside of losing flexibility.
  • Docker Swarm: Currently, no cloud provider supports it, which means that having to manage both managers and workers is required. It takes a simpler approach to orchestrating applications, with the downside of losing flexibility.

Usage

We use Kubernetes for

  • hosting our platform;
  • automatically deploying ephemeral environments on CI/CD workflows;
  • automatically deploying DNS records for applications;
  • automatically deploying load balancers for applications;
  • automatically scaling worker nodes based on application load;
  • running application performance monitoring using New Relic.

We do not use Kubernetes for:

  • Rollbacks: We should version production artifacts in order to be able to automatically return to a previous working version of our applications.
  • GitLab Runner: It was slow, unreliable and added too much overhead to workers. We decided to go back to Autoscaling Runner.
  • Chaos Engineering: In order to harden ourselves against errors, we should create a little chaos in our infrastructure.

On this page