New Contributor Workshop

Welcome on board!

Imange from: The Illustrated Children’s Guide To Kubernetes, by Matt Butcher, Bailey Beougher, and Karen Chu.

Workshop Facilitators

101 Beginner Content

Marky Jackson, SIG ContribEx

Bob Killen, SIG ContribEx

Chris Short, SIG ContribEx

201 Intermediate Content

Guinevere Saenger, SIG Release
Alison Dowdney, SIG ContribEx

Tutors

Arnaud Meukam
Jeremy Rickard
Eduar Tua


Order of operations - Combined session

  • Welcome and PR Demo
  • Contributing: Who/Where/How
  • How We Communicate
  • Repo and SIG Tour

Credit Ashley McNamara and github.com/ashleymcnamara/gophers for Kubernetes Gophers image.

Credit Renee French for the original gopher concept and design.

Demo

Who can contribute to Kubernetes?

Credit Ashley McNamara and github.com/ashleymcnamara/gophers for Kubernetes Gophers image.

Credit Renee French for the original gopher concept and design.

Why contribute to Kubernetes?

Fitting Contributions Into Your Job

Choose Your Own Adventure

Figuring out where

to contribute

Find Your Topic Exercise

As a group…

  • Explain your background, job, interests, or what motivates you.
  • Use your group to help figure out what you think you want to do in the Kubernetes community

Let’s Talk

Communication

in the
Kubernetes
Community

DEF

Standards of Communication

aka: Why is everyone so nice?

We believe that mutual respect is a prerequisite for healthy collaboration.

git.k8s.io/community/code-of-conduct.md

The Kubernetes Community Code of Conduct is a vital component in how we communicate

Mutual Respect

I’m going

Where to ask

Technical Questions

Slack

Register here: slack.k8s.io

Contributor Focused

User Focused

Discuss

Want more long-form discussions?

Head over to:

discuss.kubernetes.io

TODO: create topic for new contribs to say hi

Planning and Discussion

Mailing lists

  • One per SIG/WG
    • Some have more for large subprojects.

  • Run on Google Groups

  • You need to join:
    • kubernetes-dev
    • Required for Org Membership!

GitHub

Issues

Features

Pull requests

Decisions are made openly in public, with input requested and waited for

Zoom Meetings

Zoom Meetings

Schedule is on the community calendar

  • SIG Meetings
  • Kubernetes Weekly Community Meeting
    • Overview of community activities, release info, and governance updates.
  • Special meetings
  • Code of Conduct always applies

May not have quorum for decision making

Other Communications

  • kubernetes.io/community
    • Links to everything community related can be found here
  • Meet Our Contributors
    • Monthly live video discussion with contributors
  • Office Hours
    • Monthly live video panel to ask technical questions
  • KubeCon + CloudNativeCon
  • Face-to-Face SIG meetings
  • Meetups

Attend a Meetup

Collected links

Community Values

Community Values

Distribution is better than centralization

Community over product or company

Evolution is better than stagnation

Automation over process

Inclusive is better than exclusive

"Culture eats strategy for breakfast."

-- Peter Drucker

Distribution is better than centralization

The scale of the Kubernetes project is only viable through high-trust and high-visibility distribution of work, which includes delegation of authority, decision making, technical design, code ownership, and documentation. Distributed asynchronous ownership, collaboration, communication and decision making are the cornerstone of our world-wide community.

Community over product or company

We are here as a community first, our allegiance is to the intentional stewardship of the Kubernetes project for the benefit of all its members and users everywhere. We support working together publicly for the common goal of a vibrant interoperable ecosystem providing an excellent experience for our users. Individuals gain status through work, companies gain status through their commitments to support this community and fund the resources necessary for the project to operate.

Automation over process

Large projects have a lot of less exciting, yet, hard work. We value time spent automating repetitive work more highly than toil. Where that work cannot be automated, it is our culture to recognize and reward all types of contributions. However, heroism is not sustainable.

Inclusive is better than exclusive

Broadly successful and useful technology requires different perspectives and skill sets which can only be heard in a welcoming and respectful environment. Community membership is a privilege, not a right. Community Leadership is earned through effort, scope, quality, quantity, and duration of contributions. Our community shows respect for the time and effort put into a discussion regardless of where a contributor is on their growth path.

Evolution is better than stagnation

Openness to new ideas and studied technological evolution make Kubernetes a stronger project. Continual improvement, servant leadership, mentorship and respect are the foundations of the Kubernetes project culture. It is the duty for leaders in the Kubernetes community to find, sponsor, and promote new community members. Leaders should expect to step aside. Community members should expect to step up.

"Culture eats strategy for breakfast." --Peter Drucker

Community Groups

Community Group Types

