Kubernetes Basics

Kubernetes is simple at its core: you declare the desired state in YAML, and controllers continuously reconcile reality to match it.

Four core objects

Pod: the smallest scheduling unit
Deployment: manages replicas and rolling updates
Service: stable access point
Namespace: logical isolation boundary

Declarative model

You describe what you want
Controllers decide how to make it happen
Reapplying the same YAML is safe and idempotent

Minimal Deployment example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
        - name: web
          image: nginx:1.25
          ports:
            - containerPort: 80

Common commands

kubectl apply -f hello.yaml
kubectl get deploy,pods
kubectl describe deploy hello
kubectl logs deploy/hello

Pitfalls

Labels and selectors do not match
Updating YAML without checking rollout status
Treating Service as a full reverse proxy

Practical notes

Start with a quick inventory: kubectl get nodes, kubectl get pods -A, and kubectl get events -A.
Compare desired vs. observed state; kubectl describe usually explains drift or failed controllers.
Keep names, labels, and selectors consistent so Services and controllers can find Pods.

Quick checklist

The resource matches the intent you described in YAML.
Namespaces, RBAC, and images are correct for the target environment.
Health checks and logs are in place before promotion.

Reading Kubernetes basics as a system

Kubernetes basics makes more sense when you see Kubernetes as a set of contracts between people and controllers. You describe intent in YAML, controllers reconcile it, and the cluster keeps trying until reality matches the spec. That mental model is the same whether you are creating a Pod, a Service, or an entire environment. The key is to think in desired state, not imperative steps, and to accept that reconciliation is continuous.

Declarative workflow in practice

A typical workflow is write a manifest, apply it, observe status, then refine. The applied object becomes the source of truth, not the CLI command you typed. When you change a field, you are changing the desired state, and controllers take action to reach it. This encourages idempotent changes, repeatable rollouts, and safe automation because the same manifest can be applied in any environment without manual rework.

Object model and API habits

Every object follows the same shape: apiVersion, kind, metadata, and spec. The metadata block is not busywork. Names, labels, and annotations are how other objects discover and manage your resource. Establish naming conventions, label taxonomy, and ownership references early, because they become the glue for services, selectors, and monitoring queries. A clean object model is the difference between a cluster you can reason about and one that feels unpredictable.

How control loops change your thinking

Control loops keep running, even when you are not watching. That means retries are normal, and eventual consistency is a feature. When a node disappears, schedulers place replacement Pods. When configuration changes, controllers roll out updates. This is why Kubernetes wants you to specify intent rather than sequence, and why most operations are safe to repeat. Design your workflows around observation and rollback instead of manual fixes.

Minimal lab sequence

A small lab makes these ideas concrete. Start by creating a namespace, deploy a simple workload, expose it, and then observe. You can follow a sequence like create or apply, check status, describe for events, and watch logs. Repeat this loop for a few objects to build intuition about the event stream and the pace of reconciliation.

kubectl create namespace demo
kubectl apply -f app.yaml
kubectl get pods -n demo
kubectl describe pod -n demo
kubectl get events -n demo --sort-by=.metadata.creationTimestamp

Common misreads and corrections

People new to Kubernetes often assume it is a PaaS or a VM scheduler. It is neither. It is an orchestration system that assumes your app can be restarted. A Pod is not a long lived machine, and a Service is not a process. Namespaces organize resources but are not a strong security boundary by themselves. Correcting these assumptions early makes later concepts much easier.

Operational hygiene

Even in a quickstart, develop habits that scale. Keep manifests in version control. Use labels that encode owner, team, or environment. Define resource requests and limits so scheduling is predictable. Enable logs and metrics from the start, not as an afterthought, because every troubleshooting session depends on them. When you treat the cluster as a system of record, the mental overhead drops.

Decision points and tradeoffs

Kubernetes gives you choices that matter in practice: deployment vs statefulset, rolling updates vs recreate, small replicas vs larger nodes. There is rarely a single correct answer, so it helps to document the tradeoffs you pick. The fastest path is not always the safest, and the most complex option is rarely needed early.

Control plane roles in one paragraph

The API server is the front door for all requests, and etcd is the durable store that holds desired and observed state. The scheduler assigns Pods to nodes, and controllers continuously drive state toward your intent. When you understand who does what, troubleshooting becomes far more systematic.

Versioning and compatibility

APIs evolve and some fields are deprecated over time. Prefer stable API versions, read release notes before upgrades, and avoid depending on alpha behavior in production. A small effort to track API changes saves you from surprise breakages later.

Boundaries of responsibility

Kubernetes does not build images, write CI pipelines, or secure your application logic. You still need a registry, vulnerability scanning, CI/CD, and app level monitoring. The platform handles orchestration, not product engineering.

A simple mental checklist

Before you apply changes, ask what the desired state is, which controller owns it, how you will detect failure, and how you will roll back. This checklist keeps the focus on intent, ownership, and observability. It also forces you to think about cleanup: which resources remain after delete, which data is durable, and which objects are safe to recreate.

When to revisit Kubernetes basics

After you ship a few workloads, come back to Kubernetes basics with real incidents in mind. The same concepts will look different once you have dealt with a failed rollout, a noisy neighbor, or a quota limit. That feedback loop is where quickstart knowledge turns into production skill.

Wrap-up: learn Kubernetes by operating it

You don’t really learn Kubernetes by reading pages of concepts. You learn it by:

shipping a small change
watching what the controllers do
debugging one failure end-to-end

Do that a few times and the core ideas stick.