Kubernetes

Last updated: Feb 11, 2026

---

Rationale

Kubernetes is the system we use for hosting, deploying and managing our applications. It comprises infrastructure solutions like RBAC Authorization, distributed persistent storage, managing resource quotas, managing DNS records, managing load balancers, autoscaling, blue-green deployments, and rollbacks, among many others. 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:

• It is capable of deploying complex applications, including related servers, DNS records, and load balancers in an automated way, allowing us to focus more on the application development and less on the infrastructure supporting it.
• It can be fully managed using Terraform.
• It supports Blue-Green deployments, allowing us to deploy applications many times a day without service interruptions.
• It supports Rollbacks, allowing us to revert applications to previous versions in case the need arises.
• It supports Horizontal autoscaling, allowing us to easily adapt our applications to the loads they're getting.
• It supports Service accounts, RBAC Authorization, and IRSA, allowing us to give applications permissions to external resources using a least privilege approach.
• It supports resource quotas, allowing us to easily distribute containers among physical machines using a granular cpu/memory per container approach.
• It has its own package manager, which makes deploying services very easy.
• It has its own local reproducibility tool for simulating clusters in local environments.
• It is open source.
• It is not platform-bounded.
• Azure AKS, AWS EKS, GCP GKE, support it.
• It can be IaaS when implemented under a cloud provider.
• Migrating it from one cloud provider to another is, although not a simple task, at least possible.
• It is widely used by the community.
• It has many open-source extensions.

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.