Special Interest Groups (SIGs)

Persistent open groups that focus on a part of the project.

User Groups (UGs)

Groups for facilitating communication and discovery of information

Working Groups (WGs)

Temporary groups that are formed to address issues that cross SIG boundaries.

Committees

Sets of people that are chartered to take on sensitive topics.

Community Governance

  • Special Interest Groups (SIGs)
    • Primary organizational unit
    • Topic specific (Networking, Doc, etc.)
  • Subprojects
    • Work in SIGs divided into one or more subprojects
    • Every part of Kubernetes must be owned by subproject
  • Working Groups (WGs)
    • Short-lived rallying point
    • Work spanning multiple SIGs

Community Governance

  • User Groups
    • Facilitate communication between users and contributors
    • Topics include usage of, extension of, and integration with Kubernetes and Kubernetes subprojects
    • Examples:
      • Big Data
      • Cloud Providers
      • Machine Learning

Community Governance

  • Committees
    • Don't have open membership
    • Don't always operate in the open (Security or Code of Conduct)
    • Formed by Steering Committee
    • Committees:
        • Steering
        • Product Security
        • Code of Conduct

Special Interest Group

Kubernetes is a big project

2000 contributors in one pool would be too noisy

A SIG is a sub-community; these are you K8s people

Special Interest Group

Charter:

  • Code ownership
    • Scope/area
    • Binaries
  • Governing processes
  • Subprojects
  • Working Groups

Mailing List:

  • Communications with SIG members

Types of SIGs

  • Project
  • Horizontal
  • Vertical
    • Applications
    • Resource Management
    • Infrastructure

Community Groups Overview

Release

Contributor Experience

PM

Docs

Testing

API Machinery

CLI

UI

Multicluster

Windows

Auth

Apps

Autoscaling

Cluster Lifecycle

Instrumentation

Network

Node

Scalability

Scheduling

Service Catalog

Storage

Resource Management

Steering

Project

Horizontal

Vertical

Architecture

Code of Conduct

Product Security

Big Data

Cloud Provider

Component Standard

IoT Edge

K8s infra

Machine Learning

Multitenancy

Policy

Security Audit

LTS

Apply

Usability

Applications

Resource Management

Infrastructure

Work group

SIG

Committee

User group

Project SIGs

sig-architecture

sig-contribex

sig-docs

sig-pm

sig-release

sig-testing

sig-usability

Horizontal SIGs

sig-api-machinery

sig-auth

sig-cli

sig-instrumentation

sig-multicluster

sig-scalability

sig-ui

sig-windows

Vertical SIGs: Applications

sig-apps

sig-service-catalog

Vertical SIGs: Resource Management

sig-autoscaling

sig-network

sig-node

sig-scheduling

sig-storage

Vertical SIGs: Infrastructure

sig-cloud-provider

sig-cluster-lifecycle

  • Focus areas for SIGS

  • Own Code, Issues

Subprojects

Focus areas for SIGS

Working Groups

Working Groups: Inter-SIG efforts

For specific:

  • Goals (ex. Code Cleanup)
  • Areas (ex. multi tenancy)


cf: https://github.com/kubernetes/community/blob/master/README.md#governance

Project Working Groups

wg-security-audit

wg-k8s-infra

wg-LTS

Horizontal Working Groups

wg-apply

wg-component-standard

wg-multitenancy

wg-policy

Applications

wg-machine-learning

wg-io-edge

Resource Management

wg-resource-management

Vertical Working Groups

Picking the right community group

Find a specific project/area to work on

Picking the right community group

Find out which SIG (or working group) owns your topic

    • Look on the SIG list to find SIG info and charters
    • Ask on #sig-contribex
    • Attend the SIG Meet-and-Greet later today
    • Go to the SIG intros at this conference

How Do I Join A Community Group?

  • Join the specific mailing list.
    (This is open to anyone.)
  • That’s it! You’ve joined!
    You will get a calendar invite to the meeting.

Quick reference

Tour of
Repositories

Core Repository

Most SIGs are stakeholders in the monolith.

Areas of SIG ownership can be found in https://git.k8s.io/community/sigs.yaml

My repository, my rules

Repos can have different:

  • Ownership
  • Approval workflows
  • Merge workflows
  • Release cycles

https://github.com/kubernetes/

Talk about all the pinned repos

However, most are pretty similar.

Ready to jump right in?

Reference links, again

Use this for the time that the wall is coming down

Beginner Session

Split session

Morning

  • Kubernetes Quick Overview
  • Basic Repo/Code Tour
  • Dev Env: Pre-Requisites
  • SIGs, Labels, Issues: Overview
  • Open Source Interactions
  • PRs and Bots
  • Playground Exercise
  • Dev Env: Status Check

