In this video, you will understand why Kubernetes dominated the cloud and how it quickly became the
de facto standard tool for managing cloud native applications.
In 2015, the term cloud native started getting really popular because it emphasizes applications designed
specifically for cloud environments.
A cloud native app is one that's distributed into many applications called microservices.
You don't want your app to be this one big, chunky and clunky, hard to update monolith.
Instead, you want to split it into many microservices, where each one performs a specific task and
runs inside of a container.
Ideally, a container is a lightweight environment that isolates your application by ensuring that it
only runs with the resources and dependencies that it needs.
This containerization allows your app to run reliably anywhere, whether that's your laptop or some
cloud provider, which is what makes containerized microservices truly cloud native.
Their ability to run reliably anywhere across different environments, on top of the fact that they're
ideal for the clouds is need to scale very quickly and deploy very fast.
Now, the microservice architecture isn't perfect.
Every benefit comes with a drawback in the sense that the more microservices you have, they become
harder to manage.
Think about things like resource allocation.
How do you efficiently distribute memory and CPU across numerous microservices?
That requires a lot of manual orchestration.
Think about resiliency.
When a service becomes unresponsive for whatever reason, what mechanisms can we employ to ensure that
the container is automatically resurrected and restarted back to a healthy state?
Think about things like load balancing.
If an app is getting lots of traffic, it can eventually run out of memory or CPU.
How do you dynamically scale up instances of that microservice and balance the load to ensure that traffic
is distributed equally among all your application instances.
These are just a few of the many considerations that you need to be mindful of when managing containers,
because deploying containers is just the beginning.
Anybody can do that.
That's the easy part.
The real challenge and expertise lies in efficiently managing and orchestrating your containers at scale.
Well, let's go back to 2014 when an engineer from Google revealed that they were releasing 2 billion
containers a year.
They had their own in-house container orchestration tool called Borg that dealt with all of these problems
and automated things like scaling, resiliency, resource orchestration, load balancing, among many
other features.
And based on their success with Borg, Google open sourced the container orchestration platform Kubernetes
that same year.
And because of Google's credibility, um, Kubernetes is now the de facto standard tool for container
orchestration.
So let's assume you have Kubernetes hosted on AWS, Azure or Google Cloud.
Then Kubernetes can be described as a software that runs across many virtual machines.
If you have Kubernetes hosted on your own servers on premise, which is typical to government agencies
that require more security than Kubernetes, can be described as a software that runs across many physical
servers.
Now, regardless, these machines in the world of Kubernetes we refer to as nodes.
And these nodes, these machines, they collaborate.
They work together under the supervision of Kubernetes to manage your container workloads.
They come together to form a unified Kubernetes cluster that can orchestrate your containers at scale.
So in a Kubernetes cluster, some machines are designated as master nodes, forming the brains of the
operation, while the other machines, the other nodes are worker nodes, the master nodes.
They make decisions about when and where your container workloads will run, while the worker nodes,
they have the infrastructure to actually run your container workloads.
Let me dive a bit deeper.
So the pod in Kubernetes is the smallest deployable unit, meaning you can't deploy containers directly.
They must be wrapped in a pod.
Now, to deploy an application, I can simply specify a configuration that declares what my container
will be called and the image a prebuilt package of my application, source code and dependencies from
which the container will be created, and the resources that the application needs in order to run like
the CPU and memory, I simply have to declare this configuration, and upon submitting it to the cluster,
the Kubernetes control plane just springs into action.
But ultimately, what I wanted to convey is not necessarily what's going on behind the scenes, but
show you that this process really illustrates.
Kubernetes is declarative nature.
We simply declare, we simply state what we want.
And behind the scenes, there are so many moving parts where Kubernetes manages the complex details
of deployment, resource allocation, and maintenance.
It also goes further in orchestrating the discovery of these services.
Every pod has a virtual IP address by which it can be accessed, by which it can be connected to.
But pods in Kubernetes are ephemeral, which means they, um, they get destroyed or recreated very
often.
That's why Kubernetes offers a primitive called a service that specifically binds to pods with a certain
label like great submission, and regardless of their individual IP address, all great submission pods.
They share this label, which effectively allows the service to consistently route traffic to them.
And not only do services in Kubernetes make it really easy to connect to our applications, they also
act as natural load balancers if multiple instances of the Great Submission app are running simultaneously,
the service will evenly distribute incoming traffic among them, and this ensures that the load is balanced
across all available pods.
Okay, and now one of the most powerful features that Kubernetes provides is storage orchestration.
Manually provisioning storage for your databases is really, really hard work.
Kubernetes automates that for you.
For each database instance, Kubernetes allows you to define your storage requirements in a persistent
volume claim.
When the Kubernetes control plane behind the scenes sees your persistent volume claim your PVC, it
takes on the burden of looking through all of the nodes in your cluster, every machine in your cluster,
and within one of them, Kubernetes will try to find a physical piece of storage and create a persistent
volume linked to your claim.
This allows any data that gets saved to your MongoDB database to be redirected to a persistent volume,
to a durable piece of storage that lives inside of some node.
And what's really powerful here is that it doesn't matter where your Kubernetes cluster is deployed,
be it AWS, Azure, or Google Cloud, Kubernetes abstracts away the underlying infrastructure.
It itself is going to take on the burden of scanning every node for that piece of storage and provision
it for the container that needs it.
Now, speaking of platform is one of Kubernetes biggest selling points is the fact that it's vendor
neutral and it works the same way.
Regardless of whether your cluster is deployed on AWS, Azure, Google Cloud or on premises.
Kubernetes abstracts away the underlying infrastructure, which means you can define your applications
as configuration once and deploy them anywhere Kubernetes runs.
In other words, no more vendor lock in.
I want to finalize this video by emphasizing that deploying your application on a Kubernetes cluster.
It automates very powerful mechanisms that are needed to manage and orchestrate the life cycle of your
containers at scale.
Kubernetes handles things like service discovery, load balancing, resource management, storage,
orchestration, as you just saw, and many, many other complex tasks that are challenging to implement
on your own.
So by abstracting away all of these intricacies, Kubernetes.
Kubernetes lets you focus on just developing your cloud native app while it takes on the burden, while
it takes care of the operational heavy lifting.
That is why Kubernetes dominated the cloud and became the de facto standard for managing cloud native
applications across virtually every major platform.
I hope you enjoyed this video.
Make sure to do the upcoming quiz to really solidify the concepts that were discussed in this lesson,
and I will see you there.