Whether you are new to Kubernetes or have some experience under your belt, there are some things that you should simply never, ever do in Kubernetes. Corey Quinn, founder of Screaming in the Cloud and Chief Cloud Economist at The Duckbill Group, joined Kendall Miller, President of Fairwinds, and Stevie Caldwell, Senior Site Reliability Engineer at Fairwinds to discuss what development and operations teams should never ever do in Kubernetes if they want to get the most out of the leading container orchestrator. Here are a few Kubernetes basics tips to get you started.
(Remember, this is never should you ever, so the headlines might seem a bit wrong to some!)
Many site reliability engineers have absolutely done Kubernetes the hard way — learning from scratch how to set up and run Kubernetes environments. Undeniably, it can be a very interesting journey, and you’re going to learn a lot. It's good to know what's going on under the hood, so when you have complex problems you have some ideas about how to deal with them. So as a learning process, it can be very valuable.
When you’re trying to get up and running fast, however, it’s really helpful to get started with some of the basics in place, and get help and advice from the folks who’ve already learned how to build repeatable frameworks. Most companies face the same infrastructure problems, so while you might learn a lot trying to figure out all of the moving parts in Kubernetes yourself, it can be kind of mind boggling to figure out everything that you need to track and manage. Doing Kubernetes the hard way is great for learning, but you probably want your production infrastructure to be built on something more robust.
If you're spinning up and turning down clusters all the time, maybe throwing a blog on Kubernetes doesn't feel like overkill. But even in that situation, it's a stretch. When you're learning something like Kubernetes, you might want to run a ‘hello world” blog on top of Kubernetes as part of your training process, because most people readily understand the purpose and functionality of a blog. And it’s easy to grab a blog app from a variety of places and try it out. The problem comes when people think they should run their blog on top of Kubernetes.
Ask yourself, why do you want to use something very complex for something that's essentially very simple? Here are a few reasons you probably don’t want to use K8s for your simple blog:
The complexity of running a production grade Kubernetes cluster isn’t worth the cost, which can be significantly higher.
To have maximum uptime, you need to run a high availability cluster, further increasing the complexity of your deployment.
The brainpower to troubleshoot things that aren't going correctly just isn’t worth it for something that’s easy to run in another way.
If you’re asking yourself, should I build this myself? Should I host WordPress locally? Should I build a Kubernetes cluster? The answer is: you can, but you don’t need to. Choose your battles, and save your energy for when it counts.
Your master nodes, mainly the etcd component, is something that you don't want to disappear without your control. If your control plane nodes go away, your workload will still run and that's fine, but you have quorum to consider. If you're doing your control plane manually in some way, bringing etcd back up after you've had some nodes drop out is a really painful, manual process.
Spot instances on AWS, or preemptive ones on other providers, are effectively unused capacity that is far less expensive, but it can be taken away at any time. If you balance it out correctly, you can save significant money and your site stays up — in most cases! In Kubernetes environments, the control plane is not a large percentage of your node account. So the hassle that you get by trying to save a little bit of money on just the control plane fees isn’t worth it. And you’re probably going to ruin someone’s day (or night) when it goes down and someone needs to fix it.
Basically, it’s not good practice to run your core services on the control plane. You don't want to run your resource-hungry pod on the nodes that are responsible for keeping your cluster running. If your resources get out of control on the control plane, it will really impact your deployment. You want to keep your control plane stable, and keep the workloads that require a lot of resources separate.
Watch the entire webinar on demand to learn what else you should never, ever do in Kubernetes.