Afternoon

  • Dev Env: Final Check
  • Build System(s)
  • Make Targets
  • Build kubectl
  • Testing
  • SIGs, Areas, Issues: Engaging
  • Help Wanted: First PR Ideas

NCW 101 Agenda

Kubernetes Architecture Overview

👨‍🎤

👩‍🎤

🤖

📑

Kubernetes

Object

Definitions

kubectl

curl

client libraries

ui

Kubernetes Control

Plane

Kubernetes Nodes

Kubernetes API

Kubernetes API

Before we start let’s just minimally talk about the architectural internals of a Kubernetes cluster

img src: https://kubernetes.io/docs/concepts/architecture/cloud-controller/

Kubernetes Primitives

Client

60

Kubernetes Control Plane

API Server

Kubernetes node

user

etcd

etcd

Controller Manager

Scheduler

kube-proxy

Kubelet

etcd

Persistent data

iptables

Container Runtime

kube-proxy

Kubelet

iptables

Container Runtime

Kubernetes node

Before we start let’s just minimally talk about the architectural internals of a Kubernetes cluster

img src: https://kubernetes.io/docs/concepts/architecture/cloud-controller/

Basic Repo/Code Tour

  • Lots of RAM/Disk/CPU
  • Linux, Mac, Windows basic dev tools
  • Docker (for Mac/Win dedicate 6GB RAM)
  • Golang 1.13 latest and $GOPATH set
  • GitHub:
    • Account and SSH key configured
    • Fork github.com/kubernetes/kubernetes

Dev Environment: Pre-Requisites

Lots:

May be simplest to start your work in a Linux in a VM with eg: 10GB RAM, 80GB Disk, 4 Cores

If using Docker for Mac (or Windows), dedicate the Docker system multiple CPU cores and 6GB RAM


https://github.com/kubernetes/community/blob/master/contributors/devel/development.md

  • mkdir -p $GOPATH/src/k8s.io/ && cd $GOPATH/src/k8s.io/
  • git clone git@github.com:$YOUR_USER/kubernetes.git && cd kubernetes
  • git remote add upstream https://github.com/kubernetes/kubernetes.git
  • git fetch upstream
  • git checkout v1.16.3 or git checkout upstream/release-1.16

Dev Environment: Initialization

We’re using a local Harbor instance to serve up the majority of the container images you’ll need for this:

docker pull kubecon.goharbor.io/contribsummit/debian-base-amd64:0.4.1

docker pull kubecon.goharbor.io/contribsummit/debian-hyperkube-base-amd64:0.12.1

docker pull kubecon.goharbor.io/contribsummit/debian-iptables-amd64:v11.0.2

docker pull kubecon.goharbor.io/contribsummit/kindest/node:v1.16.3

docker pull kubecon.goharbor.io/contribsummit/kube-cross:v1.12.5-1

docker pull kubecon.goharbor.io/contribsummit/etcd:latest

docker pull kubecon.goharbor.io/contribsummit/alpine/socat:latest

Dev Environment: Container Images

NOTE: this is non-standard and is set up just for this workshop so that we don’t each download multiple gigabytes from the internet. We set this up so we can download from a server in the room with us.

SIGs, Labels, Issues: Overview

How to talk to the Kubernetes

community and automation

On average 2000 open issues in k/k

SIG labels narrow this, eg:

Initially it will feel like a normal GitHub workflow

Most labels are commonly named and colored across the Kubernetes org on GitHub

Many labels have mouse-hover help text

DEF

Gathering all the labels can feel like trying to catch all of the Pokemon.

Required Labels for Issues

On creation:

sig/
kind/

Label

sig/auth

sig/testing

sig/api-machinery

sig/node

Bot command

/sig auth

/sig testing

/sig api-machinery

/sig node

The SIG Label

Adding a label

kind/bug

kind/feature

kind/documentation

kind/design

The Kind Label

kind/failing-test

kind/flake

kind/cleanup

Example bot command: /kind feature

Defines what type of issue it is. Helpful in triage.

priority/critical-urgent

priority/important-soon

priority/important-longterm

priority/backlog

priority/awaiting-evidence

Example bot command: /priority critical-urgent

The Priority Label

Your SIG will set these.

area/kubectl

area/api

area/dns

area/platform/gce

The Area Label

Often, the area label is the name of a SIG subproject.

Area is a nice to have

triage/duplicate

triage/needs-information

triage/support

triage/unreproduceable

triage/unresolved

The Triage Label

These are for the maintainers to manage issues filed by users.

Open Source Interactions

me

implementation

centralized

implicit

assumptions

All of these labels are about improving visibility and discoverability, reducing collaboration friction between humans.

