Kubernetes Full Tutorial for Beginners 2026: Step by Step

Have you ever wondered how companies [music] like keep their applications running smoothly even when millions of users are accessing them all at the same

time? So, behind the scenes, modern

time? So, behind the scenes, modern applications often rely on containers running across many servers. And

managing all of those containers manually would quickly become quite overwhelming. So, this is exactly the

overwhelming. So, this is exactly the kind of problem that Kubernetes, often shortened to K8s, was built to solve.

Kubernetes is the industry standard platform for automating the deployment and scaling and management of containerized [music] applications. As software systems move

applications. As software systems move towards microservices architectures, Kubernetes acts like the sort of brain of the operation, coordinating

containers across a cluster of machines and just making sure that everything stays healthy and available to users.

Before continuing, it does help to have a basic understanding of containers and Docker. Docker packages an application

Docker. Docker packages an application and all of its dependencies into a portable image that can run pretty much anywhere. Kubernetes doesn't replace

anywhere. Kubernetes doesn't replace Docker, it just works on top of it, orchestrating those container images across multiple servers to create a distributed production-ready [music]

environment. And today, you're going to

environment. And today, you're going to learn Kubernetes by walking through the core concepts and applying them in a hands-on environment. We're going to

hands-on environment. We're going to explore the architecture of a cluster.

We'll work with [music] essential objects like pods, deployments, and services, and eventually deploy a multi-tier microservices application to

see how all of these pieces fit together in practice. But before we dive in, if

in practice. But before we dive in, if you do want to master Kubernetes in just 2 hours instead of spending weeks figuring it out all on your own, I've got a complete [music]

Kubernetes Pro Program and a community as well with everything that you're going to need. The link's in the description down below, but first, let's go ahead and get you started with the basics. Running a container on a single

basics. Running a container on a single machine is fairly straightforward, but once an application grows and then starts running across many different servers, well, then managing everything

manually just becomes really hard.

Containers need to be placed on the right machines, restarted if they fail, and then scaled when traffic increases.

Kubernetes is built to handle this complexity by coordinating containers across an entire cluster, allowing teams to manage infrastructure as one scalable system instead of many individual

servers. [music]

servers. [music] So, fundamentals focus on the transition from managing single isolated containers to managing a coordinated cluster of

machines. And this orchestration layer

machines. And this orchestration layer allows modern IT teams to treat infrastructure as a single scalable source rather than a collection of individual servers. Managing containers

individual servers. Managing containers on one server is simple, but managing them across 100 servers is impossible without automation. Kubernetes handles

without automation. Kubernetes handles the complex logic of where a container should run based on available CPU and memory across a cluster. It also ensures

high availability, scalability, and disaster recovery. So, if a container

disaster recovery. So, if a container happens to crash, Kubernetes automatically just restarts [music] it.

If traffic suddenly increases, it can launch additional container instances to handle the demand. So, this creates a sort of safety net that helps prevent outages even when hardware fails or

workloads change unexpectedly. And in

many ways, Kubernetes transforms infrastructure management from what engineers call pets to cattle. So,

instead of individually caring for each server like a pet that must be maintained, Kubernetes treats components as replaceable units that can be

automatically created, destroyed, and scaled when needed. So, this approach makes production-scale deployments far more resilient and easier to manage. So,

at the center of every Kubernetes cluster is a structured architecture made up of two main parts, the master node, also known as the control plane,

and the worker nodes. The master node acts as a sort of brain of the cluster.

It makes global decisions about [music] scheduling containers, monitoring the overall health of the system, and responding when something does inevitably go wrong. Worker nodes, on

the other hand, are the machines that actually run the application containers.

Several key components inside the control plane make this coordination possible. The API server acts as the

possible. The API server acts as the sort of front door to the entire cluster. So, every command that you run

cluster. So, every command that you run from the terminal, every configuration change, and pretty much every request to deploy an application goes through the API server. Now, behind the scenes, etcd

