In the previous lessons, you created individual Pods with unique names like nginx-configured and nginx-broken. Each Pod had its own manifest file, and you managed them one at a time using their specific names. This approach works fine when you're learning or running a small experiment, but it breaks down quickly in real-world scenarios.

Imagine you're running a production application with 50 Pods spread across different versions, environments, and teams. How do you find all the Pods running version 2 of your app? How do you identify which Pods belong to the staging environment versus production? Relying on unique names becomes impossible because you'd need to remember or document every single Pod name.

Labels solve this problem. They are human-readable tags that you attach to Pods (and other Kubernetes resources) to organize and group them. Instead of tracking individual Pod names, you tag Pods with meaningful information like which application they belong to, what version they're running, or which team owns them. Then, you can query and filter Pods based on those tags. This lesson teaches you how to add labels to Pods and use them to organize your resources effectively.

Labels are key-value pairs that you attach to Kubernetes resources in the metadata section of a manifest. They look like this: app: demo or version: v1. The key is on the left side of the colon, and the value is on the right. You can attach as many labels as you want to a single Pod, and multiple Pods can share the same labels.

Labels serve as organizational metadata. They don't change how a Pod runs or what containers it contains. Instead, they provide a way to categorize and group resources based on characteristics that matter to you and your team. Common uses include tracking which application or project a Pod belongs to (app: demo, app: payment-service), tracking versions (version: v1, version: v2), tracking environments (env: production, env: staging), and tracking ownership (team: backend, team: frontend).

The power of labels comes from their flexibility. Unlike Pod names, which must be unique within a namespace, labels can be shared across many Pods. You might have 20 Pods all labeled with app: demo because they all belong to the same application. You might have 10 of those labeled version: v1 and 10 labeled version: v2 because you're running two versions side by side. Labels let you slice and organize your Pods in whatever way makes sense for your use case.

Let's create three Pods and organize them using labels. In real-world scenarios, you'll often manage related Pods across multiple separate files. This approach makes it easier to version control individual components, update them independently, and organize your configuration by component or service.

Each Pod will have two labels: app to indicate which application it belongs to, and version to indicate which version it's running. All three Pods will have app: demo because they're all part of the same demo application. Two Pods will have version: v1, and one will have version: v2 to simulate running multiple versions of the same app.

Create a file called nginx-one.yaml:

Let's break down what's new here. The metadata section now includes a labels field. This field contains key-value pairs where each key is a label name and each value is the label's value. In this case, we're setting app: demo and version: v1. The rest of the Pod definition is the same as what you've seen before: a single container running nginx version 1.25 with port 80 exposed.

Now, let's create the second Pod in a separate file. Create nginx-two.yaml:

Now that your Pods have labels, you can use label selectors to filter and find specific groups of Pods. Instead of listing all Pods and manually looking for the ones you care about, you can ask Kubernetes to show you only the Pods that match certain label criteria.

The -l flag (short for --selector) lets you filter Pods by label. Let's find all Pods that belong to the demo application:

You'll see:

All three Pods appear because they all have the label app: demo. This query answered the question "show me all Pods for the demo application" without requiring you to know or remember the specific Pod names. If you had 50 Pods in your cluster but only 3 belonged to the demo app, this command would show you just those 3.

Now, let's filter by version. Show only the Pods running version 1:

You'll see:

Only nginx-one and nginx-two appear because they're the only Pods with version: v1. The nginx-three Pod is excluded because it has version: v2. This is useful when you want to check the status of a specific version of your application or perform operations on just that version.

You've learned how to organize Pods using labels, which are key-value pairs that you attach to resources in the metadata section. You created three Pods in separate YAML files, tagged them with app and version labels, and used label selectors to filter and query those Pods. Commands like kubectl get pods -l app=demo and kubectl get pods --show-labels let you find and inspect Pods based on their labels rather than their individual names.

Right now, labels serve as a human-friendly organizational tool. They help you and your team understand which Pods belong to which applications, versions, or environments. But labels have a second, more powerful purpose that you'll explore in the next course: machine automation. Kubernetes resources like Deployments and Services use label selectors to automatically manage groups of Pods. A Deployment might say "manage all Pods with app: demo and version: v1" and automatically create, update, or delete those Pods. A Service might say "route traffic to all Pods with app: demo" without needing to know their names or IP addresses.

Understanding labels now gives you the foundation for how Kubernetes manages applications at scale. In the practice exercises, you'll create your own labeled Pods, query them using different selectors, and see how labels make it easy to organize and find resources in a cluster. When you're ready to clean up, you can delete all three Pods at once: kubectl delete -f nginx-one.yaml -f nginx-two.yaml -f nginx-three.yaml.