We Teach Kubernetes

A Kubernetes roadmap organised by problem rather than by exam syllabus. Click any checkpoint to see what is inside it.

—contributors
—resources
—checkpoints
—hours of path
Taught by real people

Everyone whose name is on this roadmap

Each card is one object in data/contributors.json. The portrait is generated from the handle, so nobody has to upload a photo to take part — and the LinkedIn link is optional.

How the content gets here

Read freely. Sign in only to write.

Every node, every tutorial and every contributor page is public, indexable and linkable with no account — a recruiter or a reviewer following a link sees all of it. An account is needed only for the handful of things that write something down.

No account The roadmap and all node content · community tutorials and their authors · contributor profiles · search, filters and deep links · progress kept on this device
Sign in with GitHub Submitting a tutorial · reporting a dead link · flagging something outdated · progress that follows you between devices · joining a peer cohort
  1. Sign in with GitHub. The authorize screen asks for nothing — the scope is empty, which grants public profile data and no repository access whatsoever.
  2. Fill in the form on any checkpoint: kind, title, link, minutes. Your handle is not a field, because it comes from the session rather than from anything you can type.
  3. The Worker validates and commits — appends one object to data/roadmap.json on a new branch, with a Co-authored-by trailer using your GitHub noreply address.
  4. A maintainer merges. The site rebuilds, your name appears on the checkpoint and in the contributors wall, and the commit counts on your profile.
One rule that gets a PR closed: no exam content. Teach the subject, never the questions.

Prefer Git? Nothing stops you. The form is a convenience on top of two plain JSON files — a hand-written PR against them is reviewed exactly the same way.

// 1. the sign-in redirect — note the empty scope
GET github.com/login/oauth/authorize
  ?client_id=$GITHUB_CLIENT_ID
  &redirect_uri=https://…/api/auth/callback
  &scope=                // nothing at all
  &state=$RANDOM         // CSRF, checked on return

// 2. the callback, server side only
POST github.com/login/oauth/access_token
  { client_id, client_secret, code, state }
   // client_secret is a Worker secret and never
   // reaches a browser. Read login + id, discard the
   // token, set an httpOnly SameSite=Lax cookie.

// 3. progress, the one write most people want
PUT /api/progress      // signed in
Cookie: wtk_session=…
{ "done": ["object-model", "network-policy"] }
// anonymous? it stays in localStorage, and on first
// sign-in the site offers to merge rather than
// silently overwrite either side.

// 4. the submission — no handle in the body
POST /api/contribute
Cookie: wtk_session=…
{ "checkpoint": "network-policy",
  "resource": { type, title, url, minutes } }

// 5. what the Worker does, in order
1. session  verify cookie, resolve handle + id
2. validate https URL, HEAD 200, checkpoint exists,
            lengths capped, no HTML
3. limit    max 5 open PRs per handle
4. read     data/roadmap.json + its blob sha
5. append   one resource, by = session handle
6. commit   GitHub App installation token, trailer
            Co-authored-by: Name <[email protected]>
7. pull     open the PR  // never auto-merge
Why the site still opens the PR, rather than you: having the PR authored by your own account would need write scope on your repositories, and most people are right to decline that for a one-paragraph contribution. The co-author trailer gets the profile credit without the site ever being able to touch your account.