Published: 2026-06-01 โ€ข Updated: 2026-07-05

Understanding Kubernetes Objects and YAML Manifests: Complete Enterprise Guide for Real-World Cloud-Native Applications

Kubernetes is one of the most powerful container orchestration platforms used in modern cloud-native infrastructure. However, Kubernetes itself does not directly manage applications magically. Instead, Kubernetes works using Objects.

Every application, deployment, networking rule, storage configuration, security policy, and scaling configuration inside Kubernetes is represented using Kubernetes Objects.

These objects are defined using:

YAML Manifests

Understanding Kubernetes Objects and YAML files is one of the most important skills for:

  • Backend developers
  • DevOps engineers
  • Cloud engineers
  • Platform engineers
  • Site Reliability Engineers (SRE)
  • Microservices architects

This foundational introduction to Kubernetes Objects and YAML manifests is introduced here: :contentReference[oaicite:0]{index=0}

However, in real enterprise environments, Kubernetes Objects become much more advanced and powerful than basic examples.


Why Kubernetes Uses Objects?

Kubernetes follows:

Declarative Infrastructure Model

Instead of manually starting containers one by one, developers define:

  • What should run
  • How many replicas should exist
  • How applications communicate
  • What resources are required
  • How failures should be handled

Kubernetes continuously ensures the actual cluster state matches the desired state.


Real-World Banking Example

Suppose a banking application contains:

  • Payment service
  • Loan processing API
  • Fraud detection engine
  • Customer management service
  • Notification service

Manually managing containers for these services would become extremely difficult.

Instead, Kubernetes Objects define:

  • Deployments
  • Networking
  • Scaling
  • Secrets
  • Storage

inside YAML files.


What are Kubernetes Objects?

Kubernetes Objects are persistent entities that describe the desired state of cluster resources.

Examples:

  • Pods
  • Deployments
  • Services
  • ConfigMaps
  • Secrets
  • Ingress
  • StatefulSets
  • DaemonSets

These objects are stored inside:

etcd

which acts as Kubernetes cluster database.


How Kubernetes Objects Work Internally


[ Developer Writes YAML ]
            |
            v
[ kubectl apply ]
            |
            v
[ API Server ]
            |
            v
[ etcd Stores Desired State ]
            |
            v
[ Controller Manager ]
            |
            v
Ensures Actual State Matches Desired State

This is the core working principle of Kubernetes.


What is a YAML Manifest?

A YAML Manifest is a configuration file used to define Kubernetes Objects.

YAML stands for:

YAML Ain't Markup Language

YAML is popular because:

  • Human readable
  • Easy to structure
  • Simple indentation
  • Widely used in DevOps

Basic YAML Structure

apiVersion: apps/v1
kind: Deployment

metadata:
  name: my-app

spec:
  replicas: 2

Understanding Each Field

Field Purpose
apiVersion Kubernetes API version
kind Type of Kubernetes object
metadata Object information
spec Desired configuration

1. Pod Object

A Pod is the smallest deployable unit in Kubernetes.

Pods contain:

  • One or more containers
  • Shared networking
  • Shared storage

Pod Flow Diagram


+----------------------+
|        Pod           |
|----------------------|
|  App Container       |
|  Logging Sidecar     |
+----------------------+

Simple Pod YAML

apiVersion: v1
kind: Pod

metadata:
  name: nginx-pod

spec:
  containers:
  - name: nginx
    image: nginx

Real-World Example

Suppose an e-commerce application needs:

  • Nginx container
  • Logging sidecar container

Both can run inside same Pod.


Why Pods Are Temporary?

Pods are designed to be:

  • Replaceable
  • Scalable
  • Disposable

If a Pod crashes:


[ Pod Crash ]
      |
      v
Kubernetes Creates New Pod Automatically

This improves application reliability.


2. Deployment Object

Deployments manage stateless applications.

Responsibilities:

  • Replica management
  • Rolling updates
  • Self-healing
  • Scaling

Deployment Architecture Flow


[ Deployment ]
       |
       v
[ ReplicaSet ]
       |
       v
[ Pods ]
       |
       v
[ Containers ]

Deployment YAML Example

apiVersion: apps/v1
kind: Deployment

metadata:
  name: payment-service

spec:
  replicas: 3

  selector:
    matchLabels:
      app: payment

  template:
    metadata:
      labels:
        app: payment

    spec:
      containers:
      - name: payment-container
        image: payment-api:v1

Real-World Banking Example

Suppose a payment API receives huge traffic during salary credit day.

Deployment ensures:

  • 3 replicas always running
  • Failed Pods replaced automatically
  • Application remains highly available

3. Service Object

Pods are temporary and their IP addresses may change.

Services provide stable networking.

Service Flow Diagram


[ Users ]
    |
    v
[ Kubernetes Service ]
    |
 -------------------------
 |           |           |
 v           v           v
Pod-1      Pod-2      Pod-3

Services perform:

  • Load balancing
  • Stable DNS
  • Traffic routing

Service YAML Example

