Kubeflow – About

Docs: Kubeflow

Mon, 01 Jan 0001 00:00:00 +0000

The Kubeflow project is dedicated to making deployments of machine learning (ML) workflows on Kubernetes simple, portable and scalable. Our goal is not to recreate other services, but to provide a straightforward way to deploy best-of-breed open-source systems for ML to diverse infrastructures. Anywhere you are running Kubernetes, you should be able to run Kubeflow.

Getting started with Kubeflow

Read the Kubeflow overview for an introduction to the Kubeflow architecture and to see how you can use Kubeflow to manage your ML workflow.

Follow the getting-started guide to set up your environment and install Kubeflow.

Watch the following video which provides an introduction to Kubeflow.

What is Kubeflow?

Kubeflow is the machine learning toolkit for Kubernetes. Learn about Kubeflow use cases.

To use Kubeflow, the basic workflow is:

Download and run the Kubeflow deployment binary.
Customize the resulting configuration files.
Run the specified script to deploy your containers to your specific environment.

You can adapt the configuration to choose the platforms and services that you want to use for each stage of the ML workflow: data preparation, model training, prediction serving, and service management.

You can choose to deploy your Kubernetes workloads locally, on-premises, or to a cloud environment.

Read the Kubeflow overview for more details.

The Kubeflow mission

Our goal is to make scaling machine learning (ML) models and deploying them to production as simple as possible, by letting Kubernetes do what it’s great at:

Easy, repeatable, portable deployments on a diverse infrastructure (for example, experimenting on a laptop, then moving to an on-premises cluster or to the cloud)
Deploying and managing loosely-coupled microservices
Scaling based on demand

Because ML practitioners use a diverse set of tools, one of the key goals is to customize the stack based on user requirements (within reason) and let the system take care of the “boring stuff”. While we have started with a narrow set of technologies, we are working with many different projects to include additional tooling.

Ultimately, we want to have a set of simple manifests that give you an easy to use ML stack anywhere Kubernetes is already running, and that can self configure based on the cluster it deploys into.

History

Kubeflow started as an open sourcing of the way Google ran TensorFlow internally, based on a pipeline called TensorFlow Extended. It began as just a simpler way to run TensorFlow jobs on Kubernetes, but has since expanded to be a multi-architecture, multi-cloud framework for running entire machine learning pipelines.

Roadmaps

To see what’s coming up in future versions of Kubeflow, refer to the Kubeflow roadmap.

The following components also have roadmaps:

Getting involved

There are many ways to contribute to Kubeflow, and we welcome contributions! Read the contributor’s guide to get started on the code, and get to know the community in the community guide.

Docs: Use Cases

Mon, 01 Jan 0001 00:00:00 +0000

The end goal of every organization that utilizes machine learning (ML) is to have their ML models successfully run in production and generate value to the business. But what does it take to reach that point?

Before a model ends up in production, there are potentially many steps required to build and deploy an ML model: data loading, verification, splitting, processing, feature engineering, model training and verification, hyperparameter tuning, and model serving.

In addition, ML models can require more observation than traditional applications, because your data inputs can drift over time. Manually rebuilding models and data sets is time consuming and error prone.

To simplify these requirements and challenges, we created Kubeflow.

Deploying and managing a complex ML system at scale

Kubeflow is a scalable, portable, distributed ML platform that runs on Kubernetes. This means that all capabilities of Kubernetes are available to a Kubeflow user. With Kubeflow, you can manage the entire AI organization at scale and still be able to maintain the same quality of control.

Kubeflow and Kubernetes provide consistent and efficient operations and optimized infrastructure. Your researchers can have more time to focus on the valuable tasks of developing domain specific intellectual property rather than debugging DevOps configuration issues.

Kubeflow’s core and ecosystem critical user journeys (CUJs) provide software solutions for end-to-end workflows: build, train and deploy and/or develop a model and create, run and explore a pipeline.

Experimentation with training an ML model

Rapid experimentation is critical to building high quality machine learning models quickly. Kubeflow offers a user-friendly interface (UI) that allows you to track and compare experiments. You can decide later on which experiment was the best and use it as a main source for your future steps.

In addition, Kubeflow 1.1 provides stable software sub-systems for model training, such as Jupyter notebooks and popular ML training operators— TensorFlow and PyTorch that run efficiently and securely in Kubernetes isolated namespaces. The ML training operators simplify configuration and operations of scaling ML training tasks.

Kubeflow has also delivered Critical User Journeys (CUJs), such as the build, train and deploy, which provide end-to-end workflows that speed development. You can read more about the CUJs in the Kubeflow roadmap.

End to end hybrid and multi-cloud ML workloads

The development of ML models can require hybrid and multi-cloud portability and secure sharing between teams, clusters and clouds. Kubeflow is supported by all major cloud providers and available for on-premises installation.

