Containers and Kubernetes are the backbone of how modern software is built and deployed, and they are surrounded by jargon that makes them sound harder than they are. This article separates the two ideas — packaging an application (containers) and running lots of them reliably (Kubernetes) — and is written for the buyer or new engineer who needs the whole shape before the detail.
It sits under the cloud computing pillar, alongside server virtualisation — the technology containers are most often confused with.
What a container is
The clearest way in is to compare a container with a virtual machine. A virtual machine virtualises the hardware: a hypervisor runs several VMs on one server, and each VM carries a full guest operating system of its own. A container virtualises the operating system instead: containers on a host share that host's OS kernel, and each one isolates just the application and its dependencies. That single difference cascades into everything else.
| Virtual machine | Container | |
|---|---|---|
| What it virtualises | The hardware (via a hypervisor) | The operating system (shared host kernel) |
| Carries | A full guest OS per VM | Just the app and its dependencies |
| Size / start-up | Gigabytes; boots in minutes | Megabytes; starts in seconds or less |
| Density | Tens per server | Hundreds per server |
| Isolation | Strong — full OS boundary | Lighter — process-level, kernel shared |
Containers are not "lightweight VMs" — they use a genuinely different mechanism. The trade-off is that VMs give stronger isolation (a full OS boundary), while containers give far greater speed and density. Most teams run containers inside VMs to get both.
Images, registries and the OCI standard
A running container starts from a container image — an immutable, layered package containing the application and everything it depends on. You build the image once and run it anywhere, which is the source of the famous promise that it "works the same on my machine and in production". Images live in a registry — a store such as Docker Hub or a private registry your organisation runs — from which they are pulled to wherever they will run.
Crucially, none of this is locked to one vendor. The Open Container Initiative (OCI) standardises the image and runtime formats, so an image built with one tool runs on any compliant runtime. That open standard is a large part of why containers became universal rather than a single company's product.
Why containers changed how software ships
Four things followed from that simple package, and together they reshaped software delivery:
- Portability — the same image runs unchanged from a developer's laptop to any cloud, ending "it worked in test".
- Density and efficiency — far more workloads per server than VMs, which cuts infrastructure cost.
- Microservices — applications split into small, independently deployable services, each in its own container.
- CI/CD and immutability — fast, repeatable, automated deployments of a fixed artifact, rather than patching a running server in place.
What Kubernetes is
Running one container is easy. Running hundreds across a fleet of servers — scheduling them onto machines, restarting the ones that fail, scaling them up and down with demand, connecting them, and rolling out new versions without downtime — is hard. Kubernetes (often written K8s) is the orchestrator that does all of that. It is an open-source project stewarded by the Cloud Native Computing Foundation and is the de facto standard for running containers at scale.[1]
Its defining idea is declarative, desired-state management: you describe the state you want — "run five copies of this service, behind this address" — and Kubernetes continuously works to make reality match, replacing failed copies and rebalancing as machines come and go. You manage the goal, not each step.
How Kubernetes works
A handful of terms unlock most Kubernetes conversations:
- Pod — the smallest deployable unit: one or more containers that share networking and storage and are scheduled together.
- Node — a worker machine (physical or virtual) that runs pods.
- Cluster — a set of nodes managed as one.
- Control plane — the brain: the API server you talk to, the scheduler that places pods, the controllers that drive toward desired state, and etcd, the store that holds the cluster's state.
- Deployment and Service — a Deployment declares how many copies of an app to run and how to update them; a Service gives them a stable address.
Managed Kubernetes vs your own
Kubernetes is powerful and genuinely complex to operate — upgrades, the etcd datastore, networking and security all demand real expertise. That is why most organisations do not run it themselves. The major clouds offer managed Kubernetes — Amazon EKS, Google GKE and Azure AKS — which run the control plane for you, leaving you to deploy workloads rather than babysit the cluster.
| Managed (EKS / GKE / AKS) | Self-managed | |
|---|---|---|
| Control plane | Run and upgraded by the cloud provider | You run, patch and back up etcd and the control plane |
| Effort | Deploy workloads; provider handles the plumbing | Significant platform-engineering team required |
| Best for | The large majority of organisations | Specialised needs, on-prem, or deep customisation |
Containers and Kubernetes in Singapore
Singapore runs containers at national scale, and the government's own platform is a useful reference. The Singapore Government Tech Stack (SGTS) includes CStack, a centralised, secure and fully managed platform for containers and Kubernetes, and SHIP-HATS, the CI/CD toolchain that builds, tests and deploys onto it with DevSecOps guardrails.[3] Together they are how many government digital services are now built and shipped.
The portability payoff shows up in the Government on Commercial Cloud (GCC) programme: GovTech has been shifting the deployment of services onto Kubernetes specifically so that workloads can run across multiple clouds without changing the application.[2] That is the container promise in practice — the same image, the same orchestration, portable across providers — and a pattern any Singapore enterprise pursuing a multi-cloud or exit-optionality strategy can learn from.
When to reach for Kubernetes
Kubernetes is a heavy tool, and using it where it is not needed adds cost and complexity for no return. A straight answer:
- Reach for it when you run many services, need automatic scaling and self-healing, have multiple teams shipping independently, or want workload portability across clouds.
- Skip it for a single application, a small team, or anything a managed platform-as-a-service or serverless option would run with far less operational burden.
- If you do adopt it, start with managed Kubernetes, not a self-built cluster — the control plane is where most of the operational pain lives.
- Be honest about the team. Kubernetes rewards platform-engineering maturity; without it, the cluster becomes the problem rather than the solution.
Adopting containers or Kubernetes?
Container platforms live or die on how they are built and run. Compare Singapore cloud and system-integration partners who design, migrate and operate Kubernetes.
Browse Cloud & Systems Integrators in Singapore
Frequently asked questions
What's the difference between a container and a virtual machine?
A virtual machine virtualises hardware and carries a full guest operating system, so it is heavier and boots in minutes. A container virtualises the operating system — containers on a host share the host's kernel and package only the application and its dependencies — so it is far smaller, starts in seconds, and packs many more workloads onto a server. They are different mechanisms, not the same thing at different sizes, and teams often run containers inside VMs to get both isolation and density.
Do we actually need Kubernetes?
Often not. Kubernetes earns its complexity when you run many services that need automatic scaling, self-healing and independent deployment, or you want portability across clouds. For a single application or a small team, a managed platform-as-a-service or serverless option usually delivers the same outcome with a fraction of the operational burden. Adopt Kubernetes because you need orchestration, not because it is the default answer.
Docker vs Kubernetes — what's the difference?
They do different jobs. Docker is a popular tool for building container images and running individual containers. Kubernetes is an orchestrator that runs and manages large numbers of containers across many machines — scheduling, scaling, healing and networking them. You commonly use Docker (or a similar tool) to build the images that Kubernetes then runs. One packages and runs a container; the other coordinates a fleet of them.
What is a pod?
A pod is the smallest deployable unit in Kubernetes: one or more containers that are scheduled together and share networking and storage. Most pods hold a single container, but tightly coupled helpers can share a pod. Kubernetes schedules, scales and heals at the level of pods rather than individual containers.
Should we run our own Kubernetes or use managed?
For the large majority of organisations, use managed Kubernetes — Amazon EKS, Google GKE or Azure AKS run the control plane, upgrades and etcd for you, so your team deploys workloads instead of operating the platform. Self-managed Kubernetes only makes sense for specialised needs, on-premises requirements or deep customisation, and it demands a real platform-engineering team.
Are containers secure?
Containers can be secure, but they need attention because they share the host kernel and pull images from registries. The essentials: use trusted, scanned base images from a controlled registry, keep them patched, run containers with least privilege (not as root), isolate sensitive workloads, and apply the same identity and network controls you would elsewhere. Managed Kubernetes helps by keeping the control plane current, but image and workload security remain your responsibility.
Sources
- Kubernetes Documentation: Concepts — Kubernetes (Cloud Native Computing Foundation) — official checked 2026-09-01
- Government on Commercial Cloud (GCC) — Government Technology Agency of Singapore (GovTech) — official checked 2026-09-01
- SHIP-HATS, Singapore Government Tech Stack — Singapore Government Developer Portal (GovTech) — official checked 2026-09-01
Related resources
Go deeper on this topic
Knowledge base
- Backup and Disaster Recovery Explained: RPO, RTO and What They Cost
- Object vs Block vs File Storage Explained
- Cloud Computing Explained: IaaS, PaaS, SaaS, Hybrid and Landing Zones
- Server Virtualization Explained: Hypervisors, Virtual Machines and Enterprise Infrastructure in 2026
- Edge Computing Explained: Latency, Local Processing and Distributed Apps
- Network Virtualisation Explained: VLANs, VXLAN, Overlays and SDN
Vendor directories
Research cluster
Related analysis
Recent TechDirectory Insights coverage from the same research cluster.