As a beginning to my Road To Kubernetes series, some people might think it makes sense to start by talking about all the things you can do in Kubernetes, but I think the natural place to start is when you’re first developing your application if your application isn’t developed to take advantage of Kubernetes it probably shouldn’t be deployed there.

So how do we write an application to take advantage of Kubernetes? You can do many things, but I think the best place to start is to make sure you are using the twelve-factor methodology. If you’re not familiar with it, I would highly recommend clicking on the link and reading through the site thoroughly to learn everything you need, but the TLDR is that if you follow a few factors, your application is probably suitable for deployment to modern cloud platforms, including Kubernetes. I’ll briefly review each factor and tie it back to how it will help your app run in Kubernetes.

Codebase

The first factor is pretty straightforward: You have your code base in one place, and it’s under source control. While it’s not impossible to deploy an application to Kubernetes without it being under source control, it will make everything else you do much harder. There are entire application deployment methodologies for Kubernetes that are tied into source control (gitops). This factor also speaks to having one application in a single code base. I don’t always agree with this one, especially if you are using a microservice pattern; it may make sense for multiple applications to live in the same repo.

Dependencies

This one isn’t much of a problem anymore, but once upon a time, application dependencies were installed system-wide. Not much else to say here because all modern application development platforms have dependency managers.

Config

Configuration is everything likely to vary between deployment environments (dev, staging, prod, etc.) That can things include credentials, per-deployment values, and connection strings. Apps will sometimes store configuration in code. DON’T DO THIS. It’s a security issue, making deploying your code to different environments much harder. There are multiple ways to store and access your app config. My preferred method lately is to use environment variables to store your configuration. Pretty much every language has a way to access environment variables at run time. That allows you to set and access the configuration very quickly. That includes Kubernetes, where there are processes to set environment variables for pods.

Backing Services

Treating backing services as attached resources isn’t the norm these days. My thinking on this is that we should be treating dependencies as dependencies and not try to deploy database infrastructure, for example, at the same time as the application. The database infrastructure should be deployed beforehand; the only thing needed at application deployment time is the connection string for connecting to the database.

Build, Release, Run

A well-built app has three distinct deployment stages; build, release, and run. The build stage converts the code repo into an “executable” bundle. I have quotation marks around executable because many languages are interpreted today, and there is no executable. In the context of Kubernetes, this would be a docker image you build. The release stage combines the produced build with the deployment’s current configuration. For Kubernetes, this is two things; we push the docker image up to a container registry and the YAML for deploying to Kubernetes. The run stage runs the app in the execution environment; for Kubernetes, this is the equivalent of doing kubectl apply with the YAML created in the release stage.

Processes

In my opinion, this one is named wrong. The definition of this factor on the site is to Execute the app as one or more stateless processes. I think calling this factor Stateless is better. What does being stateless mean? A stateless application means data doesn’t persist in the application process running. It is stored in some backing data service or store (like a database). The idea of web apps being stateless is pretty standard now, but that wasn’t always the case; old Java web apps were notorious for keeping state around between requests in shared memory or the file system. Using sticky sessions is another example of a state in the app and is not the best thing to do. There’s not much to tie back to Kubernetes here, but in the land of k8s, memory consumption on pods is almost always a problem, so keeping your memory low will always be good.

Port Binding

Web applications had web servers injected into them at runtime for a long time. This isn’t very common anymore because it can cause many problems. The way most web frameworks do it now is to have an HTTP server bind to a port and then listen for requests on that port. This is a fundamental of the way Kubernetes work; your app will attach to a port, and through configuration, Kubernetes will send traffic to that port when appropriate. There might be exceptional use cases where this deviates, but for the simplest case, that’s the way it works.

Concurrency

Twelve-factor apps should be able to have their servers scale both vertically and horizontally. That means by adding more CPU, memory, and possibly other resources; your app can process more requests (vertical scaling). Also, if you add more servers or. in the case of Kubernetes, pods, your app can process more requests (horizontal scaling). Having your app be stateless is essential for horizontal scaling because what happens if a request comes in, but the state it needs to process is on another pod? Always storing your data in a separate backing service like a database is the best practice for this reason.

Disposability

How long should it take an application that crashes to restart? If you had a sudden spike in traffic and need to deploy your app to a new server, how long would that take? When we talk about making your app disposable, we talk about fast startup and graceful shutdowns. I’ve encountered several applications that can take up to 10 minutes before they’re started. If we needed to quickly spin that app up for a sudden spike in traffic, we would have been in trouble. Focus on disposability is critical to using Kubernetes pods efficiently. An app running on a pod crashes? It just spins up another one. Need to scale horizontally to support a rise in traffic? Just change the deployment configuration, and you can have multiple pods running.

Dev/Prod Parity

Keeping your development and deployment environments as similar as possible is something I repeatedly teach the development teams I work with. If I see a team using a different database on their development machines than in their production environment, we must discuss why. Sometimes it’s due to licensing costs or too challenging to get something set up locally. This is important because a whole class of bugs could arise from using something different during development than you would use in production. Docker has helped with this, as most of the time, you can have all the backing services for your production environment running locally in containers. Sometimes that’s impossible, and then conversations need to figure out an acceptable approach that minimizes the number of bugs that could arise. Ideally, you should deploy the same architecture with a different scale in any deployment environment. For example, you have two web servers in production but only need one in dev and staging.

Logs

Logging is one of the essential tools available to you during the lifetime of an application. It can help you monitor app health and performance and give insight when issues arise. That said, an app should never concern itself with routing and storing its logs. It should just write out the logs to stdout and let log aggregation tools do the work of routing and storing them. This gives the app flexibility to run on more platforms and doesn’t get in the way of operations teams that may need to do actions on those logs. In the Kubernetes world, everything should be ephemeral; if a pod crashes and you’re writing logs to a log file in your app, that log file will disappear, and you’ll never be able to review the logs to understand why it crashed.

Admin Processes

How do you accomplish one-off administrative tasks like changing the database in your apps? Is it a manual process, or do you have it automated? Is the task completed in the same context as the rest of your application, or is it separate? We should strive to automate these admin tasks and run them in the same context as the application to reuse configuration and code. That is hard to do inside the context of Kubernetes, but not impossible. Some languages include a REPL shell out of the box, and many frameworks have tools for building and running one-off tasks. You’ll just need shell access to a pod with restricted access like any other web server for your application (sparingly).