Kubernetes Demystified: Kubectl & YAML Configuration

Part 2, we covered the architecture - Control Plane and Worker Nodes. Now let's look at how you actually manage Kubernetes components: through kubectl **and **YAML configuration files.

How to Manage K8s Components:
There are two ways to interact with your cluster's components.

1. kubectl — the Kubernetes CLI(Imperative):

A very powerful tool that enables direct interaction with the cluster.

kubectl create deployment mydepl
kubectl create statefulset myst
kubectl create service mysvc
kubectl create <objecttype> <instancename>
kubectl delete <objecttype> <instancename>

A very powerful tool that enables direct interaction with the cluster:

kubectl get        (basic information)
kubectl describe    (aggregated detail info)
kubectl logs         (logs of containers)

Limitation:
These commands get unwieldy while creating multiple Pods or components at once.

2. Kubernetes Manifests (Configuration Files-Declarative):

For anything more complex, Kubernetes component files — also called Kubernetes manifests are the better option.

• Write the component configuration in a file
• Apply the configuration file with kubectl apply
• Multiple K8s components can go in one file and be applied with a single apply command
• To update: edit the config file and apply again
• To delete: delete using the config file

Kubernetes Configuration File: YAML

Kubernetes configuration files are written in YAML, and every one of them has three parts:

**

• metadata
• specifications (spec)
• status**

A typical flow connects a Deployment → Service → Pod.

Example: Deployment vs Service

Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels: ...
spec:
  replicas: 2
  selector: ...
  template: ...

Service:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector: ...
  ports: ...

Breaking Down the Three Parts:

Declaration — apiVersion and kind tell Kubernetes what type of object this is.
metadata — the object's name and other identifying info (e.g., labels).
spec (specifications) — the desired configuration; attributes here are specific to the kind (a Deployment's spec looks different from a Service's spec).
status — automatically generated and added by Kubernetes; you don't write this yourself

How "status" Actually Works:

This is where Kubernetes' self-healing nature comes from:

• If desired state = actual state → all good, pass.
• If desired state ≠ actual state → Kubernetes self-heals, working to bring actual state back in line with desired state.
• Kubernetes updates this state continuously.
• This status information is retrieved from etcd, which holds the current status of every K8s component.

Recap

• Use kubectl for quick, one-off, imperative changes.
• Use YAML manifests (declarative) for anything real, repeatable, and version-controlled.
• Every manifest has metadata, spec, and an auto-managed status.
• Kubernetes constantly compares desired vs actual state — that comparison is why self-healing works.