Should I migrate to Kubernetes?

Kubernetes is a powerful container management tool that automates the deployment and management of containers. More and more businesses migrate their infrastructure and architecture to reflect a cloud-native, data-driven era. Yet, the learning curve can be heavy and lead to the question: should I invest in a migration to Kubernetes?

So if you are yourself wondering if you should use Kubernetes, here are a few things you won’t have to think about anymore if you decide to train yourself on Kubernetes.

Choosing an OS

Without containers, switching your app from one OS to another is a massive pain because of all the subtle difficulties to navigate: different versions, different package names, different defaults, and so on. Applications don’t care about your OS, and Kubernetes makes the OS choice irrelevant.

Deploying your app

You can script something to restart your service. But how would you know if your app started correctly? How can you roll back if the deployment went wrong? You would have to write a few scripts and ensure to support "singleton" services that must not have multiple copies running at once vs normal services that need to run more than one during deployment.

Wondering if your application is working

Maybe your app crashes and stops running. How can you ensure it gets restarted? Do you get alerted when it dies in the middle of the night and doesn't restart properly? More custom code, more research to find something that will health-check your app.

Locating logs

How do I know when the last deployment was? How do I find out why it restarted? More custom code, more research to find out if ELK stack would work.

Wondering how is your server doing

Is the disk filling up? Is there enough RAM? Is the CPU overloaded? I guess I need to research and install Nagios or Zabbix.

Routing traffic to your app

I only have one app, which means my site goes down when I deploy. Ok, I guess I need to run a load balancer. But now I have to write software to configure the load balancer.

Managing cron jobs

Sure, writing the cron job is trivial. But I guess I have to write code to retry on failure. Oh, and how do I get notified of repeated failures?

Backing up your server

Sure, you could snapshot your whole 10GB disk, but that feels silly. I guess I have to write a custom script that backs up just the important configuration files, right? (Sure would be nice to have all "config" centralized/declared in one place.)

Upgrading your server

Sure, you can deploy your app, but what about upgrading your server or kernel (without breaking your app?) Sometimes you have to do this in an emergency when the latest Spectre/Meltdown/HeartBleed is going around. Kubernetes operators are making this super-easy, even for things like managing a database.

Documenting

What port does your application run on? What is your LB config? What version of Python/Java did I need to install again? Is my server documentation up-to-date? How would you know?

Going multi-cloud

Microservice architecture makes it easy to split your application into smaller components with containers that can then be run on different cloud environments, giving you the option to choose the best host for your needs.

So do I need Kubernetes?

Kubernetes plus a few add-ons such as Prometheus or Grafana can transform all of those challenges into an afternoon exercise. You can find online alert templates that will wake you up if CPU/disk is getting full, or your app falls over and doesn't get back up.

Instead of thinking about low-level details of servers, OS images, and procedural maintenance, you get to think higher-level, about applications, services, and declarative properties of your application. It makes it easy to think in terms of "Immutable Infrastructure " and "Infrastructure as Code", which make maintenance a breeze.

Managed Kubernetes, such as Kapsule, equipped with all the best practices and configuration, can also be a game changer and can help smooth out the heavy learning curve that comes with Kubernetes.