If you need to develop on your laptop, train with GPU on your on-prem cluster and serve in the cloud, Kubeflow provides the portability to support fast experimentation, rapid training and robust deployment in the same or different environments with minimal operational overhead.

Tuning the model hyperparameters during training

During the model development part hyperparameters are often hard to tune. Tuning hyperparameters is critical for model performance and accuracy. Manually configuring hyperparameters is time consuming.

Kubeflow’s hyperparameter tuner (Katib) provides an automated way to match your objectives. This automation can save days of model testing compute time (freeing up valuable infrastructure), and speed the delivery of improved models.

Continuous integration and deployment (CI/CD) for ML

Kubeflow currently doesn’t have a dedicated tool for this purpose. But our users have been using the Pipelines component and it worked really well for them.

Kubeflow Pipelines can be used to create reproducible workflows. These workflows automate the steps needed to build a ML workflow, which delivers consistency, saves iteration time, and helps in debugging, auditability and compliance requirements.

Next steps

See these docs for more information on the topics covered above:

Docs: Contributing to Kubeflow

Mon, 01 Jan 0001 00:00:00 +0000

Welcome to the Kubeflow project!

Getting started as a Kubeflow contributor

This document is the single source of truth for how to contribute to the code base. We’d love to accept your patches and contributions to this project. There are just a few small guidelines you need to follow.

Sign the CLA

Contributions to this project must be accompanied by a Contributor License Agreement (CLA). You (or your employer) retain the copyright to your contribution. This gives us permission to use and redistribute your contributions as part of the project. Head over to https://cla.developers.google.com/ to see your current agreements on file or to sign a new one.

You generally only need to submit a CLA once, so if you’ve already submitted one (even if it was for a different project), you probably don’t need to do it again.

Follow the code of conduct

Please make sure to read and observe our Code of Conduct and inclusivity document.

Consider participating in Kubeflow user research

Maggie Lynn, a user experience researcher, is conducting user studies to inform future developments for Kubeflow. These typically involve a one hour study session conducted online with a thank you gift for providing your feedback. As a member of the Kubeflow community, your feedback and expertise are extremely valuable to us, so if you have time in the next month, please consider participating. To gather your interest, availability, and some basic information about you, please fill out this form where you’ll find out more details about this research opportunity: https://goo.gl/forms/sv5sRo3UfsgeUEjK2

Joining the community

Follow these instructions if you want to

Become a member of the Kubeflow GitHub org (see below)
Become part of the Kubeflow build cop or release teams
Be recognized as an individual or organization contributing to Kubeflow

Joining the Kubeflow GitHub Org

Before asking to join the community, we ask that you first make a small number of contributions to demonstrate your intent to continue contributing to Kubeflow.

There are are a number of ways to contribute to Kubeflow

Submit PRs
File issues reporting bugs or providing feedback
Answer questions on Slack or GitHub issues

You can use this table to see how many contributions you’ve made

Note: This only counts GitHub related ways of contributing

When you are ready to join

Send a PR adding yourself as a member in org.yaml
After the PR is merged an admin will send you an invitation
- This is a manual process that’s generally run a couple times a week
- If a week passes without receiving an invitation reach out on kubeflow#community

Companies/organizations

If you would like your company or organization to be acknowledged for contributing to Kubeflow or participating in the community (being a user counts) please send a PR adding the relevant info to member_organizations.yaml.

If you want your employee’s GitHub contributions to be attributed to your company please ask them to set the company field in their GitHub profile.

Community discussions

There are many ways to contribute! Join one of our communication channels, attend a community meeting, get to know the community. Read the details in our community guide.

Your first contribution

Find something to work on

Help is always welcome! For example, documentation (like the text you are reading now) can always use improvement. There’s always code that can be clarified and variables or functions that can be renamed or commented. There’s always a need for more test coverage. You get the idea - if you ever see something you think should be fixed, you should own it. Here is how you get started.

Starter issues

To find Kubeflow issues that make good entry points:

Start with issues labeled good first issue. For example, see the good first issues in the kubeflow/website repository for doc updates, and in the kubeflow/kubeflow repository for updates to the core Kubeflow code.
For issues that require deeper knowledge of one or more technical aspects, look at issues labeled help wanted. For example, see these issues in the kubeflow/kubeflow repository
Examine the issues in any of the Kubeflow repositories.

Owners files and PR workflow

Our PR workflow is nearly identical to Kubernetes'. Most of these instructions are a modified version of Kubernetes' contributors and owners guides.

Overview of OWNERS files

OWNERS files are used to designate responsibility over different parts of the Kubeflow codebase. Today, we use them to assign the reviewer and approver roles used in our two-phase code review process. Our OWNERS files were inspired by Chromium OWNERS files, which in turn inspired GitHub’s CODEOWNERS files.

The velocity of a project that uses code review is limited by the number of people capable of reviewing code. The quality of a person’s code review is limited by their familiarity with the code under review. Our goal is to address both of these concerns through the prudent use and maintenance of OWNERS files

OWNERS

