Now that we created our mini-cube setup,
and we there for have this virtual machine
with our Kubernetes cluster up and running,
we can start interacting with that cluster,
and we can start sending commands to that cluster
to get Kubernetes to do something.
And in order to start doing that,
we need to understand how Kubernetes works internally.
And with that, I don't directly mean
how the architecture looks like
and how such a Kubernetes cluster looks like,
but which kind of commands, which kind of language
Kubernetes understands, to then for example,
create a new pod and start a new container.
And here, it's important to understand and to keep in mind
that Kubernetes works with so called objects.
That's just how it's named.
Kubernetes knows a couple of objects, for example,
it knows pods, it knows deployments, services, volumes,
and way more than that,
and we're going to see the most important objects
in action in this and the next modules.
Now, the idea behind these objects,
is simply that you can create such an object
by executing a certain command.
And then Kubernetes will take that object created by you,
which of course is just a thing in code in the end,
and it will then do something based
on the instructions encoded in that object, you could say.
And these objects can actually be created
in two different ways, imperatively or declaratively.
And we're going to see both ways in action,
we're going to start with the imperative approach.
But we'll also see what the difference is
and which approach is preferable.
So that's how Kubernetes basically works.
It wants such objects,
which then leads to Kubernetes doing something.
And now when it comes to these objects,
there are a couple of key objects,
which we work with all the time,
for example, the pod object.
A pod in Kubernetes, is that smallest unit Kubernetes,
knows and interacts with.
And you do know that pod from the architecture slide
I showed you earlier.
Kubernetes creates pods and pods then hold containers,
and Kubernetes manages these pods
and therefore the containers for you.
So indeed, the idea behind a pod is that it contains
and runs one or multiple containers.
Both is possible, you can have one container in a pod,
or multiple containers.
Though, typically you have one container per pod.
That's the most common use case and scenario,
but both would be possible.
And if you wanna tell Kubernetes,
that it should create a pod,
run a container and do that on some worker node
in the cluster.
You would tell Kubernetes to do that,
by creating a pod object in code or with help of a command,
and sending that object to Kubernetes.
That's how you can think about that.
Now, pods are not just there to run one
or multiple containers though,
they can also hold shared resources
which these containers might utilize,
most importantly volumes.
Though I will come back to volumes and Kubernetes later,
because that is definitely something
we can also dive in deeper.
And also very important, pods of course,
also are part of the cluster
and therefore it can communicate with our pods
or the outside world.
But by default, a pod has a cluster internal IP address.
Now that is something which we'll be able to change
or we'll be able to communicate with pods nonetheless,
even from outside the cluster.
But by default, a pod has a cluster internal IP address,
which can be used to send requests to that pod
and there for to the containers
running in the pod, for example.
Now if you have multiple containers in one of the same pod,
I can also tell you right away that these containers
will be able to communicate with each other
by using the local host address.
And if you followed along with the AWS ECS lectures
in the deployment section, before this section here,
if you followed along there,
you might remember that with AWS ECS,
we also had that concept of tasks which held our containers.
And if you had multiple containers,
in one and the same task,
these containers were also able to communicate
with each other through localhost.
And indeed, a task in AWS ECS
is very similar to a pod in Kubernetes.
This is not something you necessarily need to know,
since Kubernetes is not related to AWS ECS at all.
But it is something I wanna tell you here,
because we covered AWS ECS in the course.
So knowing that analogy is definitely something
which is, well, worth mentioning I would say.
Nonetheless, I will have a closer look at pod networking
and pod volumes later in the course.
For the moment, let's just focus on the fact
that we have this pod object,
and that we can basically tell Kubernetes to create a pod,
run a container, and place that pod on some worker node
in the cluster, by creating such a pod object,
and sending it with a command to the Kubernetes cluster.
But there are two important things to understand
and keep in mind about pods.
The first important thing to understand
is that pods are ephemeral,
which basically means they don't persist.
If a pod is replaced or removed by Kubernetes,
all the resources in the pod,
for example, data stored and created by a container is lost.
Now, just as with containers and volumes,
there are ways of persisting data,
but by default, it's lost.
And that's not a bug, but it's a deliberate design decision.
And this is important to understand and keep in mind.
It's also very similar to the core idea behind containers,
if you would think about it though.
Containers also work like this.
If we launch a container,
we can run our application in there.
And this application could for example,
also create and store files.
But if a container is then removed thereafter,
and we rerun the container based on the same image,
we still get a different container,
and all the data which was in the previous container
will be lost.
And it's the same here for pods.
Because after all,
pods are just a tiny wrapper around containers.
And they share many of the core concepts of containers,
for example, the fact that they are ephemeral,
and that therefore we lose all the state
if they are removed or replaced.
In addition, and that's also very important to understand,
when working with Kubernetes,
we can create pods on our own
and start them on some worker node in our cluster,
but that's typically not what we will do.
Instead, we want Kubernetes to manage these pods for us,
We want Kubernetes to automatically create
and remove and replace them.
For example, if the application running in a pod fails,
we want Kubernetes to do all of that,
because that is the core idea behind using Kubernetes.
If we wouldn't use Kubernetes
to manage the deployed application for us
and to replace failing pods,
then we could just manually run a container
on some instance which we own, with just a Docker.
We wouldn't need Kubernetes then.
The entire idea behind using Kubernetes
is that it also manages the deployment for us.
And that's why we typically don't just create pod objects
and send them to the cluster,
but why we create controller objects,
specifically the deployment object,
which then actually will create pods for us.
So therefore, let's next have a look at this
deployment object, and let's understand how that works.