Skip to main content

Platform Engineering Foundations on Kubernetes

Learn to run Kubernetes for many teams: tenant namespaces, quotas, Kyverno guardrails, Crossplane self-service, and cluster upgrades done safely.

~3.5 hours
12 Topics
Hands-on Scenarios

What You'll Learn

Understanding the Platform Team's Job

acme-shop's product teams have grown from one to three, and all three now deploy to the same Kubernetes cluster.

Designing Multi-Tenancy with Namespaces

A tenant is a team that shares your cluster. Multi-tenancy means giving each tenant enough isolation that one team's mistake stays inside that team.

Preventing Noisy Neighbours with Quotas and LimitRanges

A noisy neighbour is a workload that uses so much of a shared resource that others suffer. Quotas and LimitRanges are your first defence.

Isolating Teams with RBAC and Network Policies

Quotas protect resources. RBAC and network policies protect access. Kubernetes Security teaches the mechanics; here you design them for tenants.

Understanding Admission Control

Admission control is the checkpoint every create or update request passes before it is saved. It is where your platform's rules live.

Writing Guardrails with Kyverno

Kyverno is a policy engine that runs as an admission webhook. Policies are Kubernetes YAML, so there is no new language to learn.

Skills You'll Master

PLATFORM-ENGINEERINGMULTI-TENANCYKYVERNOPOLICY-AS-CODEOPERATORS

Curriculum Index12 topics

Career Impact

Roles that use the skills in this module.

  • DevOps Engineer

  • Site Reliability Engineer

  • Platform Engineer

See how this is asked in interviews

Practice on the Coding Sheet

Not a software engineer sheet. Every problem comes from real DevOps, SRE, Platform and Cloud interviews, from your first script to a system you build yourself.

Open the Coding Sheet

Frequently Asked Questions

A DevOps engineer usually helps one product team ship and run its software. A platform engineer builds the shared paved road that many teams use, with safe defaults, guardrails, and self-service. The skills overlap, but the platform engineer treats other engineers as customers.

It is safe enough for teams inside one company when you add quotas, RBAC, network policies, and admission policies. It is not a hard security boundary for teams that do not trust each other. For that you need separate clusters or virtual clusters.

If your policies only target Kubernetes, Kyverno is easier because policies are written in YAML. Gatekeeper uses the Rego language, which pays off when you want one policy language across several systems. This module teaches Kyverno.

No. Most platform work uses operators other people wrote, such as cert-manager or CloudNativePG. You should understand the reconcile loop well enough to debug one, and know when building your own is justified.