The good, the bad, the ugly
As we mentioned in part 1 and part 2 of this blog series, both Kubernetes and Docker, along with the use of containers, have a history that instills a lot of confidence in using Kubernetes. But this isn't the best solution for everyone, as, like any software, its use should be well thought out. We’ll explain why you should, or perhaps should not, choose it.
The bad
Remember all that trust in Google’s internal processes? Unfortunately, they are also filled to the brim with complexity. Some even dare to claim that everything is overdesigned. Kubernetes is managed via an API. When creating it, you can choose from a wide range of objects. So, you’ll need to invest some time to overcome that learning curve. The easiest objects are pods and services. In most guides, you’ll be up and running quickly with an nginx container and a static website, but what do you do with monitoring, certificates, and persistent data? For this, you’ll need an additional component in your environment, which brings its own API objects with it.
Setting up a Kubernetes environment locally can be quite easy using kubeadm. However, when moving to production, it is not advisable to do this in the same way. You will then need to use a different scheduler or maybe even set up the installation entirely on your own. Networking is always a crucial aspect because you’re working with different systems for your masters and workers. On those workers, pods and services run, each with its own IP address, and that all needs to be quite dynamic because those pods can also move around. All these pieces must be able to communicate perfectly, or things will not function correctly. Moreover, there are different implementation options, each with its pros and cons, making the choice even more difficult.
So, if something goes wrong in your environment, you really need to know what you're doing. What do you do when a node becomes unavailable, when a namespace can't connect to the network, or when a pod brings down your entire cluster? You’ll need to prepare for these situations so you can react quickly. You can run failure tests, centralize logs, and gain insights into your environment by visualizing component statistics.
As mentioned earlier, Kubernetes is an open-source project with a quick release cycle. It continues to evolve with new features that might be useful to implement. But this also means you’ll need to keep investing time. How will you handle upgrades? Where will you test those new versions? The additional components like monitoring must also be updated, but will they still work after an upgrade? What has been changed there?
Don’t let yourself be convinced by Kubernetes buzzwords like auto-scaling, easy deployability, redundant by design, and fewer resources. In practice, you’ll need to invest quite a bit of time to get these features working. Additionally, a wrong implementation is easily made and can haunt you for some time. So, make sure to build a solid business case and evaluate whether Kubernetes will really offer you any benefits. Ask yourself: what do I gain with Kubernetes, what do I lose, and what if I do it the ‘uncool’ way?
The good
Does all this sound a bit intimidating? Good, that was the intention. Don’t get us wrong, Kubernetes is an impressive technology that can do great things. But, just like any other software, use it for its intended purpose. And there are definitely some use cases that make implementing it worthwhile.
Let’s say you’re a software company using 20 different technologies, each with its own version. If you’re using VMs for this, you’ll need some automation to ensure the machines are similarly configured. You might not want to upgrade Java manually every time or support an old version of PHP on your operating system? In this case, you could place your software in containers, so each one has what it needs. This way, you can keep up with the latest software versions much faster since you’re not waiting for the infrastructure to catch up. So, Kubernetes will definitely provide a solution for managing all those technologies in containers.
If you’re a tech-driven team that loves the latest technology, go for it. If there’s motivation to invest a lot of time as a team, you will definitely achieve great results. There are implementations worth pursuing, such as making application statistics available, automatic checks on container health, and complex deployments. With the right tools, you can standardize and use this across all your environments.
Scaling is, of course, the key selling point of Kubernetes, as that’s what it was ultimately designed for. You can easily spin up extra pods in your environment to give your application more power. Moreover, adding extra worker nodes is fairly easy since they only need Docker and the Kubernetes worker component. You can easily play with the number of pods and nodes. It’s also useful for system maintenance because you can quickly move all pods to another node.
A step further is auto-scaling. Here, I’d still approach it with caution, especially if you're using a cloud provider like AWS. You don’t want to wake up one morning with suddenly 30 more systems in your environment. Or at least not if you're also paying the bill :). So, first, ensure there’s some automatic scaling at the application level before you start scaling at the system level.
