Pod definition in YAML in Kubernetes - Step-by-Step Execution

Process Flow - Pod definition in YAML

Start YAML file

↓

Define apiVersion

↓

Define kind: Pod

↓

Define metadata: name, labels

↓

Define spec: containers list

↓

Define each container: name, image, ports

↓

End YAML file

This flow shows how a Pod YAML is structured step-by-step from top-level fields to container details.

Execution Sample

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    ports:
    - containerPort: 80

This YAML defines a Pod named 'my-pod' with one container running nginx on port 80.

Process Table

Step	YAML Section	Action	Value Set	Notes
1	apiVersion	Set API version	v1	Specifies Kubernetes API version
2	kind	Set resource type	Pod	Defines this resource as a Pod
3	metadata	Set metadata block	name: my-pod	Names the Pod 'my-pod'
4	spec	Set spec block	containers: list	Defines containers in the Pod
5	containers[0]	Define container	name: my-container	First container named 'my-container'
6	containers[0]	Set image	nginx	Container runs nginx image
7	containers[0]	Set ports	containerPort: 80	Container exposes port 80
8	End	YAML complete	Pod definition ready	Pod YAML is valid and ready for use

💡 All required fields set; YAML defines a valid Pod with one container.

Status Tracker

Field	Start	After Step 3	After Step 7	Final
apiVersion	undefined	v1	v1	v1
kind	undefined	Pod	Pod	Pod
metadata.name	undefined	my-pod	my-pod	my-pod
spec.containers	undefined	undefined	[{name: my-container, image: nginx, ports: [{containerPort: 80}]}]	[{name: my-container, image: nginx, ports: [{containerPort: 80}]}]

Key Moments - 3 Insights

Why do we need to specify 'apiVersion' and 'kind' at the top?

These fields tell Kubernetes what type of resource you are creating and which API version to use, as shown in steps 1 and 2 of the execution table.

What happens if we forget to define 'containers' under 'spec'?

The Pod would be invalid because Kubernetes requires at least one container in the Pod spec, as seen in step 4 where containers list is defined.

Why do we indent 'name', 'image', and 'ports' under the container?

Indentation shows these fields belong to the container object inside the containers list, demonstrated in steps 5 to 7.

Visual Quiz - 3 Questions

Look at the execution table, what is the value of 'kind' after step 2?

A Pod

B v1

C my-pod

D containers

💡 Hint

Check the 'Value Set' column at step 2 in the execution table.

At which step is the container image set to 'nginx'?

A Step 3

B Step 5

C Step 6

D Step 7

💡 Hint

Look for 'Set image' action in the execution table.

If we remove the 'ports' section, which step would be missing?

A Step 4

B Step 7

C Step 6

D Step 8

💡 Hint

Ports are set in step 7 according to the execution table.

Concept Snapshot

Pod YAML structure:
apiVersion: v1
kind: Pod
metadata:
  name: pod-name
spec:
  containers:
  - name: container-name
    image: image-name
    ports:
    - containerPort: port-number

Indentation shows hierarchy; containers list is required.

Full Transcript

This visual execution traces a Kubernetes Pod definition in YAML. It starts with setting the apiVersion and kind fields to specify the resource type. Then metadata is defined to name the Pod. The spec section contains a list of containers. Each container has a name, image, and optionally ports. The execution table shows each step setting these fields. The variable tracker shows how fields get their values step-by-step. Key moments clarify why apiVersion and kind are needed, why containers are required, and the importance of indentation. The quiz tests understanding of these steps. The snapshot summarizes the YAML structure and key rules for defining a Pod.