What Is Kubernetes? How the Control Loop Works

Understand Kubernetes through desired state, the control plane, nodes, Pods, workloads, and Services—what it automates, what remains yours, and how to inspect failure.

Guance Observability Research 16 min read
Industry insights Best practices
What Is Kubernetes? How the Control Loop Works

Kubernetes is an open-source platform for managing containerised workloads and services across a cluster. You describe the state you want—such as an application image, three replicas, and a network Service—and Kubernetes control processes keep working to bring the observed cluster state towards that declaration. Containers run the application; Kubernetes manages the desired workload state around them.

That distinction is the shortest useful answer to what is Kubernetes. Kubernetes can schedule Pods, replace failed workload instances, coordinate rollouts, and provide a stable Service abstraction over changing Pods. It does not build source code, prove that an application returns the correct business result, repair every storage or network failure, or mandate a monitoring backend. The Kubernetes overview describes both these capabilities and these limits.

This guide is for engineers and technical decision-makers who need to understand the control loop before choosing a workload resource, investigating a failure, or deciding whether Kubernetes is justified. It explains the core model, the responsibility boundary, the evidence to inspect, and a conditional adoption worksheet. Installation commands, vendor-specific configuration, and product evaluation remain separate tasks.

This article is published by Guance, an observability platform provider. It is not official Kubernetes documentation and does not claim that Guance is required to run or observe Kubernetes. Kubernetes facts below are tied to upstream Kubernetes sources reviewed on 1 August 2026; the decision worksheet and evidence paths are Guance editorial methods, not Kubernetes project recommendations.

Four distinctions to keep in mind

  • A container image, a container, and a Pod are different layers. An image packages an application and its dependencies; a container is a running instance created from an image. A Pod is the smallest deployable compute unit Kubernetes creates and manages, and it can contain one or more tightly coupled containers that share network and storage context.
  • Desired state is not application correctness. A controller can make three Pods exist because the specification asks for three. That does not prove that checkout totals, authorisation decisions, database writes, or downstream responses are correct.
  • Self-healing is conditional. Kubernetes can restart or replace failed workload instances according to policies and health signals. It cannot repair an application defect merely by restarting it.
  • A Service is an access abstraction, not proof of availability. It decouples clients from changing Pod addresses. Healthy endpoints, valid routing, responsive dependencies, and a correct application still need verification.

Kubernetes in one control-loop model

The Kubernetes API stores objects that express intent. For objects with both fields, spec describes the desired state and status describes the current state reported by Kubernetes components. The control plane continually acts on differences between them. The upstream guide to Kubernetes objects calls an object a record of intent and explains this spec/status relationship.

Related guideKubernetes Monitoring: The Complete 2026 Guide

Human or automation declares intent
                |
                v
       Kubernetes API object
       spec = desired state
                |
                v
 Controllers compare desired and observed state
                |
                v
 Workload controllers create or replace Pod objects as needed
                |
                v
 Scheduler selects and binds a Node for an unscheduled Pod
                |
                v
 kubelet asks the container runtime to run containers
                |
                v
     Object status and Events show progress
                |
                +-----------------------> next reconciliation

Application and user outcomes
                |
                v
      Metrics + logs + traces + checks
                |
                v
 Humans or automation change code, config, policy, or spec

The upper loop is Kubernetes reconciliation. The lower evidence path is how a team decides whether the resulting application is actually useful and correct. They interact, but they are not the same loop.

Consider a Deployment with replicas: 3. If only two matching Pods exist, a controller can create another Pod. If the new Pod cannot pull its image, the declaration still says three while the observed state remains below the requested availability. Kubernetes exposes the mismatch; it does not invent a valid image or decide which application version the business intended.

This model also explains why Kubernetes is not simply a fixed sequence of “run A, then B, then C”. The platform uses independent control processes that repeatedly drive current state towards declared state. A controller may retry, another component may update status, and an operator may need to change the declaration when the declaration itself is wrong.

Control plane, worker nodes, and Pods

An upstream Kubernetes components page defines a cluster as a control plane plus one or more worker nodes. The precise deployment and ownership of those components vary, especially with a managed Kubernetes service, but their responsibilities remain a useful map.