Humans on a VERY large team. Most of us don’t have much experience working on a VERY large team. It takes some changes in mindset.

Photo by John Schnobrich on Unsplash

Open Source Interactions

we

collaboration

decentralized

explicit

shared theories

me

implementation

centralized

implicit

assumptions

We before Me

Open Source Interactions

functionality

code

A simple individual contributor may focus on a limited deliverable

Open Source Interactions

docs

tests

integrations

releases

security

functionality

code

But open source communities expect more

Open Source Interactions

functionality

code

docs

tests

integrations

releases

security

HUMAN / SOCIAL:

Photo by You X Ventures on Unsplash

Paying attention to this bigger picture (and collaborating with others on it) makes you a better engineer.

Open Source Interactions

Be good people!

Mutual respect is a prerequisite for healthy collaboration.

git.k8s.io/community/code-of-conduct.md

Reminder: Human and social means we must act with mutual respect.

Open Source Interactions

Goal: Get a change into project

Photo by Alexander Muzenhardt on Unsplash

Open Source Interactions

Goal: Get a change into project

Path:

  • Visibility, transparency, proactive communication
  • Code, plus documentation, plus test cases
  • Presence in meetings, Slack, mailing list
  • Reviewable code

Open Source Interactions

Reviewable code:

  • demonstrates sound IDEA...through words
  • demonstrates reasonably architected solution...through words
  • polished implementation

As a contributor, consider what the reviewer needs, eg:

http://sage.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/

A reviewer/approver must defend the commons, will demand quality ideas/architecture/implementation.

Do your homework, prepare a reasoned argument, add test/docs coverage, show test results, proof goodness/safeness/correctness.

Open Source Interactions

Reviewable code:

  • demonstrates sound IDEA...through words
  • demonstrates reasonably architected solution...through words
  • polished implementation

Make the reviewer’s job easy:

  • commit subject line summarizes
  • commit body details what & why

Do your homework, prepare a reasoned argument, add test/docs coverage, show test results, proof goodness/safeness/correctness.

Record that in your commit messages.

Chris Beam’s Rules:

Open Source Interactions

Timing:

  • expect things you CARE about to take time
  • quality vs. speed
  • decentralized consensus forming
  • conversations wrap the globe
  • is it code freeze right now or merge time?

Open source is fast in aggregate, but:

  • idea → months → alpha → 1+ release → beta → 1+ release → stable
  • ...9-24 months

Enhancement ideas are formalized into...

Kubernetes Enhancement Proposal (KEP) documents are implemented in code iteratively through...

Alpha/Beta/Stable promotion

Note: this is not saying to get started you must dedicate years to doing trivial bug fixes and docs. It’s saying expect complex ideas to take persistent and ongoing advocacy to reach a quality end state across diverse stakeholders...SOFTWARE ENGINEERING.

Open Source Interactions

That was all pretty abstract...what about specifics?

PRs and Bots: GitHub PR Flow

PR == Pull Request

PRs and Bots: Kubernetes PR Flow

  • You submit Pull Request (PR)
  • You add labels & notes
  • Bots validate and comment on the PR

release-note cncf-cla: no needs-ok-to-test needs-kind needs-sig

  • You add more labels & notes & resolve review comments
  • SIGs & OWNERS review and /approve → approved
  • Other contributors /lgtm → lgtm
  • Tests pass
  • Tide merges the PR

https://prow.k8s.io/command-help

Read what the bot tells you on GitHub

First things it tells you about are:

PR’s merge AUTOMATICALLY when they achieve merge criteria. The bot will tell you what is between you and that continually.

Command

/assign @username

/retest
/close
/cc @username

Result

Assigns a Reviewer

Reruns failed tests
Closes PR
Tags a user

PRs and Bots: Useful Commands

A lot of the common GitHub features, like closing a pull request, are disabled in favor of bot commands.

PRs and Bots: Reviewers/Approvers

Finding reviewers and approvers: The bot searches for people and suggests them

PRs and Bots: Reviewers/Approvers

  • Attach /sig label
  • Contact the SIG
    • attend SIG meeting
    • ask Slack
    • send email to list
  • Contact OWNERS

One of the hardest things about contributing can be getting someone to review (and hopefully approve after changes) your PR. At any time, the K/K repository has nearly 1000 open PRs, so simply creating one isn’t usually enough to get it attention. Also many contributors get a flood of Github notifications, so relying just on those isn’t enough.

The first step is making sure that you have the correct sig/ labels attached; many SIGs search for PRs aimed at them periodically. Secondly, if you have been part of any mentorship program, you should contact your mentor(s) for advice and assistance; even if they can’t review it themselves, they should be able to offer advice on who to contact and how.

