What is Kubernetes (K8s)?

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

The manifest: how you talk to Kubernetes

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

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 / 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 — 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
}

// 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
  }
}

// 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

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 is the canonical next step down.

Kubernetes vs. Docker

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, 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 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

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 runs them as a managed service: push an image, get orchestration, without owning the harbor.