apiVersion: v1
kind: Service

metadata:
  name: payment-service

spec:
  selector:
    app: payment

  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

  type: ClusterIP

Types of Kubernetes Services

Service Type Purpose
ClusterIP Internal communication
NodePort Expose through node port
LoadBalancer Cloud load balancing
ExternalName Maps external DNS

4. ConfigMap

ConfigMaps store non-sensitive configuration.

Examples

  • Application URLs
  • Environment settings
  • Feature flags
  • Configuration files

ConfigMap Example

apiVersion: v1
kind: ConfigMap

metadata:
  name: app-config

data:
  APP_ENV: production
  LOG_LEVEL: INFO

5. Secret Object

Secrets store sensitive information securely.

Examples

  • Database passwords
  • JWT secrets
  • AWS keys
  • API tokens

Secret Flow Diagram


[ Secret ]
     |
     v
[ Pod Environment Variables ]
     |
     v
[ Application ]

Secret YAML Example

apiVersion: v1
kind: Secret

metadata:
  name: db-secret

type: Opaque

data:
  password: cGFzc3dvcmQ=

Why Secrets Are Important?

Hardcoding passwords inside source code is dangerous.

Kubernetes Secrets improve:

  • Security
  • Configuration separation
  • Environment management

6. Ingress Object

Ingress manages external HTTP/HTTPS traffic.

Traffic Flow


[ Internet Users ]
        |
        v
[ Ingress Controller ]
        |
        v
[ Services ]
        |
        v
[ Pods ]

Ingress supports:

  • Domain-based routing
  • SSL termination
  • Path routing
  • Load balancing

7. StatefulSet

StatefulSets manage stateful applications.

Examples

  • MySQL
  • MongoDB
  • Kafka
  • Redis clusters

StatefulSets provide:

  • Stable network identities
  • Persistent storage
  • Ordered deployment

8. DaemonSet

DaemonSets ensure one Pod runs on every worker node.

Common Use Cases

  • Log collection
  • Monitoring agents
  • Security agents

Example


Every Worker Node
        |
        v
Runs Logging Agent Automatically

Real-World E-Commerce Kubernetes Architecture


                    [ Mobile App ]
                           |
                           v
                      [ Ingress ]
                           |
                           v
                     [ API Gateway ]
                           |
------------------------------------------------
|                |               |             |
v                v               v             v
[ Product API ] [ Order API ] [ Payment ] [ User API ]
                           |
                           v
                    [ MySQL Cluster ]

Each Kubernetes Object plays a critical role in this architecture.


Common YAML Mistakes

1. Incorrect Indentation

YAML is whitespace-sensitive.

One wrong space can break deployment.

2. Wrong Labels

Services use labels to find Pods.

Incorrect labels break communication.

3. Wrong apiVersion

Older API versions may become deprecated.

4. Hardcoding Secrets

Sensitive data should use Secret objects.

5. Missing Resource Limits

Pods may consume excessive resources.


Realistic Production Failure Example

Suppose payment-service becomes inaccessible.

Possible Root Causes

  • Service selector mismatch
  • Pod crash
  • Image pull failure
  • Configuration error

Debugging Flow


Step 1: Check Pods
kubectl get pods

Step 2: Check Services
kubectl get svc

Step 3: Describe Deployment
kubectl describe deployment payment-service

Step 4: Check Logs
kubectl logs pod-name

Step 5: Verify YAML Labels

Interview Questions

Q1: What is a Kubernetes Object?

A Kubernetes Object represents the desired state of cluster resources.

Q2: What is YAML Manifest?

A YAML configuration file used to define Kubernetes Objects.

Q3: Difference between Pod and Deployment?

Pod runs containers while Deployment manages Pods and replicas.

Q4: Why Services are needed?

Services provide stable networking and load balancing.

Q5: Difference between ConfigMap and Secret?

ConfigMap stores non-sensitive configuration while Secret stores sensitive information securely.


Interview Trap Questions

Can Pods communicate directly?

Yes, Kubernetes networking allows Pod-to-Pod communication.

Are Secrets encrypted automatically?

Not always. Additional encryption configuration may be required.

Can Deployments manage databases?

Usually StatefulSets are preferred for databases.

Can Services work without labels?

No. Services depend on labels to identify Pods.


Recommended Learning Path


Summary

Kubernetes Objects and YAML manifests form the foundation of Kubernetes architecture and cloud-native application deployment.

Objects define:

  • Applications
  • Networking
  • Storage
  • Security
  • Scaling

while YAML manifests provide the declarative configuration used to create and manage these resources.

Understanding Kubernetes Objects deeply is essential for designing scalable, production-ready, and highly available distributed systems.

About the Author

Naresh Kumar

Naresh Kumar

Senior Java Backend Engineer experienced in Banking, Payments, ISO 20022, Spring Boot, Microservices, Kafka, Docker, Kubernetes, AWS and Cloud Native Systems.

Built enterprise payment solutions, transaction processing systems, API platforms and scalable microservices used in production.

LinkedIn Profile