Layer Core responsibility What it does not prove
API server Exposes the Kubernetes HTTP API through which objects are created, read, and changed That an accepted specification is safe or produces a correct application
etcd Stores API server data That application data is backed up, consistent, or recoverable
Scheduler Selects a suitable node for a Pod that has not yet been assigned That the node has unlimited future capacity or the application will meet its latency objective
Controller manager Runs controllers that implement Kubernetes API behaviour and reconciliation That a healthy-looking object means the business transaction is correct
kubelet Works on a node to ensure assigned Pods and their containers are running That a running process is ready, useful, secure, or producing correct results
Container runtime Runs containers on a node That the image is trusted or the application is correctly configured
Network and storage implementations Supply environment-specific connectivity and persistence mechanisms That every route, policy, volume, backup, or recovery objective is correct

A Pod is not a durable machine. The official Pods concept defines it as the smallest deployable unit Kubernetes can create and manage. A Pod may hold one application container or multiple tightly coupled containers, but all containers in that Pod are co-located and co-scheduled. Individual Pods are ephemeral; higher-level workload resources normally create replacements instead of treating a Pod name as a permanent host.

In a managed service, the provider may operate some control-plane components. That does not automatically transfer responsibility for workload definitions, identity, network policy, data protection, application telemetry, incident response, or upgrade compatibility. The actual boundary is provider-, service-, region-, and contract-specific, so record it rather than assuming it.

Choose a workload resource by lifecycle

Kubernetes normally manages Pods through higher-level workload resources. The upstream workloads guide distinguishes resources by lifecycle and identity rather than presenting one universal controller.

Resource Use it when State Kubernetes tries to maintain Important boundary
Deployment Replicas are interchangeable and the workload is normally stateless A selected number of Pods based on a Pod template, with rollout history and conditions It does not make an application stateless or validate a database migration
StatefulSet Pods need stable identities, ordered behaviour, or persistent-volume relationships Ordinal Pod identities and controller-managed rollout/scaling behaviour Stable identity is not data replication, backup, quorum safety, or disaster recovery
DaemonSet A node-local function should run on every eligible node or a selected subset A matching Pod on each eligible node A DaemonSet does not prove that the agent can reach its backend or that every emitted record is retained
Job A task should run to completion The requested successful completions under the declared retry and parallelism policy A completed process can still have produced an incorrect business result

The choice is conditional. A database is not automatically safe because it runs in a StatefulSet, and an agent is not automatically effective because its DaemonSet is Available. Start from the workload's identity, completion, placement, failure, and data requirements; then select and test the resource.

Where a Service fits

Pods created by a Deployment can be replaced, renamed, and assigned different IP addresses. A Kubernetes Service provides a network abstraction over a logical set of endpoints, usually Pods. Clients can address the Service while Kubernetes updates the associated endpoint set as matching Pods change.

That abstraction solves discovery and decoupling. It does not, by itself, establish that:

  • a selector points to the intended Pods;
  • a readiness check represents real ability to serve;
  • the application listens on the expected port;
  • network policy, DNS, load-balancer, or cloud-provider behaviour is correct;
  • a downstream database or external API is healthy;
  • a successful HTTP response contains the correct business result.

When a Service is unreachable, inspect the object chain—Service, selectors, EndpointSlices, Pods, readiness, ports, and network path—before treating “Kubernetes networking” as one undifferentiated cause.

What Kubernetes automates—and what remains your responsibility

The Kubernetes project explicitly says that Kubernetes is not a traditional all-inclusive PaaS. It provides building blocks and leaves important choices—such as CI/CD, application-level services, and logging or monitoring backends—to the user. The boundary below turns that principle into review questions.

|---|---|---|
| Placement | Schedule Pods against declared requests, constraints, and available nodes | Resource requests, topology, disruption tolerance, capacity, quotas, and what happens when no suitable node exists |
| Replica control | Create replacements and maintain a declared replica count | Whether the replica count is sufficient, whether state is safe, and whether replacement actually restores service |
| Rollouts | Coordinate changes between old and new Pod templates | Compatibility, readiness semantics, database changes, rollback safety, and business-result validation |
| Self-healing | Restart failed containers, replace failed Pods, and remove unsuitable endpoints under applicable policies | Application defects, persistent storage failures, corrupted data, dependency failures, and misleading health checks |
| Service abstraction | Decouple clients from changing backend Pod addresses | CNI and cloud implementation, DNS, policy, encryption, external exposure, and end-to-end reachability |
| Scaling mechanisms | Change replica counts when a configured scaling system has usable signals and policies | SLOs, signal quality, minimum capacity, scaling delay, cost, stateful limits, and safe scale-down |
| Extensibility | Add controllers, custom resources, admission logic, and add-ons | Version compatibility, supply-chain trust, permissions, failure isolation, and maintenance ownership |
| Observability hooks | Expose component signals and object state that pipelines can collect | Collection, redaction, retention, correlation, alert design, access control, and operational response |