Each directory that contains a unit of independent code or content may also contain an OWNERS file. This file applies to everything within the directory, including the OWNERS file itself, sibling files, and child directories.

OWNERS files are in YAML format and support the following keys:

approvers: a list of GitHub usernames or aliases that can /approve a PR
labels: a list of GitHub labels to automatically apply to a PR
options: a map of options for how to interpret this OWNERS file, currently only one:
- no_parent_owners: defaults to false if not present; if true, exclude parent OWNERS files. Allows the use case where a/deep/nested/OWNERS file prevents a/OWNERS file from having any effect on a/deep/nested/bit/of/code
reviewers: a list of GitHub usernames or aliases that are good candidates to /lgtm a PR

All users are expected to be assignable. In GitHub terms, this means they are either collaborators of the repo, or members of the organization to which the repo belongs.

A typical OWNERS file looks like:

approvers:
  - alice
  - bob     # this is a comment
reviewers:
  - alice
  - carol   # this is another comment
  - sig-foo # this is an alias

OWNERS_ALIASES

Each repo may contain at its root an OWNERS_ALIAS file.

OWNERS_ALIAS files are in YAML format and support the following keys:

aliases: a mapping of alias name to a list of GitHub usernames

We use aliases for groups instead of GitHub Teams, because changes to GitHub Teams are not publicly auditable.

A sample OWNERS_ALIASES file looks like:

aliases:
  sig-foo:
    - david
    - erin
  sig-bar:
    - bob
    - frank

GitHub usernames and aliases listed in OWNERS files are case-insensitive.

The code review process

The author submits a PR
Phase 0: Automation suggests reviewers and approvers for the PR
- Determine the set of OWNERS files nearest to the code being changed
- Choose at least two suggested reviewers, trying to find a unique reviewer for every leaf OWNERS file, and request their reviews on the PR
- Choose suggested approvers, one from each OWNERS file, and list them in a comment on the PR
Phase 1: Humans review the PR
- Reviewers look for general code quality, correctness, sane software engineering, style, etc.
- Anyone in the organization can act as a reviewer with the exception of the individual who opened the PR
- If the code changes look good to them, a reviewer types /lgtm in a PR comment or review; if they change their mind, they /lgtm cancel
- Once a reviewer has /lgtm‘ed, prow (@k8s-ci-robot) applies an lgtm label to the PR
Phase 2: Humans approve the PR
- The PR author /assign’s all suggested approvers to the PR, and optionally notifies them (eg: “pinging @foo for approval”)
- Only people listed in the relevant OWNERS files, either directly or through an alias, can act as approvers, including the individual who opened the PR
- Approvers look for holistic acceptance criteria, including dependencies with other features, forwards/backwards compatibility, API and flag definitions, etc
- If the code changes look good to them, an approver types /approve in a PR comment or review; if they change their mind, they /approve cancel
- prow (@k8s-ci-robot) updates its comment in the PR to indicate which approvers still need to approve
- Once all approvers (one from each of the previously identified OWNERS files) have approved, prow (@k8s-ci-robot) applies an approved label
Phase 3: Automation merges the PR:
- If all of the following are true:
  - All required labels are present (eg: lgtm, approved)
  - Any blocking labels are missing (eg: there is no do-not-merge/hold, needs-rebase)
- And if any of the following are true:
  - there are no presubmit prow jobs configured for this repo
  - there are presubmit prow jobs configured for this repo, and they all pass after automatically being re-run one last time
- Then the PR will automatically be merged

Quirks of the process

There are a number of behaviors we’ve observed that while possible are discouraged, as they go against the intent of this review process. Some of these could be prevented in the future, but this is the state of today.

An approver’s /lgtm is simultaneously interpreted as an /approve
- While a convenient shortcut for some, it can be surprising that the same command is interpreted in one of two ways depending on who the commenter is
- Instead, explicitly write out /lgtm and /approve to help observers, or save the /lgtm for a reviewer
- This goes against the idea of having at least two sets of eyes on a PR, and may be a sign that there are too few reviewers (who aren’t also approver)
Technically, anyone who is a member of the Kubeflow GitHub organization can drive-by /lgtm a PR
- Drive-by reviews from non-members are encouraged as a way of demonstrating experience and intent to become a collaborator or reviewer
- Drive-by /lgtm’s from members may be a sign that our OWNERS files are too small, or that the existing reviewers are too unresponsive
- This goes against the idea of specifying reviewers in the first place, to ensure that author is getting actionable feedback from people knowledgeable with the code
Reviewers, and approvers are unresponsive
- This causes a lot of frustration for authors who often have little visibility into why their PR is being ignored
- Many reviewers and approvers are so overloaded by GitHub notifications that @mention’ing is unlikely to get a quick response
- If an author /assign’s a PR, reviewers and approvers will be made aware of it on their PR dashboard
- An author can work around this by manually reading the relevant OWNERS files, /unassign‘ing unresponsive individuals, and /assign‘ing others
- This is a sign that our OWNERS files are stale; pruning the reviewers and approvers lists would help with this
- It is the PR authors responsibility to drive a PR to resolution. This means if the PR reviewers are unresponsive they should escalate as noted below
  - e.g ping reviewers in a timely manner to get it reviewed
  - If the reviewers don’t respond look at the OWNERs file in root and ping approvers listed there
Authors are unresponsive
- This costs a tremendous amount of attention as context for an individual PR is lost over time
- This hurts the project in general as its general noise level increases over time
- Instead, close PR’s that are untouched after too long (we currently have a bot do this after 90 days)

Automation using OWNERS files

`prow`

Prow receives events from GitHub, and reacts to them. It is effectively stateless. The following pieces of prow are used to implement the code review process above.

cmd: tide
- per-repo configuration:
  - labels: list of labels required to be present for merge (eg: lgtm)
  - missingLabels: list of labels required to be missing for merge (eg: do-not-merge/hold)
  - reviewApprovedRequired: defaults to false; when true, require that there must be at least one approved pull request review present for merge
  - merge_method: defaults to merge; when squash or rebase, use that merge method instead when clicking a PR’s merge button
- merges PR’s once they meet the appropriate criteria as configured above
- if there are any presubmit prow jobs for the repo the PR is against, they will be re-run one final time just prior to merge
plugin: assign
- assigns GitHub users in response to /assign comments on a PR
- unassigns GitHub users in response to /unassign comments on a PR
plugin: approve
- per-repo configuration:
  - issue_required: defaults to false; when true, require that the PR description link to an issue, or that at least one approver issues a /approve no-issue
  - implicit_self_approve: defaults to false; when true, if the PR author is in relevant OWNERS files, act as if they have implicitly /approve’d
- adds the approved label once an approver for each of the required OWNERS files has /approve’d
- comments as required OWNERS files are satisfied
- removes outdated approval status comments
plugin: blunderbuss
- determines reviewers and requests their reviews on PR’s
plugin: lgtm
- adds the lgtm label when a reviewer comments /lgtm on a PR
- the PR author may not /lgtm their own PR
pkg: k8s.io/test-infra/prow/repoowners
- parses OWNERS and OWNERS_ALIAS files
- if the no_parent_owners option is encountered, parent owners are excluded from having any influence over files adjacent to or underneath of the current OWNERS file

Maintaining OWNERS files

OWNERS files should be regularly maintained.

We encourage people to self-nominate or self-remove from OWNERS files via PR’s. Ideally in the future we could use metrics-driven automation to assist in this process.

We should strive to:

grow the number of OWNERS files
add new people to OWNERS files
ensure OWNERS files only contain org members and repo collaborators
ensure OWNERS files only contain people are actively contributing to or reviewing the code they own
remove inactive people from OWNERS files

Bad examples of OWNERS usage:

directories that lack OWNERS files, resulting in too many hitting root OWNERS
OWNERS files that have a single person as both approver and reviewer
OWNERS files that haven’t been touched in over 6 months
OWNERS files that have non-collaborators present

Good examples of OWNERS usage:

there are more reviewers than approvers
the approvers are not in the reviewers section
OWNERS files that are regularly updated (at least once per release)

Docs: Community

Mon, 01 Jan 0001 00:00:00 +0000

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

The Kubeflow community is guided by our Code of Conduct, which we encourage everybody to read before participating. We hold our leaders accountable for the guidelines in this document.

Welcome to all Google Summer of Code (GSoC) participants

The Kubeflow community is delighted to be part of Google Summer of Code 2020. Community mentors look forward to working with students on their GSoC projects.

Visit the Kubeflow GSoC page to find handy information and links for GSoC students and mentors.

Community discussions

There are many ways to contribute! Join one of our communication channels, attend a community meeting, get to know the community, discuss updates, suggest exciting new integrations.

Community meetings

Meeting calendar (iCal version).

Meeting notes.

If your group has a regular meeting, talk to @ewilderj about getting it added to the calendar.

Kubeflow community call

The project team holds a weekly community call on Tuesdays. This call alternates weekly between US East/EMEA and US West/APAC friendly times. Joining the kubeflow-discuss mailing list will automatically send you calendar invitations for the meetings, or you can subscribe to the community meeting calendar above.

Agenda, notes, and a reminder of the next call are sent to the kubeflow-discuss mailing list.

Slack community and channels

The Kubeflow Slack workspace is kubeflow.slack.com. To join, click this invitation to our Slack workspace.

The Kubeflow Slack workspace offers several channels. Here are a few examples:

Topic	Slack channel
General discussion	#general
Community meeting chat	#community
WG AutoML (GitHub)	#wg-automl
WG Training (GitHub)	#wg-training
KFServing (GitHub)	#kfserving
Pipelines (GitHub)	#kubeflow-pipelines
Examples (GitHub)	#kubeflow-examples
Documentation (GitHub)	#website
Product management	#product-management
Google Summer of Code (GSoC)	#gsoc

Mailing lists

The primary mailing list (email group) is kubeflow-discuss.

More detail about the Kubeflow mailing lists:

Topic	Mailing list
General discussion	kubeflow-discuss

Who should consider contributing to Kubeflow?

Folks who want to add support for other ML frameworks (e.g. PyTorch, XGBoost, scikit-learn)
Folks who want to bring more Kubernetes magic to ML (e.g. ISTIO integration for prediction)
Folks who want to make Kubeflow a richer ML platform (e.g. support for ML pipelines, hyperparameter tuning, neural architecture search)
Folks who want to tune Kubeflow for their particular Kubernetes distribution or Cloud
Folks who want to write tutorials or blog posts showing how to use Kubeflow to solve ML problems

For details on contributing please look at the contributor’s guide.

Docs: Google Summer of Code

Mon, 01 Jan 0001 00:00:00 +0000

The Kubeflow community is delighted to be part of Google Summer of Code (GSoC) 2020. Community mentors look forward to working with students on their GSoC projects.

Top links:

Information for students

The GSoC student application phase is now closed and student selection is in progress. See the GSoC timeline.

You’re still welcome to explore Kubeflow. Kubeflow welcomes contributions at any time, whether within or outside the framework of GSoC. See the community page for Slack channels, mailing lists, meetings, and other ways to connect with the Kubeflow community.

For more information about GSoC, see the GSoC docs and guides.

Information for mentors

Thanks to all mentors who’re interested in helping a GSoC student with their Kubeflow project.

To get started:

Read the Google Summer of Code mentor guide and the roles and responsibilities to understand what is expected of you over the next 6 months.
Bookmark the GSoC timeline and be prepared to take action in time for the milestones shown on the timeline, and to help your students meet the deadlines.
Watch the 5 minute YouTube video: Being a Great GSoC Mentor. The video was shot with GSoC veteran org admins and mentors. It contains helpful information about the program and how to participate successfully at each step in GSoC.
If you’re not registered as a mentor, email kubeflow-gsoc-admin@kubeflow.org to indicate your interest in mentoring a student during GSoC.
When you receive an invitation, follow the link in the email to register on the GSoC program site.
Examine the student proposals. Click want to mentor on the proposals that you’d like to mentor.

Start chatting to students:

Join the #gsoc channel on Kubeflow Slack and answer students' questions.
Respond to students' questions on the Kubeflow mentors mailing list (kubeflow-gsoc-mentors@kubeflow.org).

For more information about GSoC, see the GSoC docs and guides.

Mailing lists

These are the Kubeflow mailing lists related to GSoC:

kubeflow-gsoc-mentors@kubeflow.org: The mentor mailing list for Kubeflow GSoC projects. Students can email this group to receive feedback on project proposals. Mentors and org administrators can use this group to discuss Kubeflow GSoC matters. Group members are Kubeflow GSoC mentors and org administrators. Messages are visible to sender, CCs, and group members.
kubeflow-gsoc-admin@kubeflow.org: The organization administrator mailing list for Kubeflow’s participation in GSoC. Students and mentors can email this group to raise Kubeflow GSoC matters with the administrators. Group members are Kubeflow GSoC org administrators only. Messages are visible to sender, CCs, and group members.
kubeflow-discuss: Kubeflow’s primarily mailing list and discussion group. See the community page for more information.

Docs: Docs

Mon, 01 Jan 0001 00:00:00 +0000

Welcome to the Kubeflow documentation!

Introduction

The Kubeflow docs are published at www.kubeflow.org.

The source for the docs is in the kubeflow/website repo on GitHub. We use Hugo to format and generate our website, and Netlify to manage the deployment of the site.

Versioning

www.kubeflow.org points to the master branch of the docs. You can access other versions by clicking the version dropdown at top right of the website menu bar:

We create a new branch of the docs for each stable release of Kubeflow. For example, the docs for the v0.2 stable release are on published on the v0.2 website, which corresponds to the v0.2-branch on GitHub.

Contributing to the docs

We welcome updates to the docs! Please help us make them better. Small fixes, typos, bug fixes, plugging gaps—all are useful.

For help with getting started, take a look at the README.
For guidance on writing effective documentation, see the style guide.

Docs: Style Guide for the Kubeflow Docs

Mon, 01 Jan 0001 00:00:00 +0000

This style guide is for the Kubeflow documentation. The style guide helps contributors to write documentation that readers can understand quickly and correctly. The Kubeflow docs aim for:

Consistency in style and terminology, so that readers can expect certain structures and conventions. Readers don’t have to keep re-learning how to use the documentation or questioning whether they’ve understood something correctly.
Clear, concise writing so that readers can quickly find and understand the information they need.

Use standard American spelling

Use American spelling rather than Commonwealth or British spelling. Refer to Merriam-Webster’s Collegiate Dictionary, Eleventh Edition.

Use capital letters sparingly

Some hints:

Capitalize only the first letter of each heading within the page. (That is, use sentence case.)
Capitalize (almost) every word in page titles. (That is, use title case.) The little words like “and”, “in”, etc, don’t get a capital letter.
In page content, use capitals only for brand names, like Kubeflow, Kubernetes, and so on. See more about brand names below.
Don’t use capital letters to emphasize words.

Spell out abbreviations and acronyms on first use

Always spell out the full term for every abbreviation or acronym the first time you use it on the page. Don’t assume people know what an abbreviation or acronym means, even if it seems like common knowledge.

Example: “To run Kubernetes locally in a virtual machine (VM)”

Use contractions if you want to

For example, it’s fine to write “it’s” instead of “it is”.

Use full, correct brand names

When referring to a product or brand, use the full name. Capitalize the name as the product owners do in the product documentation. Do not use abbreviations even if they’re in common use, unless the product owner has sanctioned the abbreviation.

Use this	Instead of this
Kubeflow	kubeflow
Kubernetes	k8s
ksonnet	Ksonnet

Be consistent with punctuation

Use punctuation consistently within a page. For example, if you use a period (full stop) after every item in list, then use a period on all other lists on the page.

Check the other pages if you’re unsure about a particular convention. Examples:

Most pages in the Kubeflow docs use a period at the end of every list item.
There is no period at the end of the page subtitle and the subtitle need not be a full sentence. (The subtitle comes from the description in the front matter of each page.)

Use active voice rather than passive voice

Passive voice is often confusing, as it’s not clear who should perform the action.

Use active voice	Instead of passive voice
You can configure Kubeflow to	Kubeflow can be configured to
Add the directory to your path	The directory should be added to your path

Use simple present tense

Avoid future tense (“will”) and complex syntax such as conjunctive mood (“would”, “should”).

Use simple present tense	Instead of future tense or complex syntax
The following command provisions a virtual machine	The following command will provision a virtual machine
If you add this configuration element, the system is open to the Internet	If you added this configuration element, the system would be open to the Internet

Exception: Use future tense if it’s necessary to convey the correct meaning. This requirement is rare.

Address the audience directly

Using “we” in a sentence can be confusing, because the reader may not know whether they’re part of the “we” you’re describing. For example, compare the following two statements:

“In this release we’ve added many new features.”
“In this tutorial we build a flying saucer.”

The words “the developer” or “the user” can be ambiguous. For example, if the reader is building a product that also has users, then the reader does not know whether you’re referring to the reader or the users of their product.

Address the reader directly	Instead of "we", "the user", or "the developer"
Include the directory in your path	The user must make sure that the directory is included in their path
In this tutorial you build a flying saucer	In this tutorial we build a flying saucer

Use short, simple sentences

Keep sentences short. Short sentences are easier to read than long ones. Below are some tips for writing short sentences.

Use fewer words instead of many words that convey the same meaning
Use this	Instead of this
You can use	It is also possible to use
You can	You are able to

Split a single long sentence into two or more shorter ones
Use this	Instead of this
You do not need a running GKE cluster. The deployment process creates a cluster for you	You do not need a running GKE cluster, because the deployment process creates a cluster for you

Use a list instead of a long sentence showing various options
To train a model: Package your program in a Kubernetes container. Upload the container to an online registry. Submit your training job.	To train a model, you must package your program in a Kubernetes container, upload the container to an online registry, and submit your training job.

Use a list instead of a long sentence showing various options

Use this

Instead of this

To train a model:

Package your program in a Kubernetes container.
Upload the container to an online registry.
Submit your training job.

To train a model, you must package your program in a Kubernetes container, upload the container to an online registry, and submit your training job.

Avoid too much text styling

Use bold text when referring to UI controls or other UI elements.

Use code style for:

filenames, directories, and paths
inline code and commands
object field names

Avoid using bold text or capital letters for emphasis. If a page has too much textual highlighting it becomes confusing and even annoying.

Use angle brackets for placeholders

For example:

export KUBEFLOW_USERNAME=<your username>
--email <your email address>

Style your images

The Kubeflow docs recognise Bootstrap classes to style images and other content. The following code snippet shows the typical styling that makes an image show up nicely on the page:

<img src="/docs/images/my-image.png"
  alt="My image"
  class="mt-3 mb-3 p-3 border border-info rounded">

To see some examples of styled images, take a look at the OAuth setup page. To see the markup, search for .png in the page source.

For more help, see the guide to Bootstrap image styling and the Bootstrap utilities, such as borders.

A detailed style guide

The Google Developer Documentation Style Guide contains detailed information about specific aspects of writing clear, readable, succinct documentation for a developer audience.

Next steps

Take a look at the documentation README for guidance on contributing to the Kubeflow docs.

Docs: Events Calendar

Mon, 01 Jan 0001 00:00:00 +0000

