Kubernetes New Contributor Workshop - KubeCon EU 2018 - Notes

Joining in the beginning was onboarding on a yacht Now is more onboarding a BIG cruise ship.

Will be a Hard schedule, and let’s hope we can achieve everything Sig-contributor-experience -> from Non-member contributors to Owner

SIG presentation

  • SIG-docs & SIG-contributor-experience: Docs and website contribution
  • SIG-testing: Testing contribution
  • SIG-* (depends on the area to contribute on): Code contribution

=> Find your first topics: bug, feature, learning, community development and documentation

Table exercise: Introduce yourself and give a tip on where you want to contribute in Kubernetes

Communication in the community

Kubernetes community is like a Capybara: community members are really cool with everyone and they are from a lot of different horizons.

  • Tech question on Slack and Stack Overflow, not on Github
  • A lot of discussion will be involve when GH issues and PR are opened. Don’t be frustrated
  • Stay patient because there is a lot of contribution

When in doubt, ask on Slack

Other communication channels:

on, there is the schedule for all the SIG/Working group meeting. If you want to join or create a meetup. Go to slack#sig-contribex

SIG - Special Interest Group

Semi-autonomous teams: - Own leaders & charteers - Code, Github repo, Slack, mailing, meeting responsibility


SIG List

  1. Features Area
    • sig-auth
    • sig-apps
    • sig-autoscaling
    • sig-big-data
    • sig-cli
    • sig-multicluster
    • sig-network
    • sig-node
    • sig-scalability
    • sig-scheduling
    • sig-service-catalog
    • sig-storage
    • sig-ui
  2. Plumbing
    • sig-cluster-lifecycle
    • sig-api-machinary
    • sig-instrumentation
  3. Cloud Providers (currently working on moving cloudprovider code out of Core)
    • sig-aws
    • sig-azure
    • sig-gcp
    • sig-ibmcloud
    • sig-openstack
  4. Meta
    • sig-architecture: For all general architectural decision
    • sig-contributor-experience: Helping contributor and community experience
    • sig-product-management: Long-term decision
    • sig-release
    • sig-testing: In charge of all the test for Kubernetes
  5. Docs
    • sig-docs: for documentation and website

Working groups and “Subproject”

From working group to “subproject”.

For specific: tools (ex. Helm), goals (ex. Resource Management) or areas (ex. Machine Learning).

Working groups change around more frequently than SIGs, and some might be temporary.

  • wg-app-def
  • wg-apply
  • wg-cloud-provider
  • wg-cluster-api
  • wg-container-identity

Picking the right SIG:

  1. Figure out which area you would like to contribute to
  2. Find out which SIG / WG / subproject covers that (tip: ask on #sig-contribex Slack channel)
  3. Join that SIG / WG / subproject (you should also join the main SIG when joining a WG / subproject)

Tour des repositories

Everything will be refactored (cleaning, move, merged,…)

Core repository



  • website
  • kubernetes-cn
  • kubernetes-ko

Developer Tools

  • sample-controller*
  • sample- apiserver*
  • code-generator*
  • kubernetes-template-project: For new github repo

Staging repositories

Mirror of core part for easy vendoring

SIG repositories

  • release
  • federation
  • autoscaler

Cloud Providers


Tools & Products

  • kubeadm
  • kubectl
  • kops
  • helm
  • charts
  • kompose
  • ingress-nginx
  • minikube
  • dashboard
  • heapster
  • kubernetes-anywhere
  • kube-openapi

2nd Namespace: Kubernetes-sigs

Too much places for Random/Incubation stuff. No working path for promotion/deprecation

In future: 1. start in Kubernetes-sigs 2. SIGs determine when and how the project will be promoted/deprecated

Those repositories can have their own rules: - Approval - Ownership - …


First Bug report

- Bug or Feature

- What happened

- How to reproduce

### Issues as specifications

Most of k8s change start with an issue:

  • Feature proposal
  • API changes proposal
  • Specification

From Issue to Code/Docs

  1. Start with an issue
  2. Apply all appropriate labels
  3. cc SIG leads and concerned devs
  4. Raise the issue at a SIG meeting or on mailing list
  5. If Lazy consensus, submit a PR

Required labels

On creation

  • sig/\*: the sig the issue belong too
  • kind/\*:
    • bug
    • feature
    • documentation
    • design
    • failing-test

For issue closed as port of triage

  • triage/duplicate
  • triage/needs-information
  • triage/support
  • triage/unreproduceable
  • triage/unresolved


  • priority/critical-urgent
  • priority/important-soon
  • priority/important-longtem
  • priority/backlog
  • priority/awaiting-evidence


Free for dedicated issue area

  • area/kubectl
  • area/api
  • area/dns
  • area/platform/gcp


Currently mostly complicated things



Making a contribution by Pull Request

We will go through the typical PR process on kubernetes repos.

We will play there: community/contributors/new-contributor-playground at master · kubernetes/community · GitHub

  1. When we contribute to any kubernetes repository, fork it

  2. Do your modification in your fork ``` $ git clone $GOPATH/src/ $ git remote add upstream $ git remote -v origin (fetch) origin (push) upstream (fetch) upstream (push) $ git checkout -b kubecon Switched to a new branch ‘kubecon’


$ git add contributors/new-contributor-playground/ $ git commit


Adding a new contributors file

We are currently experimenting PR process in the kubernetes repository.

$ git push -u origin kubecon ```

  1. Create a Pull request via Github
  2. If needed, sign the CLA to make valid your contribution
  3. Read the k8s-ci-robot message and /assign @reviewer recommended by the k8s-ci-robot
  4. wait for a LTGM label from one of the OWNER/reviewers
  5. wait for approval from one of OWNER/approvers
  6. k8s-ci-robot will automatically merge the PR

needs-ok-to-test is used for non-member contributor to validate the pull request

Test infrastructure

How bot toll you when you mess up

At the end of a PR there is a bunch of test. 2 types: - required: Always run and needed to pass to validate the PR (eg. end-to-end test) - not required: Needed in specific condition (eg. modifying on ly specific part of code)

If something failed, click on details and check the test failure logs to see what happened. There is junit-XX.log with the list of test executed and e2e-xxxxx folder with all the component logs. To check if the test failed because of your PR or another one, you can click on the TOP pull-request-xxx link and you will see the test-grid and check if your failing test is failing in other PR too.

If you want to retrigger the test manually, you can comment the PR with /retest and k8s-ci-robot will retrigger the tests.

SIG-Docs contribution

Anyone can contribute to docs.

Kubernetes docs

  • Websites URL
  • Github Repository
  • k8s slack: #sig-docs

Working with docs

Docs use k8s-ci-robot. Approval process is the same as for any k8s repo. In docs, master branch is the current version of the docs. So always branch from master. It’s continuous deployment For a specific release docs, branch from release-1.X.

Local build and Test

The code: [kubernetes/kubernetes] The process: [kubernetes/community]

Dev Env

You need: - Go - Docker

  • Lot of RAM and CPU and 10 GB of space
  • best to use Linux
  • place you k8s repo fork in:
    • $GOPATH/src/
  • cd $GOPATH/src/
  • build: ./build/ make
    • Build is incremental, keep running ./build/ make til it works
  • To build variant: make WHAT="kubectl"
  • Building kubectl on Mac for linux: KUBE_*_PLATFORM="linux/amd64" make WHAT "kubectl"

There is build documentation there:


There is test documentation there: