Best Practices: How to Architect Applications for Kubernetes

Architecting a production-ready application for Kubernetes is not an easy task, but guidelines and best practices are available to ensure your application meets all necessary requirements for a production environment.

The microservice pattern has helped evolve the way applications are built. Because of this change, the platforms that can run your app should be considered during development. Indeed, Kubernetes itself—an exceedingly popular container orchestration platform—has drastically changed how we build and deploy apps. So, here are a few tips to keep in mind before running your application on Kubernetes.

(This article is part of our Kubernetes Guide. Use the right-hand menu to navigate.)

Your app must be a container image

Because K8s is a container orchestration engine, your application must be packaged into a container image for it to run in a k8s cluster. This is among the most basic requirements for building microservices, as it directly ties into how Kubernetes functions as a platform.

Ideally, you should keep your application image in a private repository for secure storage. For example, you can build a docker image and push that image to a private docker repository, where Kubernetes can then pull your image from.

By default, Kubernetes supports container runtimes in:

• Docker
• CRI-O
• containerd
• Frakti

Follow best practice for whichever runtime you use. The one for Docker can be found here.

Helm is your friend

If you have never used Helm charts, you are missing out. Helm is the de-facto way to deploy production-grade applications into Kubernetes. It allows you to describe your application in charts—so you can version, publish, share, and do other useful things with your application. It is Kubernetes yum or apt-get for simplicity.

A typical helm chart looks something like this tree:

YOUR-CHART-NAME/
|
|- .helmignore        [Files to ignore]
|
|- Chart.yaml         [Data about the chart. E.g Version etc] 
|
|- values.yaml        [This is the variable file.] 
|
|- charts/            [Specify other needed charts]
|
|- templates/         [This hold all the manifests for the application. E.g yaml files]

Note: Using a CLI tool like kubectl should be used only in dev or for debugging—never for deploying into production.