If you zone out every time someone mentions “Kubernetes,” “containers,” or “pods,” this article is for you. No complex diagrams involved!
As a front-end developer, you don’t have to know how to configure an infrastructure from scratch. However, if you have a basic understanding of how it works, you can deploy and rollback your applications more independently while also being more informed during conversations about this topic.
Let’s start with web searching what Kubernetes is.
Kubernetes is an open-source container-orchestration system for automating computer application deployment, scaling, and management.
—Wikipedia
OK, but what is a container?
Simply put, a container is like a virtual computer that you can create, use, destroy and reboot remotely.
Now imagine this computer is actually in a cloud, running alongside thousands of other virtual computers. And all of this runs in a real computer which is powerful as heck. Your computer is now a container in the cloud.
But wait — how will you create and control this virtual computer? How will it communicate with other computers in the same cloud? And how will it communicate with the world? Sounds like you need a way to orchestrate all of this. Hence: our maestro, Kubernetes (or K8s for short)!
You may have also heard the term pods. What are those, and where do they fit here? Well, simply put, pods are groups of one or more containers. They are the smallest deployable unit in K8s, like an atom.
Imagine you’re building a WordPress website and you need a computer running PHP and a MySQL database. Running both in the same computer might be too heavy; so you could instead create one container for PHP, one for MySQL, and K8s will help make them communicate.
Then, you’d group these two containers in a pod, which represents the entire application. That means you can now start and kill an entire application through pods.
You would likely not create just one pod alone to deploy an app in production, though — there‘s more that we don’t need to cover right now, but you can read more about pods in the K8s documentation.
Now’s a good time to ask: what happens when you deploy an app in this setup?
K8s creates a new pod, redirects the traffic to it, and when it‘s sure everything‘s working, it kills the old pod. Again, more entities are involved to control and redirect requests, but we’re leaving that out today.
However, sometimes the deploy breaks something and we have to rollback our application to the previous version. Imagine everything’s on fire, and we have to start all of those computers from scratch — install Linux, Node, Git, clone the repository, install dependencies, build the app… that would take forever! If only there was a faster way, like taking a snapshot from the past to quickly restore everything to…
Enter: images! You probably have heard this term a lot too. An image is like a backup of a container with everything already installed and configured. A new image is generated with your Continuous Integration (abbr>CI) every time you push to the main branch of your repository, and it‘s then replicated into new containers when they’re created.
And what are they good for? Well, mainly two things: the first one is restoring to the previous image quickly, like our example above. But they‘re also useful when your website has a bunch of traffic and just one computer won’t be able to handle it.
When you have an image, you can create as many identical containers as you want and replicate that image across all of them, serving the exact same contents.
All done! We just covered the basics on how the infrastructure of an application works, and now hopefully you can extrapolate into whatever tools your project is using.
Many thanks to Eduardo Shiota for enabling me to explain this!
