Kubernetes Orientation Map
A four-week reading and observation plan, ending the week the v1.38 shadow application window is likely to open. The deliverable is a map, not mastery.
A four-week reading and observation plan, ending the week the v1.38 shadow application window is likely to open.
Goal: not mastery. A map. By the end you should be able to answer, for any change you might want to make: which SIG owns this, which repo does it live in, who reviews it, what the bot will do to it, and where the conversation happens.
Fixed dates you are working against:
| Date | Event |
|---|---|
| 22 July 2026 | v1.37 Code Freeze (passed) |
| 28 July 2026 | KubeCon Japan co-located events, Yokohama |
| 29–30 July 2026 | KubeCon + CloudNativeCon Japan main conference |
| 5 August 2026 | v1.37 Docs Freeze |
| 26 August 2026 | v1.37.0 released |
| ~late August 2026 | v1.38 shadow application window likely opens |
On video: watch meetings, not tutorials
There is a lot of “how to contribute to Kubernetes” video on YouTube. Most of it is not worth your four weeks. It goes stale fast — the CLA tooling, the bot behaviour and the label set have all changed in the last two years — and at best it tells you what the docs already tell you, more slowly and without links you can copy.
What is worth watching is the project’s own recordings, which are not tutorials at all. They are primary source material. Every SIG meeting is recorded and published, so you can watch maintainers disagree, defer decisions, and admit they are stuck. None of that is in any document, and it is the single fastest way to work out which SIG you would actually want to spend time in.
Canonical video sources
| Source | What it is | Use it for |
|---|---|---|
| Channel playlists tab | Separate playlist per SIG and WG, plus release and community meetings | Browsing when the docs don’t link what you want |
| NCO playlist — linked from kubernetes.dev/docs/orientation | SIG ContribEx mentoring session, third Tuesday of the month, in two slots — one EMEA/APAC-friendly, one AMER-friendly. ~40 min talk + ~20 min Q&A | Week 1 background. Note: explicitly no hands-on content |
| New Contributor Series | Getting-started videos; cross-check against the workshop outline linked from the playground README | The hands-on one, if you want a walkthrough |
| SIG ContribEx meetings | The SIG that owns contributor experience | Seeing how a SIG meeting actually runs |
| New Contributor Course | Ten units of slides, not video — testing, code review, docs, architecture | Structured study if slides suit you better than talking heads |
| k8s.dev/calendar | Invites to every SIG meeting, with APAC-friendly variants | Attending live rather than watching later |
Finding links the docs don’t give you. Two techniques. For files in a repo,
open the repo on GitHub and press t to fuzzy-find by filename — Kubernetes
repos disagree about main versus master, so guessing paths wastes time.
For everything else, find the hub page that references it rather than the thing
itself: the contributor cheatsheet,
Getting Started, and
community/communication
between them link most of what exists. git.k8s.io/X redirects to
github.com/kubernetes/X.
Keep a list of every link you had to hunt for. That list is a strong first PR to kubernetes/website or kubernetes/community, and the friction you felt finding it is the evidence that justifies the change.
How to watch, so it isn’t passive: pick one SIG, watch its two most recent meetings back to back, and write down every acronym, tool and person’s name you did not recognise. That list is your reading queue for the week, and it is a better filter than any curated syllabus, because it is generated by what the project is actually working on right now.
Week 1 — Shape and governance
The question this week answers: who decides things, and how is the project cut up?
- Read
kubernetes/communitytop-level README andgovernance.md - Read
sig-list.mdproperly — not skimmed. Note which SIGs you had never heard of. - Understand the difference between a SIG, a Working Group, a User Group and a Committee. (Committees handle things SIGs cannot: Code of Conduct, Security Response.)
- Read
community-membership.md— the full contributor ladder: contributor → member → reviewer → approver → subproject owner - Read the OWNERS files guide. This is the mechanism the entire review process rests on.
- Set up the boring prerequisites now so they are not blockers later:
2FA on GitHub, affiliation recorded in CNCF gitdm and openprofile.dev,
subscribe to
kubernetes-dev@kubernetes.io - Join slack.k8s.io. Lurk in
#sig-release,#kubernetes-new-contributors,#sig-contribex - Watch one recent New Contributor Orientation recording. One is enough — they cover the same ground each month, and you will attend a live one in week 4 for the Q&A.
- Subscribe to the community calendar at k8s.dev/calendar and put two SIG meetings in your diary now, before you have decided which SIG you like. There are APAC-friendly sessions, so IST is well served.
- Sign the CNCF CLA and open the contributor-playground PR. It is forty minutes, it is the only irreversible step in this plan, and everything else is reading — which always expands to fill the time available.
Shortlist of SIGs worth a closer look, given an SRE background:
| SIG | Why it fits |
|---|---|
| sig-release | Release engineering, CI signal, branch management |
| sig-instrumentation | Metrics, logging, tracing — your daily vocabulary |
| sig-cluster-lifecycle | kubeadm, Cluster API, kOps |
| sig-testing | test-infra, TestGrid, flake hunting |
| sig-etcd | Storage layer, operational correctness |
| sig-scalability | Load testing at absurd sizes |
Post idea: a plain map of how Kubernetes is governed, written for someone who has only ever used it. Genuinely scarce.
Week 2 — The machinery
The question this week answers: what actually happens to a pull request?
- Read about Prow. It is Kubernetes’ own CI and chat-ops system, not GitHub Actions.
- Read the Prow command reference at prow.k8s.io/command-help — the full
list of
/commands - Understand Tide: why PRs merge in batches rather than on a button press
- Learn the label taxonomy:
lgtm,approved,needs-rebase,do-not-merge/hold,size/*,kind/*,priority/*,sig/*,triage/needs-information,lifecycle/stale - Browse testgrid.k8s.io and find a currently failing job. Work out what is broken. Do not fix it — just read it.
- Read the issue triage guide
- Watch the v1.37 release burndown meetings for this week (recorded on the Kubernetes YouTube channel). This is a freeze period, so you will see exception requests and cherry-picks in real time.
Post idea: what the k8s-ci-robot is doing to your PR, and why Kubernetes built its own CI system. Strong SRE angle.
Week 3 — How change happens
The question this week answers: how does an idea become code in a release?
- Read the KEP template and process in
kubernetes/enhancements - Read one KEP end to end, ideally one that shipped recently, and follow it to the PRs that implemented it
- Understand Production Readiness Review and why it exists — this is the part of the project that most closely resembles your job
- Read the v1.37 release page on kubernetes.dev/resources/release and map each freeze to what it prevents
- Read the Release Team role handbooks and shadows.md. Decide which two roles you would apply for.
- Start reading lwkd.info weekly and do not stop. It is the closest thing to a newspaper this project has.
Post idea: how a feature gets into Kubernetes — traced through one real KEP, from proposal to the release notes.
Week 4 — Stop reading
- Attend at least two SIG meetings live. Cameras off, introduce yourself if invited to, say nothing else. Note how differently they run.
- Attend a New Contributor Orientation session live, for the Q&A rather than the talk
- Watch v1.37.0 ship on 26 August
- Submit the v1.38 shadow application when the window opens — watch
#sig-releaseand thekubernetes-devlist for the announcement - As a backup with no application window at all: ask in
#sig-docsabout shadowing a PR Wrangler. A docs approver takes the role for a week, triaging incoming PRs to kubernetes/website, and shadowing is arranged by asking that week’s wrangler directly. Signing up on the wiki needs org membership; asking in Slack does not. Far lower barrier than the release team, and it teaches you review rather than authoring. - Pick one SIG and commit to it for six months
Post idea: what four weeks of reading did and did not prepare you for. Write this one immediately after your first SIG meeting, while the disorientation is still fresh.
Guardrails
Do not extend this past four weeks. The map is the deliverable, not completeness. If week 5 arrives and you have not opened the playground PR, the reading has become avoidance and the blog has no subject.
Publish weekly regardless. A post that says “I read the governance docs and three things still make no sense” is a better post than a polished summary, and it is the one that gets answered in Slack.
Write down what confused you before you understand it. That window closes permanently and it is the only thing you have that experienced contributors do not.