API server. Now, behind the scenes, etcd serves as the cluster's database of truth. It stores all configuration data

truth. It stores all configuration data and system state, so Kubernetes always knows exactly how the cluster is supposed to behave. The scheduler works

like a sort of matchmaker. When a new container needs to run, the scheduler analyzes the available nodes and then decides which machine has enough

resources to handle it. Meanwhile, the

controller manager acts as a constant sort of supervisor, just watching the cluster and ensuring that the current state always matches the desired configuration that you requested. On the

worker nodes, a different set of components handles the actual execution of applications. Kubelets, kube-proxy,

of applications. Kubelets, kube-proxy, and container runtime on worker nodes.

So, the kubelet acts as an agent on each node. It communicates with the control

node. It communicates with the control plane, and it ensures that the containers assigned to that node are actually running. The kube-proxy manages

actually running. The kube-proxy manages networking rules, making sure pods can communicate with each other across the cluster using stable IP addresses and

routing. Finally, the container runtime,

routing. Finally, the container runtime, such as containerd, is the engine responsible for actually starting and running the containerized applications.

So, all of these components, right? They

communicate through the API server, creating a continuous feedback loop. The

control plane constantly monitors the status reported [music] by worker nodes and adjusts the system when necessary.

So, this constant monitoring and correction is what allows Kubernetes clusters to remain stable, scalable, and self-healing even under heavy workloads.

Now that we understand how a Kubernetes cluster works, the next step is learning how we actually tell it what to do.

In Kubernetes, this is done through objects, and [music] these objects act as instructions that describe the desired state of your system, meaning

how many containers should be running, how they should communicate, and how users can access them. So, once these subjects are defined, Kubernetes continuously works in the background to

make sure that the real system matches that desired configuration. Objects are

the persistent entities in the system that represent the desired state of your cluster. They are essentially records of

cluster. They are essentially records of intent that tell Kubernetes exactly how you want your application to behave, from how many copies to run to how they connect to the internet. So, the

smallest unit that you can create in Kubernetes is called a pod, and while containers run the actual application code, Kubernetes does not manage containers directly. Instead, wraps them

containers directly. Instead, wraps them inside pods, and this provides a controlled environment where one or more closely related containers can actually

operate together as a single logical unit. So, inside a pod, containers share

unit. So, inside a pod, containers share certain resources such as networking and storage. For example, all containers

storage. For example, all containers inside the same pod share a single IP address and can communicate with each other using localhost. And this setup

makes it easier for helper containers, such as logging tools or monitoring agents, to work alongside the main application container. And pods are also

application container. And pods are also designed to be temporary. They're not

meant to be repaired or manually fixed when something goes wrong. So, if a pod fails, Kubernetes simply just deletes it and creates a new one to replace it. So,

this disposable nature just keeps applications running consistently without requiring manual intervention.

In real production environments, in real production environments, you typically do not manage pods directly. Instead,

you use a higher-level object called a deployment. And deployments act like

deployment. And deployments act like managers that oversee groups of pods and handle tasks such as scaling, updating, and maintaining the correct number of

running instances. For example, if your

running instances. For example, if your application suddenly receives a surge of traffic, then you can scale it by increasing the number of replicas in the deployment configuration. Kubernetes

deployment configuration. Kubernetes will automatically create additional pods to handle the increased load, and if later traffic decreases, you can just

scale the deployment back down to reduce resource usage. Deployments also allow

resource usage. Deployments also allow you to update applications safely. So,

when a new version of, say, your software is released, Kubernetes can just perform a rolling update, gradually replacing old pods with new ones, so the application remains available throughout

the process.

>> [music] >> If the update introduces problems, you can perform a rollback to instantly return to the previous stable version.

Because pods are constantly being created and replaced, their IP addresses are not permanent. And this creates a problem when other parts of your application do need a reliable way to reach them.

>> [music] >> Kubernetes solves this by using services. A service provides a stable

