An introduction to our main deployment platform, based on the Elastic Kubernetes Service on AWS.

Architecture

  • Elastic Container Service for Kubernetes (EKS) control-plane
  • Autoscaling & Auto-healing worker-nodes by Karpenter
  • Kubernetes Ingress powered by AWS NLB and NGINX
  • Wildcard DNS and certificate per cluster

Getting Started

The following will give you an introduction to the most common tasks when interacting with EKS.

Kubectl Access

Learn how to get access to EKS via the local CLI / kubectl.

Pre-requisites

Switching the EKS Cluster Kubeconfig

The Boost CLI will automatically switch to the EKS cluster in your account if only one cluster is present. If multiple clusters are present in your account, you can select the desired cluster with the --cluster flag. For more information see the Boost CLI's documentation.

Example default cluster selection:

boost auth
kubectl get pods

Example specific cluster selection:

boost auth --domain platform --stage dev --region us-east-2 --cluster eks-us-east-2-platform-dev

GitlabCI Access

Learn how to deploy to your EKS cluster from Gitlab CI.

Pre-requisites

  • your Gitlab project has to be part of the "productgroup" Gitlab group

Access to these GitLab groups is managed by the engineering manager related to the architecture domain. Projects can be moved to another GitLab group without big impact, as a redirect will be configured automatically from the old location. For more information on how to transfer projects, check the official docs.

An audit log of all changes can be found in the Kibana Index gitlab-*.

Deploying Apps via Gitlab CI

We recommend to use our Platform Auto DevOps Pipeline and our Platform Helm Chart for deploying apps to our infrastructure.

Alternatively, you can choose a matching Gitlab Runner with access to your domains Kubernetes cluster and stage.

custom_deploy_to_productgroup-dev:
stage: deploy
script:
- helm upgrade --install myapp myrepo/mychart
tags:
- eks-eu-central-1-productgroup-stage