kubectl & Your First Deployment

Chapter 3 covered what a pod is. This chapter covers the actual tool and workflow used to create and manage resources — pods and everything else — in a real cluster.

Getting Connected — kubeconfig

kubectl needs to know which cluster to talk to and how to authenticate — a kubeconfig file (typically ~/.kube/config) holds this connection info. Contexts let you switch between multiple clusters — dev/staging/prod, or different providers entirely, echoing cloud1-2's own cross-provider framing — via kubectl config get-contexts and kubectl config use-context. A genuinely easy-to-overlook, practical detail worth naming early: running a command against the wrong context by mistake is a real, common gotcha.

kubectl Basics

Revisiting cloud2-1's own console/CLI/API point, specifically for Kubernetes: kubectl talks to the API server (Chapter 2's architecture) exactly like any other client. Four commands used constantly:

• kubectl get pods — list resources.
• kubectl describe pod <name> — detailed information about one resource.
• kubectl logs <name> — a container's log output.
• kubectl delete pod <name> — remove a resource.

kubectl get works across many resource types — pods, deployments, services, nodes, and more, covered as this course goes on.

Imperative vs. Declarative — Two Ways to Work

Imperative commands tell kubectl what to do right now — kubectl run, kubectl create deployment — fast for quick testing, but leaving no reusable record of what was done. The declarative approach instead writes a YAML manifest describing the desired state, then runs kubectl apply -f file.yaml — Kubernetes' own reconciliation loop (Chapter 2) takes it from there.

This is exactly cloud1-11's declarative-vs-imperative IaC distinction, applied here to Kubernetes objects instead of general cloud infrastructure. Practical guidance: imperative commands are fine for quick exploration, but real, reusable, version-controllable work (git1-git3) should be declarative YAML.

Anatomy of a YAML Manifest

• apiVersion — which version of the Kubernetes API this resource type belongs to.
• kind — the resource type (Pod, Deployment, Service, and so on).
• metadata — identifying information: name, and labels — key-value tags that later chapters use to connect resources together (Chapter 6's Services select pods by label).
• spec — the actual desired configuration — containers, images, ports, and everything specific to that resource type.

This structure recurs, largely unchanged in shape, across every YAML example the rest of this course uses.

kubectl apply — Your Main Tool Going Forward

kubectl apply creates a resource if it doesn't exist, or updates it if it does, by diffing against the last-applied configuration.

Namespaces — Organizing a Cluster

A namespace is a logical partition within a single cluster — not a separate cluster. Used to separate teams, environments, or projects sharing one cluster. A default namespace always exists, but real usage typically creates dedicated ones. Resource names must be unique within a namespace, not across the whole cluster. Some resources are cluster-scoped (like Nodes) rather than namespace-scoped — which is why not every kubectl get command needs a namespace flag.

A Practical First Workflow

A genuinely satisfying full loop for a first real interaction with a cluster.

Hands-On Exercises