- [Instructor] In the last section,
I covered the overall Kubernetes cluster architecture.
In this section, we'll take a deeper look
at some of the components and concepts
that one uses on worker Nodes
to build applications and Kubernetes.
This is another way to look at the same architecture,
but from a cluster perspective.
From this perspective, the Master is responsible
for managing the cluster.
It coordinates all the activities in the cluster
and communicates with the Nodes to keep Kubernetes
and your applications running.
The Node serves as a worker machine
in the Kubernetes Cluster.
One important thing to note is that this Node
can be a physical computer or a virtual machine.
The Node has the following requirements.
Each Node must have a Kubelet running,
container tooling, like Docker,
a kube-proxy process running,
and a process like Supervisord,
so it can restart components.
I'll go over more details of the specifics
of these components in a later section.
One thing to note is that if you're using
Kubernetes in a production like setting,
it's recommended that you have
at least a three Node cluster.
For this course, we will use Minikube,
which is a tool run Kubernetes locally.
It's a lightweight Kubernetes implementation
that creates a virtual machine, on your local box,
and deploys a simple cluster containing
of one single Node.
Your applications run on Nodes,
so let's take a look at the most basic construct
needed to build a Kubernetes app.
This is called a Pod.
In the Kubernetes model, a Pod is the simplest unit
that you can interact with.
You can create, deploy, and delete Pods,
and it represents one running process in your cluster.
A Pod contains the following things.
Your Docker application container,
storage resources, a unique network IP,
and options that govern how the container should run.
In some scenarios, you can have multiple docker containers
running in a Pod, but a Pod represents one single unit
of deployment, a single instance of an application
in Kubernetes that's tightly coupled and shares resources.
Pods are designed to be ephemeral, disposable entities.
I never create Pods just by themselves
in a production application.
I only do that when I need to test whether
the underlying containers actually work.
Pods also don't self-heal.
If a Pod dies, for some reason,
it will not be rescheduled.
Also, if a Pod is exited from a Node
because of lack of resources, it will not be restarted
on different healthier Nodes.
There are higher level constructs to manage
and add stability to Pods, called controllers.
So pro-tip, don't use a Pod directly.
Use a controller instead, like a deployment.
Through its life-cycle, a Pod has the following states.
Pending, which means that the Pod
has been accepted by the Kubernete system,
but a container has not been created yet.
Running, where a Pod has been scheduled on a Node,
and all of its containers are created,
and at least one container is in a running state.
Succeeded, which means that all the containers in the Pod
have exited with an exit stat of zero,
which indicates successful execution,
and will not be restarted.
A failed state, which means all the containers in the Pod
have exited and at least one container has failed
and returned a non-zero exit status.
Or, my favorite, which is the CrashLoopBackOff.
This is where a container fails to start, for some reason,
and then Kubernetes tries over and over and over again
to restart the Pod.
Now that we've discussed two basic concepts, Nodes and Pods,
in the next video, we'll build on these concepts
and talk about deployments, replicacets, and services.