Saltar a contenido

Appendix C-Contributing to Kubernetes

Kubernetes is the largest open-source project in the world by contributor count. The flip side: the bureaucracy is real. This appendix is the on-ramp.

C.1 Mental Model

The Kubernetes project is governed by SIGs (Special Interest Groups)-domain-scoped groups (sig-node, sig-network, sig-storage, sig-api-machinery, sig-scheduling, sig-cli, sig-auth, etc.). Each SIG has chairs, technical leads, regular meetings, and a Slack channel. Almost every PR maps to a SIG.

Major changes go through KEPs (Kubernetes Enhancement Proposals)-design docs in the kubernetes/enhancements repo. KEPs progress through provisional → implementable → implemented → deprecated over multiple releases.

Implications for newcomers: 1. Find the right SIG before opening a PR. 2. For non-trivial changes, write or piggyback on a KEP first. 3. The cycle time is slow. Two-week review is normal; six-week is common.

C.2 Setting Up

git clone https://github.com/kubernetes/kubernetes
cd kubernetes
make all -j$(nproc)

The build is heavy (it's all of Kubernetes); plan for ~10 minutes the first time.

For tests: 

make test                       # unit
make test-integration KUBE_TEST_ARGS="-run <name>"
make test-e2e KUBE_TEST_ARGS=...

For local dev cluster: kind (uses your local Docker / containerd, spins up a multi-node cluster in containers in seconds).

C.3 Where the Easy Wins Are

C.3.1 Documentation

  • kubernetes/website (the website repo). Docs improvements are welcome and reviewed quickly.

C.3.2 e2e flakes

  • The flakey label on kubernetes/kubernetes issues. Fixing flakes is unglamorous but high-impact.

C.3.3 kubectl

  • `staging/src/k8s.io/kubectl - small, contained. Bug fixes and small features are tractable.

C.3.4 client-go improvements

  • `staging/src/k8s.io/client-go - used by every controller in the world. Improvements compound.

C.3.5 SIG-specific work

  • Pick a SIG matching your interest. Their backlogs have good first issue labels.

C.3.6 Don't start here (yet)

  • Scheduler core (high stakes; small SIG; deep changes need KEPs).
  • API machinery (apiserver internals, conversion, validation).
  • kubelet (touches every node; PR latency is high for safety).
  • Anything touching scaling / performance critical paths.

C.4 The First-PR Workflow

  1. Find an issue. Read CONTRIBUTING.md and SIG-specific contribution guides. Comment /assign to claim.
  2. Branch from master.
  3. Implement. Run make verify, make test, the relevant make test-integration subset.
  4. Commit with Signed-off-by (DCO).
  5. Open the PR. SIG bots will auto-assign reviewers. Use the PR template; fill in every field.
  6. CI cycle. Tests run on Prow. Re-run with /test all. Address comments.
  7. Approval flow: a reviewer adds /lgtm; an approver adds /approve. Both required. The bot then merges.
  8. Backport (if applicable): for bugfixes, the PR may need cherry-picks to release branches. Use the cherry-pick robot or do manually.

C.5 The KEP Process

For changes that: - Add or modify the API. - Have user-visible behavior changes. - Affect multiple SIGs.

Process: 1. Open an issue in the relevant SIG. 2. Get at least informal agreement that the problem is real. 3. Write a KEP using the template in kubernetes/enhancements/keps/NNNN-template/. 4. Submit as a PR. The KEP itself goes through review. 5. Once implementable, you can submit code PRs referencing the KEP number. 6. KEPs target a Kubernetes release (alpha → beta → GA over multiple releases).

Time scale: months to a year for a substantial KEP.

C.6 Adjacent Targets if k/k Is Too Heavy

The CNCF ecosystem has many high-impact projects with smaller surface area:

Project Bar
kubectl plugins (krew) Low. Author your own; submit to krew index.
kind Low–Medium. Friendly maintainers.
kustomize Medium.
Helm Medium. Larger team.
ArgoCD / Flux Medium. Active.
Cilium Medium–High.
Crossplane Medium. Welcoming to providers.
Operator SDK / Kubebuilder Medium.
OpenTelemetry (collector + Operator) Medium.

A merged contribution to any of these is a credible Kubernetes-ecosystem signal in interviews.

C.7 Calibration

A reasonable goal for a curriculum graduate:

  • By end of week 23: a PR open against kubernetes/website, a kubectl plugin, or a small fix to an ecosystem project.
  • By end of capstone: that PR merged.
  • 6 months post-curriculum: a substantive contribution-a kubectl feature, a new operator, a Cilium policy plugin.

Patient contributors become trusted contributors. Trusted contributors become reviewers. Reviewers become approvers. Approvers become SIG chairs. The path exists; it just takes time.

Comments