Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Umbrella issue - Revamping the Kubernetes Developer’s guide #3064

eduartua opened this Issue Jan 2, 2019 · 8 comments


Copy link

eduartua commented Jan 2, 2019

The contributor guide has been revamped. This is a mostly general guide for all who are getting ramped up on Kubernetes upstream contributions. We need to produce a section of that with the name “The developer guide”

As per #1919 and #892, and the content within the /devel folder, we have to decide a structure for the developer guide. It has to be in a way that new developers find it intuitive and well organized.

Primary goals:

  • Have an inventory of everything inside the /devel folder.
  • Update and clean up of /devel, some files have to be updated, moved or just deleted.
  • Create a skeleton.
  • Develope in a logical manner every skeleton point.

This issue is an umbrella tracking issue.

Skeleton draft

We are going to build this thinking of two personas:

  1. Developers that want to contribute to the code base (kubernetes/kubernetes).
  2. Developers that want to build apps over top of k8s.

This initial work will be focused on the understanding of the internals required by persona 1. It is important to have a sense of how they come together to form a functional cluster and how that is used.

As a new developer, the following are the things I would like to read first in order to become familiar with the project:

  1. Prerequisites
  • Setting the dev environment - There is information about this but my feeling the first time I read it was that something was missing, something like a small example or tutorial testing dev tools after installation.

    1. Golang dev environment
    2. Keeping your golang install up to date
    3. Specify the software required with versions (e.g etdc version)
  • Getting the code (git workflow)

    1. fork k8s repo on github
    2. where to put your k8s repo locally
    3. Environment variables to set
  • Concepts to which you must have familiarity and sources.

  1. Communication channels
    Where to ask for help or orientation - We have this in the contributing guide. SIGs, repos, mailing lists, IM/chat, meetings

  2. Quick reference
    Here are the basic steps needed to get set up and contribute.

  3. Status of Kubernetes branches
    A table with information like branch’s name, status about the kinds of contributions it accepts. Example: release branches that are N-3 only allow bug fixes, feature branches are used for feature work to be merged into master later, etc.

  4. Code of Conduct

Both Persona 1 and 2 have in common the previous points.

Specific points for each persona:

Persona 1 (Code Contributor)

  1. How to make a change to Kubernetes
  • Understanding the architecture - Control Plane

    • General introduction of the Kubernetes API server
      1. Terminology and architecture diagram.
      2. API request flow and API Machinery.
      3. Interaction with internal and external objects; worker nodes, kubelet, etc.
      4. API Conventions
      5. Admission controller
      6. Webhooks
    • Kube and Cloud Controller Manager
      1. Overview of how the controller manager bundle programs with different jobs.
    • Communication
      1. Protocols (gRPC, protobuf)
    • Scheduler
      1. Resource requirements
      2. Quality of services requirements
      3. Policy constraints
      4. Affinity and anti-affinity specifications
      5. Data locality
      6. Inter-workload interference
      7. Deadlines
    • How the state of kubernetes objects is managed
      1. Etcd intro
      2. Cluster state
      3. Communication between components via etcd
    • Kubelet
    • Kube-proxy
    • Container Runtime
      Introduction to the assumptions kubernetes makes about the infrastructure resources where it is hosted, and overview of compute, network, storage abstractions:
      1. Compute
      • CRI
      • Resource management
      1. Network
      • CNI
      • DNS related components
      • Resource management
      1. Storage
      • CSI
      • Volumes management
      • StatefulSets
      • Resource management
    • System components (user side)
      1. Kubectl
      2. Client-go
      3. Parts or elements involved in user and admin configuration.
  • Building

    1. Description of kubernetes build process
    • Guidelines on when/if there should be used make TARGET
    1. How to build using Bazel
  • Deploying and running Kubernetes code

    1. Bootstrapping the cluster
    • Cluster component configuration and secrets
    • Starting cluster services
    1. Bootstrapping the cluster with kubeadm
    2. A short tutorial of building
  • Testing

    1. Description of testing and status of coverage test
    • Unit test
    • e2e
    1. integration
    2. Adding a test
    3. Benchmarks
  • Debugging
    A brief description of the best practices and methods used. This information can be taken from subprojects with well defined debugging processes.

  • Submitting a Pull Request
    Lifecycle of a PR

    • Opening a PR
    • Code review
    • Tutorials/model PRs for making changes
  1. How to work within the community to get agreement on some change to the code base.

  2. Others

  • Go vendoring
  • Release process
  • Kubernetes enhancement proposals