If you can attend the SIG meeting of appropriate SIG(s), then you can use that to get some attention to the PR. For miscellaneous PRs, it’s enough to wait until the open floor and ask for a reviewer, or mention it in the SIG meeting chat. If you can’t attend the meeting, try just asking on Slack.

Finally, you can figure out who should care about your PR by looking at the Owners files. Try politely contacting those folks to see if they can review, particularly if you know it’s an area they are interested in.

However, do keep in mind that all of the project reviewers are very busy, have job requirements, and may be in a very different time zone than you. Please be patient, and don’t “spam” lists and channels with rapid and repeated requests.

PRs and Bots: Test Results

Test automation and failures: The bot lets you know about CI results on your PR.

PRs and Bots: Following Up

Answer questions

Resolve:

Bot messages

Code comments

Test failures

Different reviewers will have different opinions, don't be afraid to ask for clarification.

Don’t over-react, though. Different reviewers can have different opinions, and sometimes you need to wait for other project members to argue things out before you make changes and update the PR.

READ what the bot tells you, expand the hidden sections, click on the links, do the things...

Contributor Ladder

Subproject Owner

Set priorities and approve proposals for subproject

Responsibility and leadership for entire repository/directory

Approver

Approve contributions for acceptance

Highly experienced reviewer and contributor in subproject

Reviewer

History of reviewing; reviews frequently

Authorship in subproject

Member

Active contributor to the project

Sponsored by two Reviewers

Non-member Contributors

Contributor Ladder: Membership

Membership will affect your pull request workflow and remove some of the obstacles.

Contributor Ladder: Membership

Contributor Ladder

Low hurdle for initial membership

See link for specific details: http://git.k8s.io/community/community-membership.md

OWNERS

YAML!!! Feeds the bots…

Live browser open the links and show them

Playground Exercise

Let’s play with checking your GitHub basics, your Git basics, your CLA signature is present, and give you a sense of review/approve workflow.

https://sigs.k8s.io/contributor-playground

  • Fork and clone
  • Make changes in “sandiego” directory
  • Pull request
  • Review/comment/rebase
  • Pay attention to labels and bot prompts

Playground Exercise

OWNERS ...look in the file. It’s our helpers for the day!

Now let’s create some PRs!

Go through this to demonstrate it in action.

1. on each table, have half the people be the “PR authors” and half be “reviewers”

2. the authors should create PRs to create a new file, change an existing file, even fix a typo. NOTE: stay in your playground folder for faster review ;)

3. the reviewers should make some comments, the author should respond, reviewers (see OWNERS file) can /lgtm

4. approvers (see OWNERS file) can /approve

People who have not signed the CLA will not be able to participate :-(

CLA and “git config user.name” must match: https://sigs.k8s.io/contributor-playground/exercises/cla-vs-git-author.md

Deal with situations such as rebasing, ok-to-test if/when they come up.

  • Have you downloaded the things?
  • Have you installed the things?
  • Do you have k/k forked and cloned?
  • Can you “make”?

Dev Environment: Status Check

Lunch Break

Let us know if you need any additional hands on help with your laptop configuration...

“make” should work now...

Dev Environment: Final Check

We’ll spend much of the next hour building things and tinkering.

If something’s not working ask for help.

Consider multi-tasking trying and debugging on your laptop and your neighbor’s laptop: peer programming.

Build System(s)

  • local OS
    • or
  • container based

  • go build
  • make
  • bazel build

https://git.k8s.io/kubernetes/build/README.md

Building tends to leak build host attributes into the build. A large project needs to manage this.

Quick local builds that don’t manage this are possible with just golang’s “go build”.

Multiple options for slower, more controlled builds. These require docker and image downloads. Or require installing bazel and java and a much more complex toolchain.

As mentioned earlier, building is resource intensive.

(not going to cover bazel here...advanced topic)

Make Targets

  • ‘make’: go build of host OS/arch-specific core binaries

  • ‘make release’: (don’t do this)
    • containerized build of client/server/node binaries
    • Window, MacOS, Linux
    • x86/386, x86_64/amd64, arm, arm64, ppc64le, s390x

  • ‘make quick-release’:
    • containerized build of core binaries
    • defaults to linux/amd64

Don’t run “make release” :)

All output goes in your ./_output directory.

Make Targets

  • ‘make WHAT=cmd/kubectl
    • build kubectl for your host OS/arch

  • KUBE_BUILD_PLATFORMS=windows/amd64 \

make WHAT=cmd/kubectl’

    • build kubectl for windows/amd64

  • ‘make help’: info on make targets

Make Targets: Try it...build kubectl!

  • Edit cmd/kubectl/kubectl.go
  • Add a “hello world” print out in “func main()”, eg:

fmt.Println("Hello San Diego!")

  • Build:

make WHAT=cmd/kubectl

  • New binary?

ls -al _output/local/go/bin/kubectl

  • Run your binary:

cd ./_output/local/go/bin

./kubectl version

Testing

  • Unit: test via native golang

  • Integration: test package or component interactions

  • End-to-end (“e2e”): tests overall system behavior and coherence on a fully integrated cluster

  • Conformance: subset of e2e, tests SIG Architecture approved to define the core set of interoperable features

https://bit.ly/k8s-ncw-testing

https://github.com/kubernetes/community/tree/master/contributors/guide#testing

https://github.com/kubernetes/community/blob/master/contributors/devel/testing.md

https://github.com/kubernetes/community/blob/master/contributors/devel/testing.md#integration-tests

https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-tests.md

https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-tests.md#local-clusters

https://github.com/kubernetes/community/blob/master/contributors/devel/conformance-tests.md

Testing: Unit Tests

  • Simple native golang

  • Example: run kubectl’s unit tests

  • cd pkg/kubectl; go test ./…

ok k8s.io/kubernetes/pkg/kubectl 5.525s

? k8s.io/kubernetes/pkg/kubectl/apply [no test files]

ok k8s.io/kubernetes/pkg/kubectl/apply/parse 0.442s

ok k8s.io/kubernetes/pkg/kubectl/apply/strategy 2.916s

ok k8s.io/kubernetes/pkg/kubectl/apps 0.251s

.

.

Testing: Integration

  • Package or component interactions

  • Requires dependency management

  • Example: run a test of k8s code + etcd

  • hack/install-etcd.sh; make test-integration

These can get quite complex.

Testing: End-to-End (e2e)

  • Cluster interactions

  • Requires … a cluster

  • Example: run a focused e2e test (requires Linux)

sudo PATH=$PATH hack/local-up-cluster.sh

export KUBECONFIG=/path/to/kubeconfig

kubetest --provider=local --test --test_args="--minStartupPods=1 --ginkgo.focus=Secrets"

These can get quite complex.

Not going to actually try to run these in class. Try it yourself eventually...

Testing: Conformance

  • Subset of e2e
  • SIG Architecture approved tests
  • Represent core set of interoperable features
  • Example: run the conformance tests

(see previous on local-cluster-up.sh)

make WHAT="test/e2e/e2e.test vendor/github.com/onsi/ginkgo/ginkgo cmd/kubectl"

kubetest --provider=skeleton --test --test_args="--ginkgo.focus=\[Conformance\]"

These can get quite complex.

Not going to actually try to run these in class. Try it yourself eventually...

Testing: Minikube

  • https://github.com/kubernetes/minikube/
  • Kubernetes cluster-in-a-VM on your local machine!

  • Requirements:
    • Host machine with kubectl
    • Guest VM ability
    • Host<->Guest networking and internet connectivity

You do need a test cluster, because you’re going to test your code. Right?

Cluster needs etcd, control plane and worker nodes, quorum, and so on.

Minikube gives you this all in a VM…fairly easily.

You might later build out a test cluster on bare metal or a public cloud. Start simple, but if you want to do the hard way then follow https://github.com/kelseyhightower/kubernetes-the-hard-way/

Minikube checkout/build might take a half a gig.

Internet connectivity is in order to download the minikube VM .iso file on first run. Subsequently it should not be needed.

You have a hypervisor choice via “vm-driver” on the minikube command line.

Linux supports VirtualBox and KVM/qemu. The latter can do nested-virt, if hardware and kernel allow, and the system allows your non-root user access to this.

If you’re going to try building/running k8s and minikube on MacOS you’ve got a lot of complexity especially because of the high likelihood of multiple hypervisors running multiple VMs all in parallel:

Is Virtual Box or VMware Fusion running some Windows VM right now for whatever reasons you have?

Do you have Docker for MacOS installed to allow you to build k8s? It runs all its containers in a Moby linux virtual machine with its own hypervisor driver

Did you shut the lid on your laptop and think all of this would come back up cleanly?

Do all of these have the correct virtual network connectivity?

Do all of these in aggregate use more resources than your MacBook has available? (Don’t forget you’ve got Slack, Chrome, etc., etc. running too)

Likewise if it’s the linux subsystem on a Windows laptop.

Testing: KinD

  • https://github.com/kubernetes-sigs/kind/
  • Kubernetes cluster-in-a-container on your local machine!

  • Requirements:
    • Docker runtime
    • Internet connectivity

  • Get KinD, build k8s from source, start cluster:
    • GO111MODULE="on" go get -u sigs.k8s.io/kind@master
    • kind build node-image
    • kind create cluster --image kindest/node:latest

Requires k8s source checkout in:

$(go env GOPATH)/src/k8s.io/kubernetes