services. A service provides a stable network endpoint [music] that points to a group of pods. So, for external communication inside the cluster, Kubernetes uses a service type called

cluster IP. [music] And this assigns a

cluster IP. [music] And this assigns a fixed internal IP address that other applications can use to consistently reach the correct pods. [music]

When external users need access to the application, a service type called node port can be used. [music] This opens up a specific port on every node in the cluster, allowing traffic from the

public internet to reach the application. Services also include

application. Services also include built-in load balancing. So, incoming

requests are automatically distributed across all healthy [music] pods behind the service, ensuring that no single instance becomes overloaded while others remain idle. [music]

remain idle. [music] Applications often do require configuration settings, such [music] as environment variables, API endpoints, or

feature flags. Instead of embedding

feature flags. Instead of embedding these values directly in the application code, Kubernetes just allows them to be stored separately using config maps. And

config maps store non-sensitive configuration data, making it easy to update settings without having to rebuild or redeploy container images.

[music] For more sensitive information, such as passwords, authentication tokens, or encryption keys, Kubernetes provides a separate object called secrets. And

secrets allow sensitive data to be stored securely, of course, and delivered only to the specific [music] pods that require them at runtime, helping keep credentials out of application code and source

repositories. So far, we've focused on

repositories. So far, we've focused on understanding how Kubernetes works conceptually, how clusters are structured, how objects define the desired state, and how different

components coordinate with each other.

But Kubernetes is ultimately a hands-on tool, and the best way to understand it is by actually interacting with the cluster. So, here we'll use a

cluster. So, here we'll use a browser-based lab platform that already provides a working Kubernetes environment. This allows us to just jump

environment. This allows us to just jump straight into running commands and deploying applications without really worrying about setup issues. So, to get started, all you got to do is open up

your web browser and then navigate to this address that you see on your screen.

So, on the page, you'll see a blue sign in to enroll button either in the center of the screen or in the top right corner. Click this button, of course, to

corner. Click this button, of course, to unlock the learning curriculum. And you

can sign in using your email address or one of the available social media account options. After signing in, just

account options. After signing in, just complete the short account setup process required by the platform. And then, once your account setup is complete, you will automatically be redirected back to the

same page at, again, this address on your screen. But this time, you're going

your screen. But this time, you're going to see a blue enroll for free button.

And clicking this will grant you access to the Kubernetes learning environment and redirect you to the Kubernetes crash course page, where the hands-on labs are

located. So, this platform provides an

located. So, this platform provides an interactive browser-based environment that includes a simulated Linux terminal connected to a Kubernetes cluster. In

real-world development environments, engineers usually do need to install tools like kubectl, which is the command-line interface used to communicate with Kubernetes clusters, [music] and minikube, which allows

developers to run a small Kubernetes cluster locally on their own machine for testing. In this lab environment, both

testing. In this lab environment, both of these tools are already installed and configured for you, which means you can already begin experimenting with Kubernetes commands immediately.

Under the hands-on lab section here of the course page, just locate the option labeled labs kubectl. So, click this lab to open it, then press the start lab button. And the system will begin

button. And the system will begin preparing your environment, which typically takes around 20 to 30 seconds only to initialize. And once the lab finishes loading, you'll see a fully functional Linux terminal on the right

side of the screen. And this terminal behaves just like a real command-line environment used by engineers when managing Kubernetes clusters. And then,

behind the scenes, the lab environment automatically starts a Kubernetes cluster using minikube, which then bundles both the control plane, the master node, and the worker node

components together. So, this setup

components together. So, this setup allows you to interact with the cluster immediately without needing to configure multiple machines. And to begin

multiple machines. And to begin interacting with the cluster, just click anywhere inside the terminal window, so that your cursor becomes active. And at

this point, you're ready to start running Kubernetes commands. Before

deploying any applications, it is important to verify that the cluster is running properly and that the core components are communicating with each other. And in the terminal here, type

other. And in the terminal here, type the following command and press enter on your screen. So, this command on your