This is a nonexhaustive list of events (in reverse chronological order) with talks and workshops about Kubeflow. Please edit this page and send a pull request, or raise a GitHub issue, if something is missing or incorrect.

Kubeflow Doc Sprint - Sunnyvale and online, 10-12 February 2020
- Monday 10 February: Welcome; docs/code development; learning sessions.
- Tuesday 11 February: Sprint updates; docs/code development; learning sessions.
- Wednesday 12 February: Docs/code development; sprint demos.
Kubeflow Doc Sprint, 10-12 July 2019. See the results of the July 2019 doc sprint.
Google Cloud Next, San Francisco, 9-11 April, 2019
- Undoing Human Bias at Scale With Kubeflow: John Bohannon, Michelle Casbon
Kubeflow Contributor Summit 2019, Sunnyvale, CA, 12-13 March, 2019
- Kubeflow and the ML Landscape: Jeremy Lewi, Google
  - Slides
- Updates from the PM Working Group:
  - PMs: David Aronchick, Josh Bottum, Carmine Rimi
  - Slides
- Building Together: Community in Kubeflow: Thea Lamkin, Google
  - Slides
- Experiment Tracking with Kubeflow, Lukas Biewald, Weights & Biases
  - Slides
- Multi-User Environments, Kam Kasravi & Ebi Shahbazi, Intel
  - Slides
- On-Premise: Debo Dutta, Cisco
  - Slides
- MiniKF: Local Kubeflow: Vangelis Koukis, Arrikto
  - Slides
- TensorFlow 2.0 is coming!: Paige Bailey, Google
  - Slides
- Overview of Kubeflow Pipelines: Pavel Dournov, Google
  - Slides
- Feast: Feature Storage for Machine Learning: Tim Sell, Google
  - Slides
- Understanding the Earth: Machine Learning with Kubeflow Pipelines: Faustine Li, Descartes Labs
  - Slides
- Kubeflow Experiments at LinkedIn: Tengfei Mu & Abin Shahab, LinkedIn
  - Slides
- Ask the User: Data Science Panel, Moderator: Karthik Ramasamy, Google
  - Panelists: Ting Chen, Emmanuel Ameisen, Scott Leishman, Caio Soares, June Andrews, Jun Wang
- Simple, GPU-Accelerated Kubeflow Pipeline: Ananth Sankarasubramanian, NVIDIA
  - Slides
- Fairing: Matt Rickard, Google
  - Slides
- ModelDB: Open-source model management: Manasi Vartak, Verta.ai
  - Slides
- Katib & Hyperparameter Tuning: Richard Liu, Google
  - Slides
- Kubeflow User Experience: Derek Ferguson, JP Morgan Chase
  - Slides
- Kubeflow & TFX: Kevin Haas, Google
  - Slides
- Kubeflow inference on Knative: Dan Sun, Bloomberg
  - Slides
- Arena: Yang Che, Alibaba
  - Slides
  - Demo video
- Examples, Codelabs, & Demos: Michelle Casbon, Google
  - Slides
Data Day Texas, Austin, 26 January, 2019
- Kubeflow: Portable Machine Learning on Kubernetes: Michelle Casbon
  - Slides
AI NEXTCon, Seattle, 23-26 January, 2019
- Build and Manage Machine Learning Pipelines: Amy Unruh
KubeCon, Seattle, 11-13 December, 2018
- Deep Dive: Kubeflow BoF: Jeremy Lewi, David Aronchick
  - Slides
  - Video
- Eco-Friendly ML: How the Kubeflow Ecosystem Bootstrapped Itself: Peter McKinnon
  - Slides
  - Video
- Machine Learning as Code: Jay Smith
  - Slides
  - Video
- Natural Language Code Search for GitHub Using Kubeflow: Jeremy Lewi, Hamel Husain
  - Slides
  - Video
- Workshop: Kubeflow End-to-End: GitHub Issue Summarization: Amy Unruh, Michelle Casbon
  - Codelab
  - Slides
  - Video
Women in ML & Data Science, Melbourne, 5 December, 2018
- Panel: Michelle Casbon
YOW!, Melbourne, 4-7 December, 2018
- Kubeflow Explained: NLP Architectures on Kubernetes: Michelle Casbon
  - Slides
YOW!, Brisbane, 3-4 December, 2018
- Kubeflow Explained: NLP Architectures on Kubernetes: Michelle Casbon
  - Slides
YOW!, Sydney, 27-30 November, 2018
- Kubeflow Explained: NLP Architectures on Kubernetes: Michelle Casbon
  - Slides
Scale By the Bay, San Francisco, 15-17 November, 2018
- Data Engineering & AI Panel: Michelle Casbon
  - Video
KubeCon, Shanghai, 13-15 November, 2018
- A Tale of Using Kubeflow to Make the Electricity Smarter in China: Julia Han, Xin Zhang
  - Slides
  - Video
- A Year of Democratizing ML With Kubernetes & Kubeflow: David Aronchick, Fei Xue
  - Slides
  - Video