Docker runtime still needs a lot of resources (CPU/RAM).


Internet needed to pull container images, could be cached/mirrored after first download.

SIGs, Areas, Issues: Engaging

What’s next for you?

SIGs, Areas, Issues: Engaging

Community Contributions

  • Filing Issues
  • Answering Questions on StackOverflow
  • Github Repo Management
  • Blogging, Evangelism, and Promotion
  • Event Management and Volunteering
  • Visual Communication
  • User Experience Feedback and Surveys
  • Helping Manage Youtube Recordings
  • ...and more!

You don’t have to be a developer to contribute! Contributions can be a lot of different things. Not everyone will contribute via pull request, but just because you contribute in non-code ways does not mean you shouldn’t be a member.

SIGs, Areas, Issues: Engaging

Mentoring Opportunities

  • Meet-Our-Contributors
  • Group Mentoring
  • Release Team Shadow
  • 1-on-1 ad-hoc mentoring
  • GSOC/Outreachy/KubeCon Speed Mentoring

SIGs, Areas, Issues: Engaging

Kubernetes Tutorials

  • As an operator
  • As an app developer
  • As a kubernetes developer

https://kubernetes.io/docs/tutorials/

SIGs, Areas, Issues: Engaging

SIGs, Areas, Issues: Engaging

Right here at KubeCon!

  • Sessions
  • SIG Intros
  • SIG Deep Dives
  • Hallway Track

Filter by the maintainer track in the schedule

  • Search for good first issue & help wanted issues
  • Search by SIG & Area labels to match your interest
  • Discuss at tables ideas for contributing

...carry this discussion into the SIG Meet & Greet

Help Wanted: First PR Ideas

END BEGINNER

BEGIN INTERMEDIATE

Intermediate Session

🗄

The Kubernetes Monolith

Core Repository

Additional Repositories

🗄

website

🗄

test-infra

kind

...totaling

~190 repos

Reminder that not all the important code lives in the core repository. Also remember there’s two orgs, as previously mentioned.

kubernetes

kubernetes

kubernetes

kubernetes

kubernetes

kubernetes

kubernetes

kubernetes

kubernetes

kubernetes/pkg

A Shortcut To /staging

A Shortcut To /staging

  • /api
  • /apis

  • /api/core/v1
  • api

/pkg:

/staging/src/k8s.io

/pkg/apis vs /staging/src/k8s.io/api

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg/controller

Here lives the code that runs all the Kubernetes objects.

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg

kubernetes/pkg

kubernetes

kubernetes/plugin

kubernetes

kubernetes/staging/src/k8s.io

kubernetes/staging/src/k8s.io

kubernetes/staging/src/k8s.io

kubernetes/staging/src/k8s.io

kubernetes/staging/src/k8s.io

kubernetes/staging/src/k8s.io

kubernetes/staging/src/k8s.io

kubernetes/staging/src/k8s.io

kubernetes/staging/src/k8s.io

kubernetes/staging/src/k8s.io

kubernetes/staging/src/k8s.io

kubernetes/staging/src/k8s.io

kubernetes/staging/src/k8s.io

kubernetes/staging/src/k8s.io

kubernetes/staging/src/k8s.io

kubernetes/staging/src/k8s.io

kubernetes

A Side Tour To Test-Infra

kubernetes

kubernetes

kubernetes

LUNCH BREAK!

WELCOME BACK

Credit: @datamattsson on twitter

Building Binaries

Build and modify the kubectl binary, and use it against a locally deployed cluster

🛠 ➡️ ➡️ ✅

Welcome back from the break

Building Binaries: Prerequisites

GO111MODULE="on"; go get sigs.k8s.io/kind@v0.6.0

export PATH=$PATH:$GOPATH/bin

make sure you have 1.13.4 or above, and the kubernetes source on your machine

Modifying Kubectl

Open the file

cmd/kubectl/kubectl.go

with your prefered text editor.

Add “fmt” to the imports

After ~line 38

command := cmd.NewDefaultKubectlCommand()

add a print statement

fmt.Println("Alpacas are fluffy")

Modify the kubectl code, to build a binary with a custom message

Building the modified kubectl

$make WHAT=cmd/kubectl

big ol make

Directory names to build. Given that directory, has a main

Using The Binary

kind create cluster \

--image=kubecon.goharbor.io/contribsummit/kindest/node:v1.16.3

Deploy a cluster using KinD

./_output/bin/kubectl get po

Run the binary you built against the cluster!

Using The Binary

Opening A Pull Request, Revisited

Contributor Guide mention

Find an Issue

  • good first issue

  • help wanted

Refer to the contributor guide

Do Not Boil The Ocean

Smaller is better

Write good commit messages

