---
term: 'Kubernetes'
seoTitle: 'What is Kubernetes (K8s)? Complete Guide'
headline: 'What is Kubernetes (K8s)?'
slug: kubernetes
category: cloud-architecture
shortDefinition: 'Kubernetes is an open-source platform that automates deploying, scaling, and operating containerized applications across many machines.'
relatedTerms:
  - containerization
  - infrastructure-as-a-service
  - microservices-vs-monolith
  - no-ops-development
  - ci-cd
contrastsWith:
  - no-ops-development
faq:
  - question: 'What is Kubernetes in simple terms?'
    answer: 'An orchestra conductor for containers. You declare what should be running — this app, three copies, this much memory — and Kubernetes continuously makes reality match: placing containers onto machines, restarting them when they crash, scaling them with load, and routing traffic to healthy copies. It turns a fleet of machines into one programmable pool.'
  - question: 'What does K8s stand for?'
    answer: 'It is a numeronym: K, then eight letters, then s — the same pattern as i18n for internationalization. The name itself is Greek: kubernetes means helmsman or pilot, the person steering the ship, which is also why so many tools in its ecosystem carry nautical names and the logo is a ship''s wheel.'
  - question: 'Is Kubernetes the same as Docker?'
    answer: 'No — they answer different questions. Docker builds and runs individual containers on one machine; Kubernetes orchestrates many containers across many machines. They are complementary: images built with Docker run on Kubernetes clusters. Since version 1.24, Kubernetes no longer uses Docker itself as its runtime — it speaks to any standard container runtime — but Docker-built images work exactly as before, because images follow the OCI open standard.'
  - question: 'What are a cluster, a node, and a pod?'
    answer: 'The cluster is the whole system: a control plane plus worker machines. A node is one machine in it, physical or virtual. A pod is the smallest deployable unit — one or more tightly coupled containers that share a network identity and storage. You almost never run a bare pod; you declare a Deployment, and Kubernetes manages the pods for you.'
  - question: 'What is the Kubernetes control plane?'
    answer: 'The cluster''s brain: an API server that everything talks through, a key-value store holding the cluster''s desired and actual state, a scheduler that decides which node each pod lands on, and controllers that continuously reconcile reality against declarations. Worker nodes run an agent, a network proxy, and the container runtime that actually executes pods.'
  - question: 'Who created Kubernetes and when?'
    answer: 'It was open-sourced in June 2014, born from more than a decade of internal container-orchestration experience at one of the largest technology companies, and reached version 1.0 in July 2015 — when it was donated to the newly created Cloud Native Computing Foundation (CNCF). Written in Go, it has since become one of the largest open-source projects in the world.'
  - question: 'When is Kubernetes overkill?'
    answer: 'More often than the hype admits. A small team running a handful of containers with predictable traffic gains little from a cluster and inherits a steep learning curve, YAML sprawl, and an operational discipline built for fleet-scale problems. Simpler paths — a compose file on one host, a managed container platform, a PaaS, or a BaaS — cover most workloads below serious scale.'
  - question: 'What is managed Kubernetes?'
    answer: 'A cloud service that runs the control plane for you — upgrades, availability, state store — while you manage workloads and node pools. It removes the hardest operational layer and is how most production Kubernetes actually runs. Self-managing a cluster end to end remains the province of platform teams with dedicated expertise; the control plane is unforgiving infrastructure.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Kubernetes documentation — Overview'
    url: 'https://kubernetes.io/docs/concepts/overview/'
  - name: 'Kubernetes components (kubernetes.io)'
    url: 'https://kubernetes.io/docs/concepts/overview/components/'
  - name: 'Cloud Native Computing Foundation — Kubernetes'
    url: 'https://www.cncf.io/projects/kubernetes/'
  - name: 'Kubernetes (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Kubernetes'
cta:
  title: 'The backend without the cluster'
  text: 'Back4app gives you what most teams actually want from Kubernetes — deployed, scaled, self-healing backend services — without operating one: managed database, auth, APIs, and Cloud Code functions. And when you do have a container, Back4app Containers runs it for you.'
  linkText: 'Start Free'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-07-24'
translationKey: kubernetes
---

**Kubernetes is an open-source platform that automates deploying, scaling, and operating containerized applications across many machines.** Its core idea is declarative: you state the desired end state — *three replicas of this container, this much memory, reachable on this port* — and the system works continuously to make reality match, restarting, rescheduling, and scaling without being asked.

## Key takeaways

| Question | Answer |
| --- | --- |
| What it is | A control system that turns many machines into one pool for containers |
| The core idea | Declare desired state; the cluster reconciles reality to it, forever |
| vs. Docker | Docker builds and runs containers; Kubernetes orchestrates fleets of them |
| Name | Greek for "helmsman"; K8s = K + eight letters + s |
| The honest caveat | Fleet-scale power, fleet-scale complexity — many teams need neither |

## The manifest: how you talk to Kubernetes

Everything is a declaration. This is a minimal, real Deployment — annotated in plain English:

```yaml
apiVersion: apps/v1
kind: Deployment              # "keep N copies of this running"
metadata:
  name: api
spec:
  replicas: 3                 # the desired state: three pods
  selector:
    matchLabels: { app: api }
  template:                   # what each pod contains
    metadata:
      labels: { app: api }
    spec:
      containers:
        - name: api
          image: registry.example.com/api:1.4.2
          ports: [{ containerPort: 8080 }]
          resources:
            limits: { memory: "256Mi", cpu: "500m" }
# Apply it, kill a pod, watch Kubernetes resurrect it. That's the product.
```