your screen. So, this command on your screen asks Kubernetes to list the nodes that are currently part of the cluster.

And after running it, just look at the output displayed in the terminal. You

should see a node named control-plane with a status labeled ready. And seeing

the ready status confirms [music] that the kubelet running on the node is successfully communicating with the API server in the control plane. So, in

other words, the cluster is healthy, the infrastructure is running correctly, and the environment is ready for us to begin deploying applications in the next section. So, now that the cluster is

section. So, now that the cluster is running and the environment is ready, it's now time to start working with Kubernetes in practice. So, this section focuses on applying the concepts that

we've discussed so far by deploying and connecting applications inside the cluster. And we'll begin with a simple

cluster. And we'll begin with a simple application to understand the basic workflow, and then later move on to a multi-tier voting application that demonstrates how multiple services, such

as web interfaces and background workers and databases, how all of those interact within a Kubernetes environment. So,

before running the commands, there are a couple of things to remember here while following the steps. Whenever you see bash or command, it means the command should be entered directly into the

Linux terminal in the lab environment and then executed by pressing enter. If

you need to paste a command, use the keyboard shortcut control-shift-v, which is commonly used for pasting text in Linux terminals. Make sure the commands

Linux terminals. Make sure the commands are copied exactly as shown. To begin,

go to the hands-on lab section here and click labs kubectl. Then click the start lab button. And once the lab environment

lab button. And once the lab environment loads, click the toggle terminal size button in the upper right corner of the terminal window, beside the stop lab button, to expand the terminal for

better visibility. Before starting the

better visibility. Before starting the next steps, clear the terminal so the screen is easier to follow. Now, in the terminal, just type clear and press enter. To begin, we'll deploy a simple

enter. To begin, we'll deploy a simple web server inside the Kubernetes cluster. So, for this example, we're

cluster. So, for this example, we're going to use NGINX, a widely used tool for serving websites and web applications. This will help demonstrate

applications. This will help demonstrate how Kubernetes launches containers and manages them inside the cluster. The

command needed to create the deployment will appear on the screen. So, go ahead and run it in the terminal, and if you need time to copy it, just feel free to pause the video.

So, this command that was on your screen creates a deployment named hello-world using the NGINX container image. And

once the command runs, Kubernetes automatically finds an available node in the cluster and then just starts the container. Next, we'll check whether the

container. Next, we'll check whether the application is running correctly. The

command to list the pods will also appear on your screen.

So, after running that, you should see a pod created by the deployment. And at

this stage, the application is running successfully inside the cluster, but it still isn't accessible from the outside.

So, to allow users to access the application, we need to create a service.

>> [music] >> Again, a service provides a stable network entry point that directs traffic to the pods running the application. And

the command to expose the deployment will appear here on your screen. Run it

in the terminal to create the service.

After creating the service, we can confirm that it was created correctly by listing the services in the name space.

Again, the command will appear here on your screen, and you can just pause the video if needed to copy it. So, this

will display the service details, including the port that Kubernetes assigns for external access. Even if the pod is restarted or replaced, the service will continue routing traffic to

the correct location. Another powerful

feature of Kubernetes is scaling.

Instead of upgrading to, say, a larger server when demand increases, Kubernetes allows you to run multiple copies of the same application. The command to scale

same application. The command to scale the deployment will appear here on your screen. And running it tells Kubernetes

screen. And running it tells Kubernetes to increase the number of replicas, so multiple instances of the application run at the same time. And finally, we can check the pods again to confirm that

the scaling [music] worked. After

running the command shown here on your screen, you should see [music] three pods running.

Kubernetes automatically created additional replicas of the application to distribute the workload. And if one of those pods fails, then Kubernetes will detect the issue and create a

replacement to maintain the desired number of running instances. So, now

that we've deployed a simple application, let's go ahead and move on to a little bit more of a realistic scenario. Most modern applications are

scenario. Most modern applications are not made of a single container. Instead,

