SPEAKER 1: My friend Kelsey Hightower once said, containers
are the price of admission to using Kubernetes.
So to get started with Kubernetes,
we'll need to dive deeper into what containers really are.
With a whole universe of things to learn,
it's important to start with the essentials.
Let's go over the concepts that make
Kubernetes usable, scalable, and just downright awesome.
Are you ready?
So Kubernetes is a container orchestrator.
Last time you said that containers
were packaged up services.
What does that actually mean?
SPEAKER 2: Yeah, containers were built
to deploy smaller services with isolation and consistency.
But they're not actually a new concept.
Containers are based on some underlying concepts
from the Linux kernel--
Namespaces and Cgroups.
SPEAKER 1: Right, Namespaces make sure
that individual processes can't see
the details of other processes.
And Cgroups control how much resources a process
can use, like CPU memory.
SPEAKER 2: These two concepts are all
about giving a process isolation,
protecting it from interfering with other processes,
as well as protecting itself from others.
SPEAKER 1: Virtual machines can give us a similar level
of isolation, but only by packing the whole operating
system with it.
For plenty of applications, the OS isn't necessary.
And it certainly takes up a lot of resources.
Containers, on the other hand, only focus
on the application and its dependencies,
making them more lightweight.
Now apps don't need to worry about
if some developer had hard-coded Python 2.7 into the path
variable.
SPEAKER 2: That's an oddly specific example.
But yes.
There's actually a few different container run times.
But one of the most popular is Docker.
They built an API that helped app developers build containers
and a platform to run them the same way regardless of which
machine they run on.
SPEAKER 1: Right.
It's all about letting the app developer define what they want
the runtime to look like instead of spending time messing around
with the kernel.
This is all done in a Docker file.
Why don't we zoom in on one?
SPEAKER 2: Good idea.
If you were working on a simple Flask app,
your Docker file might look like this.
The first line is the base image the app should use.
You can choose from all sorts of base images.
So you can choose one that has exactly what you
need with less overhead, making your container smaller.
SPEAKER 1: Next, these lines so the container
what commands to run when being initialized.
Your Flask app is definitely going to need Python.
So this installs Python, Pip, and Flask.
SPEAKER 2: Now the Copy command will
grab files from your local environment
and copy them into the container.
So your local app.py file gets copied to /opt/app.py.
And the container now has your app files.
SPEAKER 1: And finally, the Entry Point command
lets your container run as an executable,
actually starting up the Flask application.
With just a few lines, you've created a container.
SPEAKER 2: Awesome, but--
SPEAKER 1: But?
SPEAKER 2: But you would still have
to manually deploy the container,
manage it, and handle situations like if the container goes down
or if you want to roll out an upgrade to your app code.
SPEAKER 1: And now we've come back to Kubernetes.
Kubernetes takes care of managing your containers,
no matter if you have one or 1,000.
Just like how your Docker file explains
what you want your container to do,
you can configure Kubernetes for what you
want your whole cluster to do.
You might hear this called the desired state.
SPEAKER 2: And that's probably the coolest thing
about Kubernetes.
You tell it what the desired state for the cluster is,
and it automates everything from pods, nodes, to load balancers,
and more.
SPEAKER 1: Whoa.
Hold on.
That's a lot of new stuff.
Let's start with the essentials.
We were just talking about containers.
So what's a pod?
SPEAKER 2: A pod is like a collection
of multiple containers, sort of a pseudo-application.
It could just be one app, or it could
be multiple different ones that need to work together.
For example, let's go back to your Flask app.
SPEAKER 1: OK.
So I know how to build a container.
How do we turn this into a pod?
SPEAKER 2: Well, if that's your desired state,
we can tell Kubernetes to make it happen.
Here's a YAML file that gives the desired state for a pod.
This metadata section gives a way for Kubernetes
to group pods and other resources together.
And we'll dive deeper into that later.
For now, the key part is this Spec section.
SPEAKER 1: Here's where you name the pod
and tell it which image to use.
Since this is a simple pod.
Your container is the only one running here.
There's also a port section so the container
can be accessed through the web on the default ACT port 80.
SPEAKER 2: Once this config is put into a Kubernetes cluster,
Kubernetes knows what you want to do
and is in charge of ensuring that your actual state matches
your desired state.
SPEAKER 1: That's a great start, but where is
the pod actually going to run?
SPEAKER 2: For that, we'll need to talk more
about nodes and deployments.
Let's cover that in the next episode.
SPEAKER 1: Sounds good.
So today, we covered more about containers
and why they became so popular.
SPEAKER 2: Then we started to talk about how Kubernetes
works with containers.
But there's still plenty more to cover.
SPEAKER 1: Wow.
That was a lot of great info on containers.
But now, we need to figure out how they run.
Stay tuned, everybody.
If you want to get hands on, check out
the link in the description.
And if you enjoyed the episode, subscribe for more.
[MUSIC PLAYING]