The Bot Will Talk To You

Do what it says.

Finding reviewers and approvers: The bot searches for people and suggests them

Labels and Bot Commands

Bot Commands

Watch Tests

Ask For Help

Finding A Reviewer

  • Follow Bot Prompts
  • Ping Issue author
  • OWNERS file
  • sigs.yaml
  • #pr-reviews on k8s Slack

PR Workflow, Recap

  • You submit Pull Request (PR) using the template
  • You add labels & notes
  • Bots validate and comment on the PR

release-note cncf-cla: no needs-ok-to-test needs-kind needs-sig

  • You add more labels & notes & resolve review comments
  • SIGs & OWNERS review and /approve → approved
  • Other contributors /lgtm → lgtm
  • Tests pass
  • Tide merges the PR

https://prow.k8s.io/command-help

Read what the bot tells you on GitHub

First things it tells you about are:

PR’s merge AUTOMATICALLY when they achieve merge criteria. The bot will tell you what is between you and that continually.

A Beautiful First-Time Pull Request

https://github.com/kubernetes/kubernetes/pull/84591

The Contributor Playground

Membership

LOW BARRIER TO ENTRY

This isn’t supposed to be hard.

Be a good citizen
Build community
Host workshops for contributors
Kubernetes office hours

Contributor Ladder

Owner

Set priorities and approve proposals for subproject

Responsibility and leadership for entire repository/directory

Approver

Approve contributions for acceptance

Highly experienced reviewer and contributor in subproject

Reviewer

History of reviewing; reviews frequently

Authorship in subproject

Member

Active contributor to the project

Sponsored by two Reviewers

Non-member Contributors

Owner

Set priorities and approve proposals for subproject

Responsibility and leadership for entire repository

Approver

Approve contributions for acceptance

Highly experienced reviewer and contributor in subproject

Reviewer

History of reviewing; reviews frequently

Authorship in subproject

Member

Active contributor to the project

Sponsored by two Reviewers

Non-member Contributors

Releases

The 3-month Release Cycle

Feature: work on spec/details of new features.

Development: complete those features:

Code Slush/Freeze: fix bugs and stabilize.

Of course, real work spans several release cycles.

Enhancements Discussion (per SIG): ongoing

Enhancements Freeze: week ~4

Release Branch Creation: week ~7

Code Freeze: week ~8

...bugs, testing, bugs, fixing, bugs, ...iterating

End Code Freeze: week ~12

Release: week ~13

Release Process

Enhancements

Definition

Feature

Work

Bug

Fixing

Release

3 Month Cycle

3 month release cycle

4 releases per year

Release Lifecycle

1.14.x Patch Releases

3mo’s

~9mo’s

K8s Releases

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Feb

Jan

Dec

Definition

Enhancement Work

Fixes

1.14

9 months support lifetime per release

3 supported release streams in parallel

Release Lifecycle

1.14.x Patch Releases

1.15.x Patch Releases

3mo’s

3mo’s

~9mo’s

~9mo’s

K8s Releases

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Feb

Jan

Dec

Definition

Enhancement Work

Fixes

1.15

Definition

Enhancement Work

Fixes

1.14

~9mo’s

3mo’s

Release Lifecycle

1.16.x Patch

1.14.x Patch Releases

1.15.x Patch Releases

3mo’s

3mo’s

~9mo’s

~9mo’s

~9mo’s

K8s Releases

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Feb

Jan

Dec

Definition

Enhancement Work

Fixes

1.16

3mo’s

Definition

Enhancement Work

Fixes

1.15

Definition

Enhancement Work

Fixes

1.14

Release Lifecycle

1.16.x Patch

1.14.x Patch Releases

1.15.x Patch Releases

3mo’s

3mo’s

~9mo’s

~9mo’s

~9mo’s

K8s Releases

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Feb

Jan

Dec

3mo’s

3mo’s

Definition

Enhancement Work

Fixes

1.17

Definition

Enhancement Work

Fixes

1.15

Definition

Enhancement Work

Fixes

1.14

Definition

Enhancement Work

Fixes

1.16

Branch Management

From: https://schd.ws/hosted_files/kccncchina2018english/93/Kubernetes%20Use%20it%2C%20Contribute%20to%20it%2C%20and%20Enjoy%20it%21.pdf

@xiangpengzhao Peter Zhao

Questions?

  • more on sched

Coming Up Next:

Thank you, and
welcome aboard!

From: The Illustrated Children’s Guide To Kubernetes, by Matt Butcher, Bailey Beougher, and Karen Chu.

END INTERMEDIATE

Title

Speaker Name

Content Title

Content Title

Kubernetes Contributor Summit San Diego 2019 - New Contributor Workshop - Google Slides