The upstream self-healing guide gives concrete examples: container restarts depend on restartPolicy; workload controllers replace failed Pods to maintain replicas; and Services can stop routing to failed backends. The same guide also warns that storage recovery may require action and that underlying application errors must be addressed separately.

Desired state is not application correctness

The difference matters most during incidents. The following are hypothetical examples, not test results.

Observed Kubernetes condition What it may establish What remains unanswered
Three of three Pods are Ready The declared readiness checks passed for three Pods Whether responses are correct, a dependency is returning stale data, or users can complete a transaction
Deployment rollout is complete The controller reached its rollout conditions Whether a schema change is backward-compatible or the new code meets its error and latency objectives
A Service has ready endpoints Selectors and readiness produced endpoint candidates eligible for routing Whether those endpoints are reachable and whether DNS, network policy, external routing, TLS, and application responses work end to end
A failed container was restarted The restart mechanism acted according to policy Whether the failure cause is gone or an endless restart loop is consuming capacity
Replica count increased A scaling decision changed desired capacity Whether the bottleneck is CPU, a downstream dependency, lock contention, or an incorrect scaling signal

A reliable verification therefore needs at least two kinds of evidence: platform convergence evidence such as spec, status, conditions, Events, Pods, and endpoints; and application outcome evidence such as transaction checks, application metrics, logs, traces, data invariants, or user-experience signals. Neither is a substitute for the other.

kubectl -n k8s-definition-lab get deployment,replicaset,pod,service,endpointslice -o wide
kubectl -n k8s-definition-lab describe deployment demo
kubectl -n k8s-definition-lab describe pod <recorded-pod-name>
kubectl -n k8s-definition-lab get events --sort-by=.metadata.creationTimestamp
kubectl -n k8s-definition-lab rollout status deployment/demo --timeout=120s

Why observability still matters after reconciliation

Kubernetes object status answers questions about the platform's declared resources. It does not contain every application or user outcome. The upstream observability guide describes collecting and analysing metrics, logs, and traces from control-plane components, add-ons, and applications to understand cluster state, performance, and health. The Kubernetes overview separately states that Kubernetes does not dictate one logging, monitoring, or alerting solution.

Related guideKubernetes Integration

Use three evidence layers during an investigation:

  1. Cluster and node evidence: API server, scheduler, controller, kubelet, runtime, node resource, network, and storage signals. This layer asks whether the platform can run the declared workload.
  2. Object and workload evidence: object spec/status, conditions, Events, Pods, replicas, readiness, EndpointSlices, and object-state metrics. This layer asks where convergence is blocked or changing.
  3. Application and user evidence: request metrics, application logs, distributed traces, synthetic checks, business invariants, and user experience. This layer asks whether the workload performs the intended service correctly.

Kubernetes components expose Prometheus-format metrics, and tools such as kube-state-metrics can expose object-state information, but endpoint availability, authentication, metric stability, collection, and retention are implementation concerns. Likewise, container logs must be collected and retained outside the container lifecycle if the team needs central history. Do not infer that a cluster stores and correlates all telemetry simply because the components emit it.

Start from the symptom, then choose the first evidence

This table is a triage entry point, not a universal root-cause tree.

Symptom First object or signal Question it answers Evidence to inspect next
Pod remains Pending Pod conditions and Events Is placement blocked by capacity, constraints, storage, or another scheduling condition? Node capacity, requests, affinity, taints, volume binding, scheduler evidence
Container keeps restarting Container state, last state, restart count, Events Did the process exit, fail a probe, or encounter a runtime condition? Previous container logs, application error, probe semantics, resource pressure, dependency state
Deployment does not complete Deployment conditions, ReplicaSets, new Pods Is the new revision unable to become Available? Image pull, admission, scheduling, readiness, quota, old/new revision state
Service has no endpoints Service selector, Pod labels, readiness, EndpointSlices Are any matching Pods considered ready backends? Port mapping, readiness logic, network path, application listener
Service has endpoints but requests fail End-to-end check plus application logs/traces Is the failure beyond discovery and endpoint selection? DNS, policy, proxy/load balancer, TLS, downstream dependencies, application response
Pods are Ready but users see latency Application and user latency, traces, dependency metrics Is the application slow even though platform readiness passes? Code path, queue, database, external API, saturation, recent change

