Sample Kubernetes Configuration File

Kubernetes uses configuration files called manifests to define how applications, containers, and services should run within a cluster. These files are typically written in YAML format and allow administrators and developers to deploy infrastructure consistently and automatically.

A Kubernetes manifest can describe many different resources, including:

• Pods
• Deployments
• Services
• ConfigMaps
• Secrets
• Ingress rules
• Persistent Volumes

Below is a simple example of a Kubernetes Pod configuration.

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  labels:
    app: my-application

spec:
  containers:
    - name: application-container
      image: my-application:latest
      ports:
        - containerPort: 80

Understanding the Configuration

apiVersion

The apiVersion field specifies which Kubernetes API version should be used for the resource.

apiVersion: v1

For basic resources such as Pods, the most commonly used version is v1.

kind

The kind field defines the type of Kubernetes resource being created.

kind: Pod

In this example, Kubernetes will create a single Pod.

metadata

The metadata section contains identifying information about the resource.

metadata:
  name: example-pod
  labels:
    app: my-application

Common metadata values include:

• Resource name
• Labels
• Annotations
• Namespace information

Labels are particularly useful because they allow other Kubernetes resources to identify and interact with the Pod.

spec

The specification section defines the desired state of the resource.

spec:

This is where you configure containers, storage, networking, and other runtime settings.

containers

A Pod can contain one or multiple containers.

containers:

Each container requires its own configuration.

name

The container name is used internally by Kubernetes.

name: application-container

image

The image field specifies which container image should be downloaded and executed.

image: my-application:latest

In production environments, it is often recommended to use specific image versions instead of the latest tag.

Example:

image: my-application:v1.2.0

ports

The ports section defines which container ports should be exposed.

ports:
  - containerPort: 80

In this example, the application listens on port 80 inside the container.

Deploying the Manifest

Save the configuration to a file such as:

pod.yaml

Then deploy it using:

kubectl apply -f pod.yaml

Kubernetes will create the Pod according to the configuration.

Checking the Pod Status

To verify that the Pod is running correctly:

kubectl get pods

To view detailed information:

kubectl describe pod example-pod

To view application logs:

kubectl logs example-pod

Why Deployments Are Usually Preferred

Although Pods can be created directly, production environments typically use Deployments instead.

Deployments provide:

• Automatic recovery
• Rolling updates
• Easy scaling
• Replica management

A Deployment automatically recreates failed Pods and helps ensure application availability.

Example Deployment Manifest

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-application

spec:
  replicas: 3

  selector:
    matchLabels:
      app: my-application

  template:
    metadata:
      labels:
        app: my-application

    spec:
      containers:
        - name: application-container
          image: my-application:v1.0
          ports:
            - containerPort: 80

This configuration launches three identical Pods and automatically replaces any Pod that becomes unavailable.

Summary

Kubernetes manifests are configuration files that define how resources should operate within a cluster. The example above demonstrates a simple Pod configuration, including metadata, container definitions, and networking settings.

While direct Pod creation is useful for testing and learning Kubernetes, most production environments rely on Deployments and Services to provide scalability, resilience, and easier application management.