For contrast — the same outcome (a deployed, scaled, self-healing backend) consumed as a service, where the manifest, the cluster, and the 3 a.m. reconciliation are somebody else's YAML:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// The workload the manifest would have described — already running
const status = await Parse.Cloud.run('healthCheck');
console.log(status); // scheduling, scaling, restarts: the platform's job
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('healthCheck');
final response = await function.execute();
if (response.success) {
  print(response.result); // no pods, no manifests, no cluster to run
}
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("healthCheck") { result in
  if case .success(let status) = result {
    print(status) // no pods, no manifests, no cluster to run
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
ParseCloud.callFunctionInBackground<String>("healthCheck", hashMapOf()) { status, e ->
  if (e == null) Log.d("Health", status) // no pods, no manifests, no cluster
}
```

## Inside a cluster

```mermaid
flowchart TB
  accTitle: Kubernetes cluster architecture
  accDescr: A control plane with an API server, state store, scheduler, and controllers manages worker nodes; each node runs an agent, a network proxy, and a container runtime hosting pods.
  subgraph CP["Control plane — the brain"]
    a["API server"] --- b["State store"]
    a --- c["Scheduler"]
    a --- d["Controllers<br/>(reconcile desired vs. actual)"]
  end
  subgraph N1["Worker node"]
    e["Agent + network proxy"] --> f["Pods<br/>(containers)"]
  end
  subgraph N2["Worker node"]
    g["Agent + network proxy"] --> h["Pods"]
  end
  CP --> N1
  CP --> N2
```

The vocabulary, one line each: a **cluster** is the whole system; a **node** is one machine; a **pod** is the smallest deployable unit (one or more containers sharing network and storage); a **Deployment** manages replicated pods with rolling updates and rollbacks; a **Service** gives ephemeral pods a stable address; an **Ingress** routes outside traffic in; **ConfigMaps and Secrets** carry configuration; **namespaces** partition one cluster among teams. [The official overview](https://kubernetes.io/docs/concepts/overview/) is the canonical next step down.

## Kubernetes vs. Docker

| Question | Docker | Kubernetes |
| --- | --- | --- |
| Job | Build, package, run containers | Orchestrate containers across machines |
| Scope | One machine | A cluster |
| Unit | Container | Pod (of containers) |
| Scaling | Manual | Declarative and automatic |
| Relationship | Builds the images | Runs them — via any standard OCI runtime |

The perennial confusion has a date attached: since v1.24 (2022), Kubernetes dropped its Docker-specific runtime shim and speaks only to standard container runtimes. Nothing broke — images follow the open OCI standard — but it made the roles crisp: Docker is the shipyard, Kubernetes is the harbor authority. The name knew this all along: *kubernetes* is Greek for helmsman — it was [open-sourced in June 2014, hit 1.0 in 2015, and seeded the CNCF](https://www.cncf.io/projects/kubernetes/), distilling a decade of fleet-scale container operations into a public commons.

## Common use cases

- **Microservices fleets.** Dozens of services with independent scaling and deploys — the workload Kubernetes was shaped by.
- **Platform teams.** Building an internal platform on one substrate that runs identically on any cloud or on-premises.
- **Bursty large-scale workloads.** Batch jobs, data pipelines, ML training — bin-packed onto shared capacity.
- **Multi-cloud and portability strategies.** The compute layer of a [vendor-lock-in](/glossary/cloud-vendor-lock-in/) defense — with the caveat that surrounding managed services still lock.
- **Self-healing production estates.** Anywhere "a machine died at 3 a.m." must be a non-event rather than a page.

## Should you run Kubernetes? A decision matrix

| Run Kubernetes when… | Skip it when… |
| --- | --- |
| Many services, many teams, independent scaling | One app, one team, predictable load |
| A platform team owns the cluster as its product | Nobody owns ops full-time |
| Portability across clouds is a hard requirement | Speed to market is the only requirement |
| Workloads are containerized and fleet-shaped | The backend needs are standard CRUD + auth |
| You've outgrown simpler orchestration | A compose file or managed platform still fits |

The industry's quiet consensus: most teams operating Kubernetes are below the scale where it pays. The alternatives ladder — one host with a compose file, a managed container service, a PaaS, a BaaS — covers everything up to genuine fleet problems, and managed Kubernetes covers most of what remains.

## Limitations and trade-offs

- **The learning curve is the product's shadow.** Pods, services, ingress, RBAC, operators, Helm — fluency is measured in months, and the cluster doesn't wait.
- **Operational surface.** Upgrades, certificate rotation, networking plugins, and state-store health are unforgiving; this is why managed control planes won.
- **YAML sprawl.** Declarative config at scale becomes its own codebase, with its own reviews, bugs, and drift.
- **It orchestrates containers, not architecture.** A poorly bounded system on Kubernetes is the same system, now distributed — the cluster amplifies design, good or bad.
- **Kubernetes is not a PaaS.** By design it ships no CI/CD, no default database, no app-level services — the platform on top is yours to assemble, which is precisely the work higher abstractions sell back as a product.

## Kubernetes and Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. The relationship to Kubernetes is honest division of labor: what most application teams actually want from a cluster — deployed, scaled, self-healing backend services — is exactly what the BaaS layer delivers with zero manifests to write. And for workloads that genuinely are containers, [Back4app Containers](https://www.back4app.com/container-as-a-service) runs them as a managed service: push an image, get orchestration, without owning the harbor.