A familiar story in platform teams goes like this. The organisation decides to "move to Kubernetes". A managed cluster is created in an afternoon. Applications are containerised and deployed. A celebration is held. Then, over the following year, the team discovers everything the cluster did not come with: a sensible way to get traffic in, a reliable way to deploy, any guardrails at all, and a clear view of what is running.
Kubernetes is an excellent engine. It schedules containers, restarts them when they fail, scales them and gives you a consistent API across clouds. It is deliberately not a platform. It leaves the decisions about traffic, delivery, policy, visibility and secrets to you.
CloudNala's view is that a production Kubernetes estate needs a small, deliberate set of components around the engine, each with an owner, adopted in stages the team can absorb. Small is the important word. The CNCF landscape offers dozens of options in each area. A 15-person team needs one per job, chosen with the scorecard from Part 3, and owned before the next one arrives.
Baobab Retail Group is fictional, and its systems and figures are illustrative. Baobab's platform team runs managed Kubernetes for the e-commerce app, store systems integration and pricing services. Two years in, it had a cluster and a growing list of incidents that the cluster itself could not have prevented.
The minimum set around the engine
Each layer below answers one question the engine does not. The maturity levels are as listed by the CNCF on 28 October 2026.
Traffic: how requests get in. Kubernetes defines APIs for routing external traffic but leaves the implementation to a controller you install. The Kubernetes project's direction here is the Gateway API, developed by SIG Network as the successor to the older Ingress API. Gateway API is a Kubernetes API, not a separate CNCF project, so it has no CNCF level of its own. Its implementations do: Envoy is Graduated, and Contour and Emissary-Ingress are Incubating, for example. For TLS, cert-manager (Graduated) automates certificate issuance and renewal.
This layer also carries the clearest recent warning in the ecosystem. In November 2025, Kubernetes SIG Network and the Security Response Committee announced that Ingress NGINX, one of the most widely deployed ingress controllers, would be retired in March 2026, with no further releases or security fixes after that, and recommended migrating to Gateway API or another controller. If you still run it, that migration belongs at the top of your list.
Delivery: how change arrives. A GitOps controller makes the cluster match a declared state in Git, so every change is reviewed, versioned and reversible. Argo (which includes Argo CD) and Flux are both Graduated.
Guardrails: what is allowed. An admission policy engine checks workloads before they are created: no privileged containers, resource limits set, images from approved registries. Kyverno is Graduated, and OPA, whose ecosystem includes Gatekeeper, is Graduated. Network policy, which decides which workloads may talk to each other, belongs here too; Firewalls, security groups and network policy covers how to decide which flows should exist.
Visibility: what is happening. OpenTelemetry, announced as Graduated in May 2026, gives a vendor-neutral way to produce and collect traces, metrics and logs. Prometheus, Graduated, stores metrics and drives alerts. Between them, they mean your telemetry format does not depend on any one observability vendor.
Secrets: where credentials come from. Kubernetes Secrets are a storage mechanism, not a secrets management strategy. Most teams on a hyperscaler sync secrets from the provider's key management service into the cluster, so that rotation, access control and audit happen in one place.
The interactive view below shows how these pieces connect in Baobab's clusters.
Notice that every CNCF project named in the diagram is Graduated. Gateway API is a Kubernetes API rather than a CNCF project, and the secrets integration depends on your cloud's key service. That is reassuring about the projects and says nothing about Baobab's ability to run all of them. As Part 2 argued, each one still needs a version, an upgrade owner and a support route.
What Baobab's incidents had in common
Baobab reviewed its last twelve months of platform incidents against these layers. Most fell into four groups:
- Untracked changes. Configuration applied by hand during incidents and never written back, so the next deployment reverted a fix. A delivery layer problem.
- Unsafe workloads. Containers with no resource limits starving their neighbours during the month-end promotion. A guardrail problem.
- Expired certificates. Two outages from manually managed certificates. A traffic layer problem.
- Slow diagnosis. Incidents that took hours to locate because logs, metrics and traces lived in three tools with no shared identifiers. A visibility problem.
None of these were Kubernetes failures. All of them were platform gaps.
Staged adoption for a 15-person team
Installing all five layers at once is the fastest way to own five things badly. Baobab gave each quarter one main focus, and did not move on until the new components had an owner, a runbook and a tested upgrade.
Quarter 1: managed cluster, GitOps and metrics. Move deployments to GitOps first, because every later layer is deployed through it. Add Prometheus-based metrics and basic alerting.
Quarter 2: Gateway API, cert-manager and secrets. Replace hand-managed ingress and certificates, and sync secrets from the cloud key service instead of storing them by hand in the cluster. This is also when Baobab planned its move off Ingress NGINX.
Quarter 3: policy in audit mode, and traces. Install the policy engine but only report violations, so teams can fix workloads before anything is blocked. Add OpenTelemetry tracing for the checkout path.
Quarter 4: enforce policy and build golden paths. Switch the agreed policies to enforcing, and publish templates that pass them by default, so the easy way and the safe way are the same.
The lower lane in that diagram matters most. A layer is not done when it is installed. It is done when someone other than the person who installed it can upgrade it. How to graduate an internal developer platform describes how to judge when a platform as a whole is ready to be trusted, and The case for platform engineering explains why the effort is worth it.
When not to use Kubernetes
Everything above assumes Kubernetes is the right engine. Often it is not.
If you run a handful of services, have no platform team and no need for multi-cloud portability, a managed container service or platform-as-a-service from your cloud provider will usually give you most of the benefit with a fraction of the operating burden. Containerisation for the South African developer: when Kubernetes is overkill covers that decision in detail.
Baobab's own test is three questions. Do we have enough services, teams or deployment frequency to justify a shared platform? Do we have at least two people per platform layer to run it? Do we need something Kubernetes gives us that a simpler managed service does not? If any answer is no, the simpler service wins, and the CNCF landscape becomes a reference rather than a shopping list.
Baobab answered yes to all three for its e-commerce and pricing workloads. For two small internal tools, it answered no and moved them to its provider's managed container service, which removed them from the cluster entirely.
Where to start
- Map your incidents to the five layers. The layer with the most incidents is usually your first priority, unless delivery is missing, in which case start there.
- Check for retired or archived components. If Ingress NGINX or an archived project is in your estate, give it a migration owner and a date.
- Pick one layer for this quarter, choose its component with a scorecard, and do not add the next layer until this one has a second operator.
Next: Part 6, Cloud native for AI workloads: what is ready and what to wait for. All parts are on the series page.
How CloudNala can help
CloudNala helps platform teams design and stage the layers around Kubernetes. We review your incidents and current components against the minimum set, identify retired or unsupported components, help you choose one tool per job, and plan a staged adoption your team can own. Where Kubernetes is the wrong engine, we will say so and help you move to something simpler.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Cloud Native Platform Review or write to us at consult@cloudnala.co.za