Docker and Podman are used for running containers in a standalone environment.
If you want to take it to cloud, Kubernetes is commonly used.
Kubernetes is what we call a container orchestrator platform, and it's built to run containers
in a cloud-native environment.
So what is orchestration?
Well, simple, orchestration makes that your container is running where it needs to be
running.
A cloud is normally a multi-server platform that can stretch out over a big region, and
the orchestrator makes sure that your container is running exactly where it needs to be running.
Using Kubernetes allows you to run containers in a flexible and cloud-native way.
In order to do so, Kubernetes uses different resources.
Let me make a drawing for you to talk about these resources and explain how all of them
are related together.
So Kubernetes is about running orchestrated containers.
It all starts with the container.
To add properties that allow you to manage the container, Kubernetes uses the notion
of a pod, and the pod is a minimal entity that is used by Kubernetes.
And in the pod, you can specify options for running the pod in the right location in your
Kubernetes cluster.
But the pod needs some scalability, and it needs some update strategies as well, and
that is brought by the deployment.
And that makes the deployment the most used resource for offering application access.
Now, the deployment by itself needs help as well, and that is because of what we call
decoupling.
Because let's face it, a container is based on a read-only image, and how are you going
to add your site-specific information to the deployment?
Well, first, you are going to work with what we call the PVC, the Persistent Volume Claim.
And a Persistent Volume Claim is what is normally going to reach out to get access to PV, which
is a persistent volume, and this persistent volume is offered on the cloud.
And that allows you to store your data in a way that it can be accessed independently
of the application, and it will survive if your application goes down.
Now, there are other resources as well, like, for instance, the ConfigMap.
Why do we want a ConfigMap?
Well, on Linux, you have a configuration file in the etc directory.
In your container, well, you don't want to hard-code the configuration file, because
then it wouldn't be changeable.
And that is why you are going to inject the ConfigMap in your application.
And if your configuration needs to be secured, you are going to use a secret, and inject
that as a secured alternative to the ConfigMap.
And then, still, you need to be able to access your application.
And in order to access your application, Kubernetes uses the notion of a service resource.
Now, this word is very confusing, because you would say a service resource, that's like
a system D service, no, not at all.
In Kubernetes, a service resource is like a load balancer that is giving you access
to the port IP addresses.
And that is necessary if your port has been scaled out.
If there are multiple port instances, the service resource will make sure that your
traffic is directed to the appropriate port.
And to make the picture complete, you want to reverse HTTP proxy on top of that.
And that is what is delivered by Ingress.
And on modern Kubernetes, we call that gateway API.
Gateway API or Ingress, they are receiving the HTTP and the HTTPS traffic that is coming
in.
So as you can see, quite a lot of resources play a role in Kubernetes.