- Benchmarking Machine Learning Workloads on Kubeflow: Xinyuan Huang, Ce Gao
  - Slides
  - Video
- CI/CD Pipelines & Machine Learning: Jeremy Lewi
  - Slides
  - Video
- Kubeflow From the End User’s Perspective: Xin Zhang
  - Video
- Kubernetes CI/CD Hacks with KicroK8s and Kubeflow: Land Lu, Zhang Lei Mao
  - Slides
  - Video
- Machine Learning on Kubernetes BoF: David Aronchick
  - Video
- Operating Deep Learning Pipelines Anywhere Using Kubeflow: Jörg Schad, Gilbert Song
  - Slides
  - Video
DevFest, Seattle, 3 November, 2018
- Kubeflow End to End: Amy Unruh
Data@Scale, Boston, 25 October, 2018
- Women in Engineering Panel: Michelle Casbon
- Kubeflow: Portable Machine Learning on Kubernetes: Michelle Casbon
  - Video
Kafka Summit, San Francisco, 16-17 October, 2018
O’Reilly AI Conference, London, 08-11 October, 2018
- Machine Learning at Scale with Kubernetes: Chris Cho
Cloud-Native, Docker, and Kubernetes Summit, Dallas, 12 September, 2018
- Deploying Machine Learning Workloads in Kubernetes clusters that support GPUs: Michael Iatrou
O’Reilly Strata Data, New York, 11-13 September, 2018
- From Training to Serving: Deploying TensorFlow Models with Kubernetes: Brian Foo, Holden Karau, Jay Smith
- Kubeflow Explained: Portable Machine Learning on Kubernetes: Michelle Casbon
O’Reilly AI Conference, San Francisco, 4-7 September, 2018
- TensorFlow Days: Kubeflow: Portable Machine Learning on Kubernetes: Michelle Casbon
Open Source Summit, Vancouver, 29-31 August, 2018
- Elastic AI Pipeline with Kubeflow for Intelligent SKU Management in a Large Chinese Retailer: Xin Zhang
- Introducing Kubeflow: A System for Deploying ML/AI on Kubernetes: Trevor Grant, Holden Karau
JupyterCon, New York, 21-25 August, 2018
- Machine Learning at Scale with Kubernetes: Chris Cho
Google Next, San Francisco, 24-26 July, 2018
- AI Platform Showcase demo: Dan Sanche
  - Video
- Machine Learning Made Easy: How to Build Flexible, Portable ML Stacks with Kubeflow and Elastifile: David Aronchick, Allon Cohen
  - Video
- Spotlight Lab: Introduction to Kubeflow on Google Kubernetes Engine: Michelle Casbon
  - Codelab
- Spotlight Lab: Kubeflow End-to-End: GitHub Issue Summarization: Michelle Casbon
  - Codelab
O’Reilly Open Source Convention, Portland, 16-19 July, 2018
- TensorFlow Day: Hassle-free, scalable machine learning with Kubeflow: Barbara Fusinska
SciPy, Austin, 09-15 July, 2018
- Kubeflow: Pythonic Machine Learning at Scale on Kubernetes: David Aronchick, Paige Bailey
  - Video
Container Day, Paris, 26 June, 2018
- Keynote: Cloud Native ML with Kubeflow: David Aronchick, Chris Cho
  - Video
Dockercon, San Francisco, 12 - 15 June, 2018
- Keynote: Moby’s Cool Hacks: David Aronchick, Michelle Casbon
  - Video
QCon, São Paulo, 9-11 May, 2018
- Architecture of an NLP Deployment: Michelle Casbon
  - Video
KubeCon, Copenhagen, 2-4 May, 2018
- Interview: Building applications on Kubeflow: Jeremy Lewi
  - Video
- Keynote: Cloud Native ML on Kubernetes: David Aronchick, Vishnu Kannan
  - Video
  - Slides
- Kubeflow Deep Dive: David Aronchick, Jeremy Lewi
  - Video
  - Slides
- Kubeflow Intro: Michał Jastrzębski, Ala Raddaoui
  - Video
  - Slides
- Serving ML Models at Scale with Seldon & Kubeflow: Clive Cox
  - Video
  - Slides
- Conquering a Kubeflow Kubernetes Cluster with ksonnet, Ark, & Sonobuoy: David Aronchick, Kris Nova
  - Video
- Building ML Products with Kubeflow: Jeremy Lewi, Stephan Fabel
  - Video
  - Slides
- Compliant Data Management & Machine Learning on Kubernetes: Daniel Whitenack
  - Video
  - Slides
- Bringing Your Data Pipeline into the Machine Learning Era: Chris Gaun, Jörg Schad
  - Video
KubeCon, Austin, 6-8 December, 2017
- “Hot Dog or Not Hot Dog” at Scale - Kubernetes & Machine Learning: David Aronchick, Vishnu Kannan
  - Video