However, once set up and configured properly, it's a powerful tool that can save developer time and application uptimes.

So when should one start using Kubernetes? And why?

Who? What? Where? When? Why? of Kubernetes

Who? + What?

Technically, anyone can run anything using Kubernetes. Usually, you'll find it being utilized by DevOps teams to help scale their company's services to meet incoming demand.

Where?

Kubernetes is run on a server (managing it yourself is known as "rolling your own Kubernetes") or handled by vendor or cloud service provider as a managed Kubernetes.

When?

Technically, you can start using Kubernetes on day one of building a project, but it doesn't matter when you start using it. The choice is up to the developers and the DevOps team.

Why?

The 'why' question is where it gets a little more interesting.

Without Kubernetes, launching an application of any kind requires three different parts:

  • A compiled version of the code: provided by you and built in a form that can be easily run (such as binary).
  • An operating system: this might be your computer or something you set up manually, but could also be a container or use a buildpack.
  • A start command: The command used to execute your codes such as a binary or run statement.

Kubernetes x Docker: Best Friends Forever

Whenever you hear Kubernetes, you're probably going to hear Docker in the same sentence. Kubernetes and Docker are like peanut butter and jelly-they're a perfect pair. Docker combines the three parts required to launch an application into one command. This makes it easier to deploy (or start) new applications through the creation of containers.

Containers are a critical part of the Kubernetes metaverse because they're the smallest building block of Kubernetes orchestration. Just like how atoms are the smallest bits of matter in the universe, pods are encapsulations of containers. Pods are considered a unit of one or more containers. All the containers in a pod will be co-located on the same operating system.

Scale

Kubernetes can help make scaling your application easier. It's a distributed system that can automatically spin up new pods to help balance the load of incoming requests.

For example, you've just shared your side project on ProductHunt and HackerNews. As the creator, you're responsible for maintaining your side project's uptime and making sure that it works. It's starting to pick up popularity, and you see that your previous configuration is starting to max out at its ability to stay running. Did I mention that your project just blew up on Tiktok, and you've gone from 100 visits per day to over 10,000? It also just hit top of HackerNews - everyone is talking about it.

With the influx of users trying out your side project, you need to scale - fast.

Prior to implementing Kubernetes, you would need to go to your hosting site (either via a website for the cloud or on premises for non-cloud servers), manually provision the servers, run the containers, and set up the reverse proxies to handle incoming router traffic. With Kubernetes, this process is mostly automated. Since you were conveniently creating this side project to try to learn Kubernetes, you were prepared. To scale with the huge influx of demand, you're able to quickly update your Kubernetes config file to begin rolling out scaling changes for your side project.

By the way, New Relic 's Kubernetes

If you've just set up your first Kubernetes cluster or are looking to understand the Kubernetes cluster you've been running, look no further. I'm a visual learner, and having a tool like New Relic is critical for helping create awesome visualizations for your clusters.Learn more about our visualization tools and sign up for a free account today.

We've done it

As a developer, it's easy to forget to slow down, to get frustrated when learning new topics, and to gloss over asking why when one is confused. Hopefully, by reading this article, you've gained a bit more practical knowledge about Kubernetes and why you keep hearing about it everywhere you go.

Attachments

  • Original document
  • Permalink

Disclaimer

New Relic Inc. published this content on 26 October 2021 and is solely responsible for the information contained therein. Distributed by Public, unedited and unaltered, on 26 October 2021 19:05:09 UTC.