Persona 2 (Platform Developer)

Extending kubernetes.

  • Extension points
    1. Kubectl Plugins
    2. API Access Extensions
    3. Custom controllers for native resources
  • Api Extensions
    1. Custom Resource Definitions (CRDs)
    2. Aggregated API Servers
  • Infrastructure Extension
    1. Network Plugins
    2. Storage Plugins
    3. Compute Extensions
    4. Scheduler Extensions

To help out

  1. The first thing we need to create is a definitive skeleton or toc. If you are part of a SIG that has valuable information regards the developer's guide, It is very helpful to make proposals to the points mentioned above.
  2. If you know a file is outdated or lacks information, please comment here.
  3. Ping me or this issue so I can update it with changes.
  4. In case you are helping to re-write, move, and/or remove a linked reference, make a PR pointing out if it is finished or it is in partial completion, and finally referring to this issue.
  5. Lastly, all files used to build this guide will live in community/contributors/devel/guide.

Files to review

Files in the contributors/devel need to be scrubbed for the developer guide. Non-developer relevant topics should be moved over to other parts of the contributor repo or just be deleted. There might be some calls to make.

Check for:

Duplicate content that can be removed.
Might not be appropriate for the developer guide.
Might need to be deleted or combined with another document.
Might be blocked on waiting on another part of the contributor guide to be finished.
(Thanks to Guin here)

Pages to update

Folders to update


  • - referes to, so references to this files has to be changed to and finally removed.
  • - Should be part of developer guide (Point 1.a)
  • - This is going to be part of the developer guide, I think we must segment the information oriented towards either the core devs or platform devs.
  • - This will be part of the developer guide, revision in progress.
  • arch-roadmap-1.png
  • - This document has to be part of k/test-infra - it won’t be part of the developer guide.
  • - The default build process is using kubernetes development helper scripts - is going Bazel to become default?
  • - Should be part of the guide, but where? - move to
  • - filed moved to docs (to be deleted from /devel).
  • - Talks about collaborative development. (To remove)
  • - This doc serves as a design guideline for component configurations. We can reference this document in the main content of the developer guide.
  • - This document has testing information that can be integrated into the guide.
  • - It has to be part of the guide.
  • - It has valuable information for developers, we can take that info and then move it into the docs.
  • - Take info to the README, then consider deletion or to merge with CRI main document.
  • - Should be part the developer guide.
  • - Should be part the developer guide.
  • - This file contains info that can be put in the README and then it can be deleted.
  • - To review with sig testing, it has to be in the dev guide.
  • - To review with sig testing, it has to be in the dev guide.
  • - This is a design document, it can be part of the dev guide.
  • - To decide with sig testing what can be taken to be part of the dev guide.
  • - Has to be part of the dev guide.
  • - Falls within Persona 2? To be moved.
  • - This can be merged into the README.
  • - It has to be in the dev guide.
  • - Great for the debugging part, keep it.
  • - This document has to be called somewhre in the How to contribute part.
  • - this document has to be in the contributor guide. Ask guin.
  • - to include in the guide, has good info about metrics and instrumentation.
  • - To be deleted.
  • - it definitely has to be part of the developer guide.
  • - this document is two years old, it has to be reviewed and updated.
  • - Needs revision too (state of running kubemark clusters on cloud providers). It should be part of the dev guide.
  • - Not sure about this. I'll ask to Christopher Hein.
  • - This document compares two architechtures and explains how to build one them with Kubernetes. It has to be part of the guide.
  • - Ask sig-testing if we can move this. It looks like an doc for operators. Merge into the README is an option too.
  • - Testing document, review with sig-testing.
  • OWNERS - Skip.
  • - Should be part of the developer guide.
  • - This guide.
  • release-cycle.png - Skip.
  • release-lifecycle.png - Skip.
  • - Is going to be part of the dev guide.
  • - This will be deleted, some of information will be taken to the main README.
  • - Is going to be part of the dev guide.
  • - Is going to be part of the dev guide.
  • - This can be added to the vendoring documentation.
  • - Good content for the dev guide, but it needs to be updated.
  • - Should be part of the dev guide - section testing.
  • - To be deleted.
  • - To be deleted.
  • - Support for vagrant has been removed in 1.10. To be archived.
  • - To be deleted.
  • - deleted.
  • - Should be part of the dev guide - section testing.

