Gnu Group Learning AcademyGnu Group ↗
Platform Engineering Fundamentals · Module 06 of 12

Kubernetes, Helm and runtime abstractions

Use Kubernetes and packaging primitives behind stable workload contracts, while preventing platform abstractions from leaking every cluster implementation detail to application teams.

Learning objectives

By the end of this module, you should be able to:

  • Distinguish a platform workload contract from raw Kubernetes administration.
  • Explain where Helm values are useful and where they become an unstable API.
  • Validate resource, health and ownership defaults in a workload profile.

Kubernetes is a substrate, not automatically a platform

Kubernetes provides APIs for scheduling and operating workloads, but developers still need supported patterns for service exposure, configuration, resources, health, identity, policy and observability.

Helm packages implementation choices

Helm charts can template Kubernetes resources and expose values. A platform should keep the values surface deliberate; exposing every chart field merely transfers cluster complexity to consumers.

Define workload classes

A small set of supported workload profiles can encode resources, probes, security context, network exposure and operational defaults while retaining an escape path for special workloads.

Worked example

Workload profile

{"class":"web-service","cpu":"250m","memory":"256Mi","health":"http:/healthz","exposure":"internal"}
  • Developers choose intent-level properties.
  • The platform translates the profile into versioned Kubernetes/Helm implementation.
Core lab · account-free

Lab 06 — Validate a workload profile

Goal: Check that a platform workload profile contains safe operational defaults.

Before you start

  • No cloud account required.
  • Core lab uses bash/Python 3 and local files only.
STEP 1

Create profile

cat > /tmp/workload-profile.json <<'EOF'
{"class":"web-service","cpu_m":250,"memory_mi":256,"readiness":"/readyz","liveness":"/healthz","exposure":"internal","owner":"payments"}
EOF
STEP 2

Validate profile

python3 - <<'PY2'
import json
x=json.load(open('/tmp/workload-profile.json'))
assert x['class'] in {'web-service','worker'}
assert 100 <= x['cpu_m'] <= 2000
assert 128 <= x['memory_mi'] <= 4096
assert x['readiness'].startswith('/') and x['liveness'].startswith('/')
assert x['exposure'] in {'internal','public'}
assert x['owner']
print('workload profile valid')
PY2
STEP 3

Identify implementation boundary

List which Kubernetes fields the platform should own versus which application-specific values the developer must supply.

Verify

  • Resource bounds, probes, exposure and ownership are explicit.
  • The platform/application responsibility boundary is documented.

Expected outcome

  • A workload contract that can be translated to Kubernetes/Helm safely.

Diagnose / troubleshoot

  • If developers need to edit generated YAML after every scaffold, the abstraction is leaking.
  • If probes are generic guesses, require application-specific endpoints and validate them in deployment.
Real-world connection

Runtime abstractions should give teams safe defaults while preserving enough visibility to troubleshoot Kubernetes behavior.

Real-tool practicum · optional but recommended

Real-tool practicum — kind + Helm workload contract

Create the disposable local Kubernetes substrate with the supplied one-command kind setup, then render and inspect a small Helm workload contract before anything is applied.

Prerequisites

  • Docker or another kind-supported container provider, kind and kubectl installed locally.
  • Run ./ops/setup-platform-kind-lab.sh once to create/reuse the disposable gnu-platform-lab cluster.
  • Helm 3 for the rendering step. No cloud account is required.

Cost / risk

  • Core learning is account-free. Optional external/sandbox tools may consume local CPU/RAM; do not use production credentials or billable cloud resources.

Warnings

  • Do not point training automation at production clusters, repositories or cloud accounts.
  • A successful command is not proof of a good platform interface; validate the developer outcome and guardrails.
TOOL 1
./ops/setup-platform-kind-lab.sh
TOOL 2
kubectl --context kind-gnu-platform-lab get nodes -o wide
TOOL 3
helm version --short
TOOL 4
helm template demo ./chart -f values.yaml | head -80
Avoid these traps

Common mistakes

  • Calling Kubernetes itself an internal developer platform.
  • Exposing hundreds of chart values as the platform API.
  • Hiding resource/probe failures so thoroughly that teams cannot debug workloads.
Knowledge check

Can you connect the developer need to a platform contract?

Three concept checks plus one scenario check.

1Why is Kubernetes not automatically a developer platform?

It provides infrastructure APIs but not the full supported developer experience, contracts, golden paths and lifecycle needed for self-service.

2What should a platform do with Helm values?

Expose a small deliberate contract and keep implementation-only values private/versioned.

3Why define workload classes?

They package safe, repeatable operational defaults for common workload shapes.

4Scenario: every team forks the Helm chart to change one setting. What does this signal?

The platform contract or extension model is inadequate; a supported input/escape hatch should replace unmanaged forks.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Attempt the core lab and knowledge checks before marking the module complete.