they're built as a multi-tier system, where different components handle different responsibilities.

Some services manage the user interface, others process background tasks, and others store data in databases. So, here

in this example, we'll deploy a voting application made up of several services working together inside the Kubernetes cluster. This will help demonstrate how

cluster. This will help demonstrate how microservices communicate and how Kubernetes coordinates them as a complete system. To begin, go to the

complete system. To begin, go to the hands-on lab section here and select deploying voting app on Kubernetes. Then

click start lab to launch the environment. And once the lab loads,

environment. And once the lab loads, you'll see a flowchart on the screen representing the different parts of the application. Each icon in the flowchart

application. Each icon in the flowchart corresponds to a step in the deployment process, and clicking on an icon reveals the checklist of tasks needed to complete that part of the system. So

throughout this section here, the commands needed for each step will be shown on your screen. So you can just copy and paste them directly into your terminal. Before deploying the

terminal. Before deploying the application components, we first also need to create a namespace. So think of a namespace as a dedicated workspace inside the Kubernetes cluster. [music]

It keeps all the resources for this voting application grouped together, so that they don't interfere with other applications running in the same environment. And then just create the

environment. And then just create the vote namespace using the command shown here on your screen, then verify that it was created successfully. [music]

Using a namespace ensures that when Kubernetes searches for services like say the database or backend components, it only looks within this specific

environment rather than just across the entire cluster. With a namespace in

entire cluster. With a namespace in place, we can start deploying the parts of the application that our users will interact with. The voting system

interact with. The voting system includes two front end services. One

where users submit their votes, and another where they can view the results.

So let's run the command shown here on the screen to deploy both the vote application and the result application inside the namespace.

After creating the deployments, check the running pods in the terminal to confirm that both services have started successfully. And once you get all of

successfully. And once you get all of that on your screen, at this stage the applications are running inside the cluster, but they are still isolated.

They're not yet connected to other services or accessible from outside the system. We'll establish those

system. We'll establish those connections in the next steps. Behind

the scenes, the voting application does rely on backend services to process and store data. One component, Redis,

store data. One component, Redis, temporarily stores incoming votes.

Another component, PostgreSQL, acts as the database that stores the final results. So use the commands displayed

results. So use the commands displayed on the screen to deploy both Redis and the PostgreSQL database inside the namespace. Also, the database requires a

namespace. Also, the database requires a password to run correctly, which we will configure using an environment variable.

So once you get all of that, and once those services are deployed, check the running pods again to make sure that the backend component started successfully.

Containers are designed to be temporary.

So if a container stops or restarts, any data stored inside of it can disappear.

So to avoid losing important information, Kubernetes allows us to attach volumes that provide storage for the application. Using the commands

the application. Using the commands shown here on the screen, we can update the Redis and database deployments to include storage volumes. These volumes

give the containers a place to store their data while the application is running. So once you get all of that,

running. So once you get all of that, the backend services are now running.

The different parts of the application do need a way to communicate with each other. Kubernetes handles this through

other. Kubernetes handles this through services, which provide a stable internal address that other components can use to locate them. So run the commands again shown here on the screen

to expose both Redis and the database using internal services. [music]

Once created, you can list the services in the namespace to confirm they are indeed available. And once you get all

indeed available. And once you get all of that on your screen, with these services now in place, the other components in the application can easily locate Redis and the database through Kubernetes networking. The voting system

Kubernetes networking. The voting system also includes a worker service that acts as a middle layer between Redis and the database. The worker reads votes stored

database. The worker reads votes stored in Redis and then writes the final results into PostgreSQL. Deploy the

worker using the command shown here on the screen, then check the pods again to confirm that it is running correctly.

And with that, at this point the worker can communicate with the backend services because we previously created the internal service connections.

So finally, we allow users outside the cluster to access the application. And

this is done by exposing the front end services using node port, which opens specific ports on the cluster nodes.

[music] So run the commands again shown here on the screen to expose both the voting interface and the results interface. And with that, to see if

