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 authkubectl 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: deployscript:- helm upgrade --install myapp myrepo/mycharttags:- eks-eu-central-1-productgroup-stage