Cloud migration · Container orchestration
Kubernetes container orchestration: how it works and what it takes to run it in Saudi Arabia
Kubernetes container orchestration is the work of starting, placing, connecting, scaling and restarting containers across a group of machines, so that nobody has to do it by hand. This guide explains what Kubernetes is and how its architecture fits together, how it relates to Docker, and what an enterprise in Saudi Arabia has to settle before a cluster carries production: where it runs, how it is monitored, how traffic reaches it and who operates it. Interkey plans and carries out Kubernetes migrations from Riyadh and operates clusters afterwards.
Published 8 min read
Orientation
At a glance
The whole page in one table, before the detail.
- What it is
- Software that runs containers across many machines and keeps them in the state you declared
- Main parts
- A control plane that decides, worker nodes that run pods, and services and ingress that route traffic
- Kubernetes vs Docker
- Docker builds and runs single containers; Kubernetes orchestrates many of them across a cluster
- Where clusters run in KSA
- A cloud provider's managed service where your data may live there, or self-run inside the Kingdom
- When it is the wrong fit
- A few stable applications that deploy rarely: the cluster costs more to run than they do
- Where Interkey fits
- Assessment, migration, cluster build and operation, with support from Riyadh
In short, for decision makers
- What it buys you: releases that become routine, failed containers replaced without a call-out, and capacity that follows load.
- What it costs: a platform somebody must own for years, with upgrades, monitoring and on-call.
- The first decision: managed or self-run. Where your data may live usually settles it.
- The common mistake: moving applications that were never fixed to run as several copies.
What Kubernetes container orchestration does, in plain words
A container packages an application with everything it needs to run, so it behaves the same on a laptop, a test server and production. One container is easy to manage. Hundreds, spread over many machines, are not: someone has to decide where each runs, restart the ones that fail, add copies when load rises and send traffic only to healthy ones. That job is container orchestration.
Read more
So what is Kubernetes? It is open-source software that does this job. You describe the state you want, for example three copies of the billing service, a given version, a given amount of memory, and Kubernetes keeps working to make the cluster match that description. When a machine fails, its containers are started elsewhere. When a release goes out, old copies are replaced a few at a time, and the release can be rolled back the same way. This declarative model is the real change for an operations team: instead of a runbook of manual steps, the desired state is written down, reviewed and versioned like code.
Kubernetes architecture: the control plane and the worker nodes
Read more
A cluster has two halves. The control plane decides: the API server receives every instruction, the scheduler picks a machine for each new workload, controllers keep comparing what runs with what was declared, and a store holds the cluster's state. The worker nodes do the running: each has an agent, the kubelet, and a container runtime that starts the containers.
Containers run inside pods, the smallest unit Kubernetes places. A deployment says how many copies of a pod to keep; a service gives those copies one stable address; ingress brings requests from outside the cluster to the right service. With a managed service the provider runs the control plane for you; self-run, your team or your partner runs both halves.
Kubernetes vs Docker: what each one does
| Question | Docker | Kubernetes |
|---|---|---|
| Main job | Building container images and running containers on one machine | Running many containers across a cluster of machines |
| Where developers meet it | Docker Desktop and the build on their own laptop | Mostly through the deployment pipeline |
| What it decides | How one container is built and started | Where each container runs, how many copies, and how traffic reaches them |
| Failure handling | A container can be set to restart on the same machine | Failed pods are replaced, on another node if needed |
| Scaling | You start more containers yourself, on the machines you choose | Copies are added or removed to match the declared count or the measured load |
| Licensing to check | Docker Desktop needs a paid subscription for larger companies and government entities, by Docker's terms | Open source; you pay for the infrastructure and, if managed, the provider's service |
The two are partners, not alternatives: teams build images with Docker and run them on Kubernetes. Licence rules for Desktop are set out on our Docker Business page.
Managed Kubernetes or a self-run cluster in Saudi Arabia
Managed Kubernetes means a cloud provider runs the control plane, its upgrades and its availability, and you run what sits on it. It is the sensible default when your data is allowed to live in that provider's region. Google Cloud runs a region in Dammam (me-central2). AWS has announced a Saudi Region and says it is on track for December 2026; it was not in AWS's Region list on 2 November 2026, as our AWS page records.
Read more
A self-run cluster inside the Kingdom is chosen when a constraint forces it, usually data classification. You then own versions, upgrades and rollback discipline. Which rules apply depends on your sector and data; the National Cybersecurity Authority (NCA) publishes cybersecurity controls, including for cloud computing.
Many organisations in the Kingdom end up with both: workloads that may leave the Kingdom on a managed service, and classified ones on a self-run cluster inside it. That works as long as every cluster has its own standards and owner, and monitoring and access are the same across all of them.
What an enterprise cluster needs beyond the orchestrator
| Area | Why it matters | What to decide before go-live |
|---|---|---|
| Monitoring | Pods come and go, so host checks miss most problems | Which metrics, logs and traces you keep, and who is alerted |
| Ingress | Every outside request passes through it | The controller, TLS certificates, and whether an API gateway sits in front |
| Access and policy | One shared admin account fails a security review | Roles mapped to real teams, and what is refused at admission |
| Images and secrets | You must know what runs and where credentials live | A private registry, image scanning, secrets outside the code |
| Upgrades and backup | Kubernetes versions move and support for old ones ends | An upgrade cadence, a tested rollback and a proven restore |
| Developer machines | Desktop tools may need licences | Who needs a Docker Desktop subscription, and which plan |
Two of these rows surprise most teams. Monitoring a cluster is not monitoring servers: the unit of failure is a pod that may live for minutes, so the data has to follow workloads, namespaces and releases, and its volume has to be controlled from the start. And the developer desktop is part of the platform: under Docker's terms, larger companies and government entities need a paid subscription to use Docker Desktop, so the licence count belongs in the plan.
Monitoring is set out on our Kubernetes monitoring page, and traffic routing on the Kubernetes ingress controller page.
Where Kubernetes fits, and where it does not
It fits when many services release often, when the same application must behave identically in several environments, or when load changes enough that capacity should follow it. It also suits teams that want deployment to become routine rather than an event.
Read more
It does not fit an application that runs on one server and is deployed twice a year. Containers will not make it faster, and the cluster will cost more to operate than the application costs to run. Nor does it repair an application that keeps session state on local disk or assumes it is the only copy: that is fixed in the application first. Our Docker and Kubernetes page covers that work. An honest assessment ends with a list of applications that stay where they are.
RelatedDocker and Kubernetes page
How Interkey runs a Kubernetes migration
-
Inventory and classify.
Every application, its dependencies, its data class and its owner.
-
Decide per application.
Leave, retire, rehost, replatform or rewrite, with the reason recorded.
-
Unblock the application.
Fix what stops it running as several copies, then build images and pipelines.
-
Build the cluster.
Managed or self-run, with ingress, secrets, monitoring and the deployment pipeline.
-
Move in dependency order.
Something real but recoverable first, with the old system live alongside.
-
Operate and decommission.
A named owner for the cluster, and the old estate switched off.
What drives the cost and the timeline
Each engagement is quoted from its own scope. The factors that move it most are the number of applications and how much each needs fixing, managed versus self-run, the environments required, the overlap while old and new run together, and the day-two scope afterwards. The timeline follows the same factors and is usually set by other teams' change windows; we give a realistic first phase early and a range for the rest once the inventory exists. The full route for the move is on the Kubernetes migration page.
The engineers who build the cluster are Interkey's own team in Riyadh, working in Arabic or English on the Saudi working week, and they can operate it afterwards under a written managed services scope.
Relatedmanaged services
Questions buyers ask about Kubernetes container orchestration
If our developers already use Docker, why would we also need Kubernetes?
Docker builds and runs containers on one machine. Kubernetes runs many of them across a cluster: it places them, replaces the ones that fail and spreads traffic. A handful of stable applications may need only Docker.
Is Kubernetes worth it for a Saudi company with only a few applications?
Often not yet. A cluster needs upgrades, monitoring and an owner, and that cost does not shrink with the number of applications. It pays off when many services release often or load changes a lot.
Where can a Kubernetes cluster run if our data must stay in the Kingdom?
On a managed service in a provider region inside Saudi Arabia, such as Google Cloud in Dammam, where your classification allows it, or on a self-run cluster on infrastructure in the Kingdom.
What does running Kubernetes cost beyond the servers?
The people and tools around it: monitoring, upgrades, security policy, on-call and, for self-run clusters, the control plane. Docker Desktop subscriptions may also apply to developer machines. We quote from your scope.
How soon can a first production workload run on Kubernetes?
It depends on how much the first application needs fixing and how quickly access and security approvals come through. We name a realistic first phase after the assessment, then a range for the rest.
Who supports our Kubernetes clusters day to day from inside Saudi Arabia?
Your team, Interkey's engineers in Riyadh under a written managed-services scope, or both. The owner is named before the cluster is built.
Next
Related pages
Next step
Ask whether Kubernetes fits your applications
Tell us what runs where today, how often you release, and whether your data must stay in the Kingdom. That is enough for a first answer.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia