Adopting Kubernetes at MAX

Patrick Foh Jr
MAX Engineering
Published in
2 min readApr 10, 2018

At MAX our vision is to revolutionise last-mile mobility for logistics and transportation in Africa. To this end, the MAX engineering team is always working hard to improve our systems to better serve our customers.

Over the last year, we have built various systems within our infrastructure using docker and have now gotten to a point where we can adopt a tool to help us orchestrate containers better.

We choose to use Kubernetes as our container orchestrator for several reasons;

  1. Large community making it easy to find help when troubleshooting problems.
  2. Native cloud provider support which removes the overheads of managing Kubernetes clusters.
  3. Kubernetes has a large gamut of tools to help simplify configuration, manage secrets, visualize your clusters and a lot more. We particularly like Helm.
  4. Scalability
  5. Simplified workflow for Engineers

Our Kubernetes Workflow

After months of researching and learning about Kubernetes, we were able to create workflow for deploying services to our clusters.

Setup a Helm Chart Repository

We setup a private Helm Chart repository using Github pages to host charts for our services. Each service we build has a its own Helm Chart with a standard CI/CD pipeline which tests, packages and verifies the chart before pushing it to our Helm repository and indexing it.

Provision the cluster

We use the Azure Container Service (AKS) at MAX, which makes provisioning a Kubernetes cluster pretty simple, all it takes is a few clicks and voila! you have a cluster of nodes running.

AKS clusters come with Helm preinstalled, so we can easily connect to the cluster and install essential stuff like NGINX-INGRESS which communicates with AKS and generates a static IP address for the cluster, and KUBE-LEGO which automatically generates HTTPS certificates using the Lets Encrypt ACME client. After installing these essential packages, we then add our Helm Repository to the cluster.

Deploying the cluster

After making changes to a service, we can then push code to the service's GitHub repository and our CI/CD pipeline takes care of deploying the code to the cluster using the corresponding helm chart for the service and performing a rolling update.

CI/CD Overview

  1. Run tests
  2. Build, tag, and push the service Docker image to private registry depending on the branch.
  3. Run the deployment script depending on what branch code was pushed to.
  4. Ping the team about the deployment status via slack.

Moving forward

We are still in the early days of our Kubernetes adoption, and are constantly researching ways to make our workflow better in order to improve the productivity of our Engineers.

If you are interested in building scalable and reliable systems to power mobility in Africa, consider applying for a role on our team. Shoot us an email at tech@max.ng

--

--