Kubernetes at a glance — the object model and the operational bill

Kubernetes is the default answer to “we need an orchestrator”, and it is frequently the right one. It is also a much larger system than anything else in this course, and the most common way to be disappointed by it is to adopt it without costing the parts that are not the scheduler.

This is a transition lesson, not a Kubernetes course. The goal is that you can read a manifest, name the moving parts, and put a realistic number on what running it costs.

The object model, from what you already know

The pattern to notice: almost every Kubernetes object is declarative desired state read by a controller. An Ingress object is not a proxy; it is a request that some ingress controller you installed configure a proxy. A PersistentVolumeClaim is not storage; it is a request that a CSI driver you installed provision some. Objects without controllers do nothing, silently.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: myapp
spec:
  replicas: 4
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: registry.example.com/myorg/myapp:1.4.2
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              memory: 512Mi
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 10
          terminationGracePeriodSeconds: 60

requests and limits are the same distinction Swarm makes with reservations and limits: the scheduler places on requests, the kernel enforces limits. terminationGracePeriodSeconds is the stop timeout from the lifecycle part of this course, spelled differently.

What the control plane is made of

The pattern is the same as Swarm’s quorum loss, generalised: the data plane survives control plane failure, so outages are partial and quiet. A cluster whose scheduler has been down for six hours looks perfectly healthy until something needs rescheduling.

Docker is not the runtime

The recurring bill

This is the part usually left out of the evaluation, and it is the part that decides whether the adoption succeeds.

When Kubernetes is the right answer

It is, genuinely and often. The honest version of the criteria:

• You have enough workloads that bin-packing matters. Below roughly a dozen services, the scheduler is solving a problem you do not have.
• You want the ecosystem specifically. Operators for databases, cert-manager, Argo CD, service meshes, autoscalers. This is Kubernetes’ strongest argument by a wide margin, and none of it exists elsewhere.
• More than one team deploys to the same infrastructure. Namespaces, RBAC, resource quotas and network policies are a real multi-tenancy story.
• Someone will own the platform. Not as a side project. The most common failure is a cluster built by one enthusiast who then changes team.
• Your workloads already tolerate being killed and moved. If they do not, fix that first — it is worth doing regardless of what schedules them.

If most of those are false, a smaller tool will serve you better, and you can always move later. The migration from Compose or Swarm to Kubernetes is tedious; the migration from a Kubernetes cluster nobody can operate is an outage.

Knowledge check