Migrating To Kubernetes
Dec 2, 2017 by Sasha Klizhentas
Containers have become the next big thing in infrastructure software. However, in order to take full advantage of containers you need to know how to turn them into production services. This is where Kubernetes helps - as an orchestrator of your containers.
Kubernetes is an exciting project that solves some important container deployment issues in really interesting ways. It is also one of the fastest growing open source projects in existence. If you aren’t familiar with Kubernetes, this introduction and tutorial is a good place to start.
At Gravitational, we have our own distribution of Kubernetes, called Telekube, which is optimized for running many instances of an application across a variety of infrastructure footprints. We have helped many organizations deliver their production Kubernetes clusters with the help of Telekube.
In this article, we are going to discuss some of the common challenges we’ve seen adapting existing software to run on Kubernetes.
One of the ways Kubernetes delivers high availability is by treating each instance of software as a disposable entity called Pods. A Pod can be stopped and moved to another server at any time. This brings up additional requirements to the application design.
If your software is not designed to run in multiple copies, for example it keeps local state, or has to connect to a specific database instance, this will be a problem when Kubernetes reschedules the Pod to another server.
Kubernetes provides a framework for failover and load balancing but migration efforts have to be paired with application-specific scalability work.
Learn more about high availability, sharding, caching and the usage patterns of your application first to see if it’s actually ready to jump from machine to machine behind the load balancer. Use Kubernetes to implement failover and auto scaling strategies.
Performance and Scalability
Kubernetes makes it really easy to run many copies of the same service with Deployments and Replica Sets.
Many common performance problems occur because of non-optimized database access. Running many copies of an application connecting to the same database could decrease performance of the application.
Kubernetes will solve the scalability problem very well if your application is CPU bound. However, you should make sure that’s actually the case.
Figure out the application level bottlenecks first. Understand if your app workload is CPU or IO bound and whether it is using the database(s) efficiently.
Container security requires more in-depth understanding of containers and systems in general. Someone on the team should consider understanding and managing this to be their part time (or better, yet, full time) job.
Monitoring distributed applications that can move around the cluster requires advanced instrumentation.
If you don’t have good distributed monitoring systems in place, debugging a set of distributed services running in containers across the network boundaries will be a challenge.
Kubernetes (and Docker) by default expect the logs to be sent to standard output, where logs are collected and forwarded to the centralized log storage.
If your application logs to disk, it should be reconfigured to log to standard output. Additionally, if the logs are unstructured, aggregating them together will make the logs harder to read.
Focus on transitioning logs to structured event streams first and only then use Kubernetes to collect and forward the logs to the event stream storage of your choice. Otherwise you’ll have to jump into containers and tail the logs manually. Learn more about Kubernetes integrations with log forwarders like fluentd.
Various Kubernetes components could fail, for example networking, and it takes significant expertise to learn how to troubleshoot common failures.
Kubernetes can improve your application resiliency, scalability and infrastructure security but it’s not magic. You need to be prepared to learn and understand this complex (and awesome!) system.