The practical rule is to preserve identifiers that let these layers meet: cluster, namespace, workload, Pod, container, service, environment, version, trace context, and change reference. Do not put credentials, personal data, session IDs, or unbounded user identifiers into telemetry merely to make correlation easier.

A conditional Kubernetes adoption worksheet

This worksheet is a Guance editorial tool, not an official Kubernetes scorecard. It intentionally has no universal point total. A security, data-recovery, or ownership blocker cannot be cancelled out by several easy “yes” answers elsewhere.

Decision question Evidence to collect Kubernetes is more plausible when Pause or compare a simpler option when
What operational problem requires a platform? Current deployment, scaling, recovery, and release failure records Multi-workload scheduling, repeatable rollouts, placement, or common policy are real needs The goal is only to run one simple service and an existing managed runtime already meets it
What is the workload lifecycle? Stateless/stateful/batch mix, identity, completion, dependency, and disruption requirements The workload maps clearly to tested controllers and failure policies The team is choosing Kubernetes before defining state, identity, and recovery behaviour
Who owns the platform lifecycle? Named owners for upgrades, nodes, add-ons, access, incidents, and capacity Ownership, maintenance time, and escalation paths are funded Kubernetes is expected to remove operations work without assigning new responsibilities
How will correctness be checked? Readiness semantics, SLOs, transaction checks, data invariants, and rollback criteria Platform and application evidence are both testable “Pod is Running” is the only success condition
How will state recover? Backup, restore test, replication, RPO/RTO, volume and zone failure evidence Recovery has been exercised independently of controller status StatefulSet or persistent volume is being treated as a backup strategy
What are the network and security boundaries? Identity, RBAC, admission, secret flow, policy, ingress/egress, image trust, and audit requirements Controls have owners and can be tested before production Required controls, permissions, or data paths are not publicly documented
Can the team observe and debug it? Signal inventory, correlation keys, retention, alerts, runbooks, and incident exercise A known failure can be traced from user symptom to cluster and application evidence Telemetry exists in separate tools but cannot support an investigation or protect sensitive data
What is managed by the provider? Service scope, shared-responsibility document, version policy, availability design, and support terms The provider boundary reduces work the team cannot or should not own “Managed” is assumed to include workloads, data, networking, and incident response without evidence
How can the team reverse the decision? Migration stages, parallel-run plan, data export, configuration ownership, and rollback drill A bounded pilot can be removed without risking the production service Adoption requires an irreversible platform rewrite before the first useful test

Decision rule

Proceed to a bounded prototype when the workload problem is concrete, the resource model fits, accountable owners exist, and the critical security, data, recovery, and observability conditions can be tested. Compare a simpler container or application platform when Kubernetes would add a control plane, networking, storage, and upgrade surface without solving a measured operational need. Keep the decision open when a material condition is not publicly documented; design a test that can resolve it instead of converting uncertainty into a positive assumption.

Singapore deployment questions

Next step by intent

Keep each page and document responsible for one task:

Do not copy a token, kubeconfig, customer cluster name, private endpoint, or credential into a worksheet, ticket, screenshot, or example. Configuration and permissions should stay in the relevant Docs and approved operational system.

Primary sources

The technical claims in this draft were checked against these first-party sources on 1 August 2026:

  1. Kubernetes — Overview: definition, declared capabilities, and what Kubernetes is not.
  2. Kubernetes — Components: control-plane and node-component responsibilities.
  3. Kubernetes — Objects: object intent, spec, status, and desired state.
  4. Kubernetes — Pods: the Pod unit and shared context.
  5. Kubernetes — Workloads: Deployment, StatefulSet, DaemonSet, Job, and controller boundaries.
  6. Kubernetes — Service: stable access abstraction over changing backends.
  7. Kubernetes — Self-healing: restart, replacement, endpoint, storage, and application-error boundaries.
  8. Kubernetes — Observability: metrics, logs, traces, and typical signal pipelines.
  9. Guance Docs — Kubernetes integration, KubernetesPrometheus discovery, ServiceMonitor / PodMonitor supported subset, and container infrastructure: Guance-specific next-step documentation only.

Continue reading