interface. And with that, to see if everything is working together, then click the check button under the task panel. All the icons on the

task panel. All the icons on the flowchart should light up green, verifying that yes, we have successfully deployed our application. All right, so the next step is making sure it's

properly configured and secure. In real

production environments, sensitive information like passwords should never be written directly inside application code or configuration files.

Kubernetes solves this problem using secrets and config maps, which allow us to store configurations separately from the application itself. First, we'll

create a secret to securely store the database password. Think of a secret as

database password. Think of a secret as a secure vault where sensitive information can be stored and accessed only by the services that need it. Run

the command shown here on the screen to create a secret that stores the PostgreSQL password for our database.

So next, we create a config map to hold non-sensitive configuration settings.

Config maps act like an instruction manual for the application. So for

example, instead of hardcoding a setting like the app's theme color directly in the container image, we can just store it in a config map, so it can be changed without rebuilding the application. Use

the command shown on the screen to create a configuration setting for the application.

And once the secret and config map are created, the next step is to inject these values into the running services.

Kubernetes allows deployments to read configuration values as environment variables. So using the command shown

variables. So using the command shown here on the screen, we can inject the config map into the vote application, so it can read the configuration settings, and then inject the secret into the

database deployment, so the database can securely access its password. And

finally, we can verify that everything now is configured correctly just by listing the resources inside the namespace.

>> [music] >> So running the command shown on the screen will display the running deployments, services, config maps, and secrets.

So at this point, the application is now fully decoupled from its configuration.

The database retrieves its password securely from the secret, while the application reads its settings from the config map. And this separation makes

config map. And this separation makes the system a lot more secure, easier to manage, and much simpler to update without having to modify the container images.

Deploying an application is only really the beginning of working with Kubernetes. In real environments,

Kubernetes. In real environments, administrators also handle what are often called day two operations, and these include monitoring the health of applications, troubleshooting errors,

and safely updating software. So

learning how to manage these tasks is what separates simply running containers from maintaining a reliable production system. Deploying an application is only

system. Deploying an application is only again really the beginning of working with Kubernetes. In real environments,

with Kubernetes. In real environments, administrators also handle what are often called day two operations, and these include monitoring the health of applications, troubleshooting errors,

and of course safely updating software.

So learning how to manage these tasks is what separates simply running containers from maintaining a reliable production system. One of the most common tasks

system. One of the most common tasks when managing Kubernetes is checking whether applications are running correctly. And a quick way to do this is

correctly. And a quick way to do this is by listing the pods in the namespace.

The command for this is shown on the screen, and this allows you to confirm whether your services are in the running state or if something is preventing them from starting.

So when a problem occurs, Kubernetes provides several tools to help identify the cause. Using the describe command

the cause. Using the describe command reveals detailed information about a specific pod, [music] including configuration details and recent system events. At the bottom of the output here, you can often find

error messages such as an image failing to download or a container failing to start. And these messages are often the

start. And these messages are often the fastest way to understand what went wrong.

Another useful troubleshooting scenario occurs when a pod becomes stuck in the pending state. So this usually indicates

pending state. So this usually indicates that the cluster does not currently have enough resources, maybe such as CPU or memory, to schedule the container. So

running the describe command again helps confirm whether resource limits or scheduling issues are causing the delay.

Kubernetes also supports health checks, which allow the system to verify whether an application is ready to receive traffic.

And one common method is a readiness probe, which periodically checks an endpoint inside the container. If the

application fails the check, Kubernetes temporarily removes it from service until it becomes healthy again. And in

this example, we use the command shown here on the screen to add a readiness probe to the running deployment.

And after applying the change, we can now confirm that the probe was added by inspecting the deployment configuration in the terminal. Keeping applications up to date is another key part of operating

Kubernetes systems. Instead of shutting down an application to deploy a new version, Kubernetes supports rolling updates. [music] So during a rolling

updates. [music] So during a rolling update, the system gradually replaces old pods with new ones, ensuring that the application remains available throughout the process.

