Kubernetes is a whole new world. Many organizations have been running their own servers for forever, and are used to being able to walk across the datacenter floor to flip a switch; or maybe they've been in the cloud for a while, but they're still working with instances that they treat like pets. But Kubernetes is different. There are things you need to know before you even get started. Here we discuss all the pitfalls to watch out for when implementing Kubernetes.
What surprised me when I started with Kubernetes is just how differently you need to think about it. Even with several years of AWS and cloud computing experience under my belt, Kubernetes felt like a foreign language, and I needed to change the way I thought about computing in order to understand it.
The biggest issue is that there are so many different ways to set up a Kubernetes cluster and so many different add-ons that do roughly the same job. It's important to do a lot of research before setting up a cluster for the first time; otherwise you may discover constraints that require you to tear everything down and start again.
One of the difficulties with Kubernetes is the hype. There is so much information available, from large-scale enterprises sharing their war stories, to hobbyists who have stood up a cluster on three raspberry PI's in their basement writing about how Kubernetes is changing the world.
It’s important to focus on the perspectives of folks who have run workloads, at scale, in a production environment, with a secure, efficient, and reliable configuration. It can be difficult to find people who are actually authoritative, so be careful about where you get your information. You're going to need to do a lot of research. Try to focus on places that make sense.
Gone are the days when sysadmins' would brag about servers with 17 years of uptime. Everything about the world of Kubernetes is ephemeral, meaning short lived. The workloads themselves are ephemeral, but we even encourage you to think all the way down to the cluster level as completely ephemeral. You should be able to destroy and recreate your clusters without a problem.
There are a lot of different ways to run workloads in the cloud. Why choose Kubernetes over something like Amazon’s ECS or Salesforce’s Heroku?
The main answer is that Kubernetes is an open-source project, which means you can use it for free, modify it to suit your needs, and never have to worry about outgrowing it or getting locked-in. And the open source ethos has fostered a rich ecosystem of extensions to Kubernetes; almost all the core add-ons you'll install on top of Kubernetes are free and open source.
Furthermore, Kubernetes can run on any of the major clouds, as well as on-prem, helping you to avoid lock-in to a particular way of doing things or to a particular service provider. Kubernetes is really meant to be everything to everyone. It's a remarkably flexible framework - there existing patterns and add-ons that will allow you to implement a serverless architecture or a Heroku-like platform on top of Kubernetes. It’s flexible enough to do anything other PaaS solutions can do, and with the right configuration, Kubernetes can be fully customized to your needs.
With platforms like ECS and Heroku (which are both proprietary) you sacrifice flexibility for simplicity. For example, you might be restricted to using a particular OS, or they’ll want you to set up network traffic in a particular way. If you choose ECS or Heroku, it’ll probably be a bit easier to get started, but you run the risk of eventually outgrowing them, and having to take on a painful migration.
Many organizations want to put DevOps practices into place, and believe switching to Kubernetes will help with that transition. But while Kubernetes can help to catalyze a DevOps transformation, it’s no silver bullet. You can have DevOps culture without Kubernetes and Kubernetes without DevOps.
However, deploying Kubernetes can help companies accelerate the transition to DevOps. Because it serves as an API layer between the infrastructure and the engineer, Kubernetes makes it easy to establish patterns of collaboration and communication between Dev and Ops. That allows developers to take more responsibility for the deployment configuration for their applications, and helps Ops teams trace production issues back to particular commits.
When developers can write code, deploy it, see it running in production, and understand how it’s running, they will have visibility into what’s working and what’s breaking. They’ll have a full sense of ownership over everything they shipped to production. That’s a true DevOps culture.
Again, Kubernetes can play a part in DevOps, but it's really just one piece of the puzzle. Companies still need to shift the way teams interact with each other to successfully implement a DevOps culture.
The Kubernetes ecosystem has matured a lot over the last few years.There are some well-established patterns like using infrastructure as code, and curated sets of add-ons for doing things like ingress or certificate management. Sticking with battle-tested best practices is a good way to make sure you don't run into any strange corner cases when implementing Kubernetes.
Find people who have lots of experience running Kubernetes at scale, or find a partner that can help you through your journey. There are a lot of “unknown unknowns” when implementing Kubernetes, so find someone who has been through these battles before and has the scars to prove it.
People rave about Kubernetes, and there is a reason for that. It’s a hugely beneficial platform. Can you use it wrong? Yes. If you are new to it, is it difficult to use until you get used to it? Yes. But once you’re off and running, it lives up to the hype.
