Creating a Pod Manifest for a Single-Container Application

1. The Anatomy of a Kubernetes Manifest

A Kubernetes manifest is a YAML or JSON file that describes the desired state of a resource, such as a Pod, Deployment, or Service. For readability and ease of use, YAML is the industry standard.

Every Kubernetes manifest, regardless of the resource it defines, contains four essential top-level fields:

1. apiVersion: Specifies the version of the Kubernetes API you're using to create this object.
2. kind: The type of Kubernetes object you want to create (e.g., Pod, Service, Deployment).
3. metadata: Data that helps uniquely identify the object, including its name, labels, and optional namespace.
4. spec: The "specification" or desired state of the object. This is the most complex section and varies significantly depending on the kind.

To get a clear overview of these four components, the following reading is an excellent reference.

2. Crafting a Pod Manifest

Now, let's apply this structure to create our first Pod. A Pod is the smallest and simplest unit in the Kubernetes object model that you create or deploy. It represents a single instance of a running process in your cluster and can contain one or more containers.

For our first Pod, we will define a manifest that runs a single container using the popular nginx web server image.

Let's break down the metadata and spec sections for a Pod in more detail.

The metadata block

As the video explained, under metadata, the two most important fields are:

• name: A unique name for your Pod within its namespace (e.g., my-nginx-pod).
• labels: Key-value pairs that you can attach to objects. Labels are critical for organizing resources and are used by other objects, like Services, to select which Pods to route traffic to. For example: app: webserver.

The spec block

This is where you define what you want your Pod to do. For a single-container Pod, the spec is straightforward:

• containers: This is a list of containers to run in the Pod. Because it's a list, each item is denoted by a dash (-). Even for a single container, you must use this list format.
  • name: A name for the container inside the Pod (e.g., nginx-container).
  • image: The container image to use from a registry (e.g., nginx:1.25). It's best practice to specify a version tag rather than relying on latest.
  • ports: A list of network ports to expose from the container.
    • containerPort: The port number the application is listening on inside the container (e.g., 80 for Nginx).

A Complete Example

Here is a complete manifest file, which you can save as nginx-pod.yaml.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo-pod
  labels:
    app: web
    tier: frontend
spec:
  containers:
  - name: nginx-container
    image: nginx:1.25
    ports:
    - containerPort: 80

spec:
  container:
    name: redis
    image: redis:7.0

spec:
  containers:
  - name: redis-container
    image: redis:7.0

spec:
  containers:
    name: redis-container
    image: redis:7.0

3. Deploying and Verifying the Pod

Once you have your nginx-pod.yaml file, you can create the Pod in your cluster. In the previous module, you used commands like kubectl get and describe to inspect resources. To create or update resources from a file, you'll use kubectl apply.

The command kubectl apply -f <filename> tells Kubernetes: "Read the desired state from this file and make the cluster match it."

Let's watch a live demonstration of this entire process.

As you saw in the video, the workflow is simple and powerful:

1. Write your YAML manifest file.
2. Apply it with kubectl apply -f your-pod.yaml.
3. Verify its status with kubectl get pods. You should see your Pod in the Running state after a few moments.
4. Inspect it further with kubectl describe pod <pod-name> to see details like the image used, the labels assigned, and the events related to its creation.

For a quick text-based summary of this workflow, you can refer to the following article.

Conclusion

Congratulations! You have now learned the most fundamental skill in managing applications on Kubernetes: defining a Pod declaratively in a manifest file and bringing it to life in a cluster.

Key Takeaways:

• Kubernetes resources are defined declaratively in YAML manifests.
• Every manifest requires four fields: apiVersion, kind, metadata, and spec.
• For a Pod, the spec must contain a containers list, where you define the image, name, and other properties for each container.
• The kubectl apply -f <filename.yaml> command is used to create or update a resource based on its manifest.
• You can verify the Pod's creation and status using kubectl get pods and kubectl describe pod.

In the previous lesson, we saw how a Pod could be OOMKilled (Out of Memory Killed) if it consumes too many resources. Our simple Pod manifest doesn't tell Kubernetes anything about its CPU or memory needs. In our next lesson, we will address this by learning how to configure resource requests and limits for containers, a critical practice for running stable and reliable applications at scale.