I will be updating this issue on a daily basis.


This comment has been minimized.

Copy link
Contributor Author

eduartua commented Jan 2, 2019

/sig contributor-experience
cc @parispittman @nikhita


This comment has been minimized.

Copy link

nikhita commented Jan 2, 2019

Looks great, @eduartua! ❤️

/sig contributor-experience
/kind feature

I know its more "developer guide" than contributor guide but would be useful to find/triage issues, so:
/area contributor-guide


This comment has been minimized.

Copy link
Contributor Author

eduartua commented Jan 2, 2019

I rewrote what I had in the doc, so this feels more like a real guide. We need to come to a consensus about the skeleton.


This comment has been minimized.

Copy link

guineveresaenger commented Jan 7, 2019

Thank you so much for this, @eduartua! A couple thoughts, in no particular order:

At the danger of repeating others, I want to point out the Python Developer Guide as a fantastic example of a very useable, helpful dev guide.

Please ping me (here or on Slack) about files that are more a contributor guide topic than a technical dev guide topic that need to be deleted or still incorporated - I'm thinking help-wanted, issues and collab, for instance, are either already elsewhere, or need to be moved/deleted.

In addition to cherry-picks, all release related processes should live in k/sig-release and be linked (and actually from the contrib guide, since it's really more of a process and less of a technical thing).

I'm super excited for a top-level README to tell me where to build WHAT. 😉


This comment has been minimized.

Copy link

guineveresaenger commented Jan 7, 2019

Found a couple related issues; perhaps add to the list of files above:
#1537 (regards
#2759 (regards e2e tests)


This comment has been minimized.

Copy link

tpepper commented Jan 7, 2019

Looking good to me for a start! A few small comments:

The sections:

  • Building and running Kubernetes
  • Deploy process

might better be:

  • Building Kubernetes
  • Deploying and running your Kubernetes code

In the deploy and run section I think some treatment needs given to the multitude of host platforms on which one might run. This also then relates to cloud provider code. I'm curious if @andrewsykim has thoughts on where best cloud provider developer content might fit into the guide.

The Testing section probably should include a "conformance" section in addition to unit, integration and e2e. I see them as a sort of continuum: unit, integration, e2e, conformance.

Debugging: This is a very broad section. It might make sense to seed some sub-categories, eg: control plane component specific, network communications, and client side.

Security: Especially thinking about recent CVEs, I think it's critically important to give developers a sense of the general thread model against a running Kubernetes cluster and the implications
this has on coding. Maybe this is a cross-component discussion under "Understanding the architecture - Control Plane", but it might also be a set of content larger than that.


This comment has been minimized.

Copy link
Contributor Author

eduartua commented Jan 9, 2019

Thank you @tpepper I will include those sections.

@parispittman parispittman moved this from Backlog to In Progress in Contributor Experience Jan 23, 2019

@parispittman parispittman moved this from In Progress to Tracking/Umbrella Issues in Contributor Experience Jan 23, 2019

@parispittman parispittman added this to To do in contributors-documentation subproject via automation Mar 6, 2019


This comment has been minimized.

Copy link

nikhita commented Mar 18, 2019

/priority important-longterm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.