What Is Kubernetes?

Welcome to Kubernetes Foundations! In this course, you'll learn how to work with Kubernetes, one of the most important technologies in modern software development. If you've heard about Kubernetes but aren't quite sure what it does or why it matters, you're in the right place.

Imagine you've built a web application that's becoming popular. At first, running it on a single server works fine. But as more users arrive, you need to run multiple copies across many servers, ensure the application keeps running if a server fails, and update without causing downtime. Managing all of this manually becomes incredibly complex. This is where Kubernetes comes in — it automates the deployment, scaling, and management of containerized applications, handling the complex work of distributing your application, restarting failed containers, and managing updates while keeping everything running smoothly.

In this lesson, we'll explore what Kubernetes is, how it compares to older ways of deploying applications, and how its core components work together. By the end, you'll have kubectl (the Kubernetes command-line tool) set up and ready to use, and you'll verify that you can connect to a Kubernetes cluster.

To understand why Kubernetes exists, it helps to look at how application deployment has evolved over time.

Traditional Deployment ran applications directly on physical servers. If you wanted to run a web application, you'd install it on a server along with all its dependencies. This approach had significant drawbacks:

• Applications could interfere with each other (version conflicts between shared libraries)
• Resource allocation was inefficient — you couldn't easily control CPU or memory usage per application
• Scaling required purchasing and configuring new physical servers

Containerized Deployment solved many of these problems. With containers (like those created with Docker), you package your application with all its dependencies into a single unit. Each container runs in isolation, so applications don't interfere with each other. Containers are also lightweight and start quickly, making them much more efficient than running separate virtual machines for each application.

However, containers alone don't solve everything. When you're running dozens or hundreds of containers across multiple servers, you face new challenges: How do you decide which server should run each container? What happens when a container crashes? How do you update containers without causing downtime? How do you allow containers to communicate with each other? This is the orchestration gap — the space between having containers and actually managing them at scale.

Kubernetes fills this gap by providing a complete orchestration platform. It automatically schedules containers onto available servers, restarts failed containers, manages networking between containers, handles updates and rollbacks, and scales your application up or down based on demand. Instead of manually managing individual containers, you tell Kubernetes what you want your application to look like, and it makes it happen.

Now that you understand why Kubernetes exists, let's look at how it's structured. Kubernetes uses several key components that work together to manage your applications.

At the highest level, Kubernetes runs on a cluster — a set of machines (physical or virtual) that work together to run your applications. Think of it as a pool of computing resources that Kubernetes can use.

The cluster has two main parts:

The Control Plane acts as the "brain" of the cluster. It makes decisions about where applications should run, when to start or stop containers, and how to respond to failures. When you tell Kubernetes what you want, the control plane works continuously to make the actual state of your cluster match your request.

Nodes are the worker machines that actually run your applications. Each node can be a physical server or a virtual machine, providing the CPU, memory, and storage your applications need. A typical cluster has multiple nodes, allowing Kubernetes to distribute your applications across many machines for better performance and reliability.

On these nodes, Kubernetes runs your applications inside Pods — the smallest unit you can deploy in Kubernetes. While a Pod can contain multiple containers, most commonly it contains just one. You can think of a Pod as a wrapper around your container that provides additional features like networking and storage.

Here's how these components work together:

1. You use kubectl to tell the control plane what you want (for example, "run three copies of my web application")
2. The control plane decides which nodes should run these Pods and instructs those nodes accordingly
3. The nodes start the Pods and keep them running
4. If a Pod fails, the control plane notices and starts a replacement

This continuous cycle of monitoring and adjusting ensures your applications stay healthy and available.

To interact with a Kubernetes cluster, you need a way to communicate with the control plane. This is where kubectl comes in. While there's no single rule, the name is most commonly pronounced "cube control," though you'll also hear "cube cuddle," "kube C-T-L," or "kube cuttle," and it's the primary command-line tool for working with Kubernetes.

Think of kubectl as your remote control for Kubernetes. Just as you use a remote to tell your TV what to do, you use kubectl to tell Kubernetes what you want. When you run a kubectl command, it sends a request to the control plane's API server over HTTPS. The control plane processes your request and sends back a response.

Key characteristics of kubectl:

• Command structure: kubectl is followed by an action (like get, create, or delete), then the resource type (like pods or nodes), and finally any additional details or options.
  • Example: kubectl get nodes asks Kubernetes to show you all the nodes in your cluster.
• It's a messenger, not a doer: kubectl doesn't create or manage resources directly — it sends your requests to the control plane, which does the actual work
• Location-independent: You can run kubectl from anywhere (your laptop, a server, or even a phone) as long as you can connect to the cluster's control plane

This separation between the command-line tool and the control plane gives you flexibility in how and where you manage your Kubernetes clusters.

Before you can use kubectl, you need to install it on your machine. If you're working on your own computer, you'll need to download and install kubectl for your operating system:

• macOS: Use Homebrew with brew install kubectl
• Linux: Download the binary directly from the Kubernetes website
• Windows: Use Chocolatey with choco install kubernetes-cli or download the executable manually

However, since you're taking this course on CodeSignal, you don't need to worry about installation. The CodeSignal environment comes with kubectl pre-installed and ready to use. This means you can focus on learning Kubernetes without spending time on setup. That said, understanding how to install kubectl is valuable for when you want to work with Kubernetes on your own devices outside of this course.

In addition to kubectl, you need a Kubernetes cluster to connect to. In real-world scenarios, you might use cloud providers like Google Kubernetes Engine, Amazon EKS, or Azure Kubernetes Service, or run a local cluster using tools like Minikube or kind. For this course, we've already created a cluster for you in the CodeSignal environment that's running and ready to use, allowing you to jump straight into working with Kubernetes.

Now that you understand the basics and have your environment ready, let's verify that everything is working correctly. We'll run three commands that will confirm kubectl is installed, that it can connect to your cluster, and that your cluster has nodes ready to run applications.

First, let's check that kubectl is installed and see which version you have. Run the following command:

kubectl version --client

This command asks kubectl to report its version. The --client flag tells it to only show the version of kubectl itself, not the cluster (which we'll check next). You should see output similar to this:

Client Version: v1.28.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3

The exact version numbers might be different, but as long as you see version information, kubectl is installed correctly. The version number follows the format v1.28.2, where the numbers represent major version, minor version, and patch version.

Next, let's verify that kubectl can connect to your cluster. Run this command:

kubectl cluster-info

This command asks the cluster to provide information about itself. If kubectl can successfully connect to the control plane, you'll see output like this:

Kubernetes control plane is running at https://127.0.0.1:45678
CoreDNS is running at https://127.0.0.1:45678/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

This output tells you where the control plane is running (the HTTPS address) and shows that essential cluster services like CoreDNS are active. The specific address will vary depending on your cluster setup, but the important thing is that you see confirmation that the control plane is running.

Finally, let's look at the nodes in your cluster. Run this command:

kubectl get nodes

This command asks Kubernetes to list all the nodes in your cluster. You should see output similar to this:

NAME                      STATUS   ROLES           AGE   VERSION
intro-k8s-control-plane   Ready    control-plane   5m    v1.28.0

This output shows you each node in your cluster. The NAME column shows the node's name. The STATUS column indicates whether the node is ready to run Pods — you want to see Ready here. The ROLES column shows what role the node plays in the cluster. In smaller clusters, you might see a node that acts as both the control plane and a worker node. The AGE column shows how long the node has been running, and VERSION shows which version of Kubernetes the node is running.

In this example, we have one node named intro-k8s-control-plane that serves as the control plane. In a production cluster, you'd typically see multiple nodes, but for learning purposes, a single-node cluster works perfectly fine.

Congratulations! You've taken your first steps into the world of Kubernetes. Let's recap what you've learned in this lesson.

You now understand why Kubernetes exists — to solve the orchestration gap when managing many containers across multiple machines. You've seen how deployment evolved from physical servers to containers, and why containers alone aren't enough for large-scale applications. You also learned about Kubernetes architecture: clusters provide resources, the control plane manages the cluster, nodes run your applications, and Pods are the smallest deployable units.

You met kubectl, the command-line tool for interacting with Kubernetes, and verified your environment by running kubectl version --client, kubectl cluster-info, and kubectl get nodes.

Next, you'll get hands-on practice running these commands and exploring your cluster, building the skills to deploy and manage applications with Kubernetes.