Now, if something goes wrong during the update, say such as a bug in the new version, Kubernetes also allows you to just roll back to the previous version.

Running the rollback command restores the last stable deployment almost instantly, helping prevent long periods of downtime. In production environments,

of downtime. In production environments, it's also a very good practice to validate commands before applying them to the cluster. Kubernetes supports dry runs, which simulate a command without

actually making changes.

And this allows administrators to confirm that the configuration is correct before applying it to a live system.

So, together, these monitoring, troubleshooting, and update tools allow Kubernetes administrators to maintain healthy applications, to respond quickly to issues, and deploy new versions with

minimal disruption.

So far, we've been working with Kubernetes using individual commands in the terminal. And this approach is

the terminal. And this approach is useful for learning and quick testing, but in real production environments, teams rarely manage infrastructure this way. Instead, they shift towards a

way. Instead, they shift towards a declarative approach, where the desired configuration of the system is written in files and stored as part of the project. This makes the infrastructure

project. This makes the infrastructure easier to reproduce, easier to manage across environments, and much easier to restore if something goes wrong. In

Kubernetes, configurations are typically written using YAML files. Earlier, when

we created deployments or services using commands like kubectl create, we were using what's called an imperative approach. Imperative commands tell

approach. Imperative commands tell Kubernetes exactly what action to perform right now. A declarative

approach, on the other hand, focuses on describing the desired end state of the system. So, instead of running commands

system. So, instead of running commands one [music] at a time, you define your application's configuration inside a YAML file. Kubernetes then reads that

YAML file. Kubernetes then reads that file and ensures the cluster matches the configuration described [music] within it. Most Kubernetes configuration files

it. Most Kubernetes configuration files do follow a similar structure. They

include fields such as API version, kind, metadata, and spec, which together describe the type of resource being created and how it should behave. So, by

storing these configurations as reusable [music] files, teams can just deploy the exact same setup across different environments, such as development, testing, and production.

Another important advantage of using configuration files is that they can be stored in version control systems like GitHub. And this allows teams to track

GitHub. And this allows teams to track changes over time, to review modifications before they are applied, and see exactly who updated a configuration and when. In large

production environments, this practice, often called infrastructure as code, is essential for maintaining consistency and reliability. When running

and reliability. When running applications in production, security also becomes a major consideration here.

Kubernetes provides several mechanisms that help control access and [music] reduce potential vulnerabilities. And

one of these mechanisms is role-based access control, or RBAC. RBAC allows

administrators to define exactly what different users are allowed to do inside the cluster. So, for example, a junior

the cluster. So, for example, a junior developer might only have permission to view pods and logs, while an administrator may have permission to modify or delete resources. So, this

prevents accidental changes and limits the impact of potential security issues.

Networking rules can also be tightened using network policies. And by default, Kubernetes allows all pods to communicate with each other, but in production environments, this level of

openness can be risky. Network policies

also allow administrators to restrict which services can talk to each other.

So, for example, allowing only back-end services to communicate with a database while blocking access from public-facing applications. And finally, it is

applications. And finally, it is important to follow basic container security best practices. Containers

should never run as a root user, since this increases the risk of security vulnerabilities. It's also recommended

vulnerabilities. It's also recommended to use minimal base images when building containers, which reduces the number of unnecessary components and limits the potential attack surface that attackers

[music] could exploit. So, by combining declarative configurations with strong security practices, Kubernetes environments just become far more

reliable, maintainable, and secure, making them suitable for running large-scale production applications. And

that's a very quick look at how Kubernetes works in practice. From a

single container to a full multi-tier application, you've seen how Kubernetes coordinates services, keeps [music] systems healthy, and scales applications when demand grows. There's a whole lot

more to explore here, but the fundamentals that you've seen here are the foundation behind many modern cloud platforms. All right, thank you for watching and investing your time with me today. I'll catch you at the next one.

today. I'll catch you at the next one.