1. What are Kubernetes Objects?

Kubernetes objects are persistent entities in the Kubernetes system. They represent the desired state of your cluster: what applications or workloads should be running, what container images they use, the number of replicas, networking details, and more.

When you create a Kubernetes object (via YAML or the kubectl CLI), you are essentially telling Kubernetes:

• What you want the system to do.
• What the desired state of the system should be.

Kubernetes continuously works to ensure the actual state matches the desired state defined in these objects.

2. Anatomy of a Kubernetes Object

Every Kubernetes object shares a common structure. Here’s a typical YAML manifest structure:

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

Explanation:

• apiVersion: Specifies the API version used to create the object.
• kind: Type of the Kubernetes object (e.g., Pod, Deployment, Service).
• metadata: Data to identify the object, like name, namespace, labels, etc.
• spec: Defines the desired state (like containers, replicas, volumes, etc.)

3. Categories of Kubernetes Objects

Kubernetes objects can be grouped into 4 main categories:

A. Workload Objects

These manage and run containers on the cluster.

Object	Description
Pod	Smallest deployable unit; a group of one or more containers
ReplicaSet	Ensures a specified number of identical Pods are running
Deployment	Provides declarative updates to Pods and ReplicaSets
StatefulSet	Like Deployments but for stateful applications (e.g., databases)
DaemonSet	Ensures a copy of a Pod runs on all or specific nodes
Job	Creates Pods to run a task to completion
CronJob	Schedules Jobs to run periodically

B. Service Discovery & Networking

These define how pods communicate with each other or external systems.

Object	Description
Service	Provides a stable network endpoint for a set of Pods
Ingress	Manages external access to services (usually HTTP)
NetworkPolicy	Controls traffic flow between Pods and/or namespaces

C. Configuration & Secrets

These manage application configuration separately from code.

Object	Description
ConfigMap	Stores non-sensitive configuration data
Secret	Stores sensitive data like passwords, tokens, keys
Volume	External storage mounted to containers
PersistentVolume (PV)	Abstracts the storage provisioned for pods
PersistentVolumeClaim (PVC)	Request for storage by a Pod

D. Cluster Management

These control how Kubernetes runs and configures cluster resources.

Object	Description
Namespace	Isolates group of resources within the cluster
ResourceQuota	Limits resource usage per namespace
LimitRange	Sets constraints on resource consumption per Pod/Container
Node	Represents a worker machine in the cluster
Role/ClusterRole	Specifies permissions in a namespace or cluster-wide
RoleBinding/ClusterRoleBinding	Grants roles to users or groups

4. Common Kubernetes Objects Explained with YAML

4.1 Pod

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

• Runs a single container nginx.
• Used mainly for learning or one-off tasks.

4.2 Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

• Manages replicas of pods.
• Handles rolling updates and rollbacks.

4.3 Service

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

• Exposes Pods to other Pods inside the cluster.
• type: ClusterIP is the default; other types include NodePort, LoadBalancer, and ExternalName.

4.4 ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_MODE: "production"
  LOG_LEVEL: "info"

4.5 Secret

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  password: cGFzc3dvcmQ=   # base64 for "password"

5. How Kubernetes Objects Work Behind the Scenes

When you apply an object using kubectl apply -f, the Kubernetes control plane:

1. Accepts the YAML manifest and stores the object in etcd (Kubernetes’ key-value store).
2. The Controller Manager watches for desired state changes and reconciles them with the actual state.
3. If differences are found (e.g., a pod is down), the Controller restarts or recreates it to match the declared state.

This is part of Kubernetes’ self-healing architecture.

6. Managing Kubernetes Objects

Creating an Object

kubectl apply -f deployment.yaml

Viewing Objects

kubectl get pods
kubectl get services
kubectl get all

Describing an Object

kubectl describe pod nginx-pod

Deleting an Object

kubectl delete -f deployment.yaml
kubectl delete pod nginx-pod

Editing Live Object

kubectl edit deployment nginx-deployment

7. Best Practices

• Use Deployment instead of directly creating Pods for scalability and fault tolerance.
• Keep configuration (ConfigMap) and secrets (Secret) separate from code.
• Always define resource limits and requests for containers.
• Use namespaces to logically separate resources.
• Use Labels and Selectors for grouping and identifying objects.
• Use liveness and readiness probes to improve application reliability.

8. Kubernetes Object Lifecycle

1. Create: You create an object using kubectl apply or API.
2. Schedule: Kubernetes decides where to place it (on which node).
3. Run: The kubelet runs the container(s) based on the object.
4. Monitor & Reconcile: Kubernetes constantly checks that the actual state matches the desired state.
5. Delete: When no longer needed, you can delete the object and Kubernetes will clean it up.