writing-a-getting-started-guide.md

Writing a Getting Started Guide

This page gives some advice for anyone planning to write or update a Getting Started Guide for Kubernetes. It also gives some guidelines which reviewers should follow when reviewing a pull request for a guide.

A Getting Started Guide is instructions on how to create a Kubernetes cluster on top of a particular type(s) of infrastructure. Infrastructure includes: the IaaS provider for VMs; the node OS; inter-node networking; and node Configuration Management system. A guide refers to scripts, Configuration Management files, and/or binary assets such as RPMs. We call the combination of all these things needed to run on a particular type of infrastructure a distro.

The Matrix lists the distros. If there is already a guide which is similar to the one you have planned, consider improving that one.

Distros fall into two categories:

• versioned distros are tested to work with a particular binary release of Kubernetes. These come in a wide variety, reflecting a wide range of ideas and preferences in how to run a cluster.
• development distros are tested work with the latest Kubernetes source code. But, there are relatively few of these and the bar is much higher for creating one.

There are different guidelines for each.

Versioned Distro Guidelines

These guidelines say what to do. See the Rationale section for why.

• Send us a PR.
• Put the instructions in docs/getting-started-guides/.... Scripts go there too. This helps devs easily search for uses of flags by guides.
• We may ask that you host binary assets or large amounts of code in our contrib directory or on your own repo.
• Setup a cluster and run the conformance test against it, and report the results in your PR.
• Add or update a row in The Matrix.
• State the binary version of kubernetes that you tested clearly in your Guide doc and in The Matrix.
• Even if you are just updating the binary version used, please still do a conformance test.
  • If it worked before and now fails, you can ask on IRC, check the release notes since your last tested version, or look at git -logs for files in other distros that are updated to the new version.
• Versioned distros should typically not modify or add code in cluster/. That is just scripts for developer distros.
• If a versioned distro has not been updated for many binary releases, it may be dropped from the Matrix.

If you have a cluster partially working, but doing all the above steps seems like too much work, we still want to hear from you. We suggest you write a blog post or a Gist, and we will link to it on our wiki page. Just file an issue or chat us on IRC and one of the committers will link to it from the wiki.

Development Distro Guidelines

These guidelines say what to do. See the Rationale section for why.

• the main reason to add a new development distro is to support a new IaaS provider (VM and network management). This means implementing a new pkg/cloudprovider/$IAAS_NAME.
• Development distros should use Saltstack for Configuration Management.
• development distros need to support automated cluster creation, deletion, upgrading, etc. This mean writing scripts in cluster/$IAAS_NAME.
• all commits to the tip of this repo need to not break any of the development distros
  • the author of the change is responsible for making changes necessary on all the cloud-providers if the change affects any of them, and reverting the change if it breaks any of the CIs.
• a development distro needs to have an organization which owns it. This organization needs to:
  • Setting up and maintaining Continuous Integration that runs e2e frequently (multiple times per day) against the Distro at head, and which notifies all devs of breakage.
  • being reasonably available for questions and assisting with refactoring and feature additions that affect code for their IaaS.

Rationale

• We want want people to create Kubernetes clusters with whatever IaaS, Node OS, configuration management tools, and so on, which they are familiar with. The guidelines for versioned distros are designed for flexibility.
• We want developers to be able to work without understanding all the permutations of IaaS, NodeOS, and configuration management. The guidelines for developer distros are designed for consistency.
• We want users to have a uniform experience with Kubernetes whenever they follow instructions anywhere in our Github repository. So, we ask that versioned distros pass a conformance test to make sure really work.
• We ask versioned distros to clearly state a version. People pulling from Github may expect any instructions there to work at Head, so stuff that has not been tested at Head needs to be called out. We are still changing things really fast, and, while the REST API is versioned, it is not practical at this point to version or limit changes that affect distros. We still change flags at the Kubernetes/Infrastructure interface.
• We want to limit the number of development distros for several reasons. Developers should only have to change a limited number of places to add a new feature. Also, since we will gate commits on passing CI for all distros, and since end-to-end tests are typically somewhat flaky, it would be highly likely for there to be false positives and CI backlogs with many CI pipelines.
• We do not require versioned distros to do CI for several reasons. It is a steep learning curve to understand our our automated testing scripts. And it is considerable effort to fully automate setup and teardown of a cluster, which is needed for CI. And, not everyone has the time and money to run CI. We do not want to discourage people from writing and sharing guides because of this.
• Versioned distro authors are free to run their own CI and let us know if there is breakage, but we will not include them as commit hooks -- there cannot be so many commit checks that it is impossible to pass them all.
• We prefer a single Configuration Management tool for development distros. If there were more than one, the core developers would have to learn multiple tools and update config in multiple places. Saltstack happens to be the one we picked when we started the project. We welcome versioned distros that use any tool; there are already examples of CoreOS Fleet, Ansible, and others.
• You can still run code from head or your own branch if you use another Configuration Management tool -- you just have to do some manual steps during testing and deployment.