-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
add glossary to documentation #1001
Changes from 3 commits
d739510
7932a8e
07bb860
fe488a5
33d66ec
0a7957d
efb048a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,156 @@ | ||
--- | ||
title: Glossary | ||
authors: | ||
- "@dhellmann" | ||
reviewers: | ||
- "@timothysc" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This should probably be the union of both cluster-api-admins and cluster-api-maintainers here: https://github.com/kubernetes-sigs/cluster-api/blob/master/OWNERS_ALIASES There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should I update the authors, reviewers, or both? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it's fine for the creator of the doc, it's not an OWNERS file. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry, just the reviewers :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done |
||
creation-date: 2019-06-10 | ||
last-updated: 2019-06-10 | ||
--- | ||
|
||
<!-- | ||
|
||
Formatting instructions for this document: | ||
|
||
- Create level 3 section for each glossary entry so other documents can consistently link to the definition. | ||
- Use a bullet list to define sub-entries or variations. | ||
- Wrap each sub-entry or variation in double underscores to have it rendered with emphasis. | ||
- Use semantic linefeeds (https://rhodesmill.org/brandon/2012/one-sentence-per-line/) | ||
|
||
--> | ||
|
||
# Glossary | ||
|
||
This document defines the terms used in other documents created by the Cluster API group. | ||
|
||
## Table of Contents | ||
|
||
[A](#a) | [B](#b) | [C](#c) | [D](#d) | [H](#h) | [I](#i) | [K](#k) | [M](#m) | [O](#o) | [P](#p) | [S](#s) | [W](#w) | ||
|
||
## A | ||
|
||
### Add-ons | ||
|
||
Services beyond the fundamental components of Kubernetes. | ||
|
||
* __Core Add-ons__: Addons that are required to deploy a Kubernetes-conformant cluster: DNS, kube-proxy, CNI. | ||
* __Additional Add-ons__: Addons that are not required for a Kubernetes-conformant cluster (e.g. metrics/Heapster, Dashboard). | ||
|
||
## B | ||
|
||
### Bootstrap | ||
|
||
The process of turning a server into a Kubernetes node. This may involve assembling data to provide when creating the server that backs the Machine, as well as runtime configuration of the software running on that server. | ||
|
||
## C | ||
|
||
### Cluster | ||
|
||
A full Kubernetes deployment. See Management Cluster and Workload Cluster | ||
|
||
### Cluster API | ||
|
||
Or __Cluster API project__ | ||
|
||
The Cluster API sub-project of the SIG-cluster-lifecycle. It is also used to refer to the software components, APIs, and community that produce them. | ||
|
||
### Control plane | ||
|
||
The set of Kubernetes services that form the basis of a cluster. See also https://kubernetes.io/docs/concepts/#kubernetes-control-plane There are two variants: | ||
|
||
* __Self-provisioned__: A Kubernetes control plane consisting of pods or machines wholly managed by a single Cluster API deployment. | ||
* __External__: A control plane offered and controlled by some system other than Cluster API (e.g., GKE, AKS, EKS, IKS). | ||
|
||
## D | ||
|
||
### Default implementation | ||
|
||
A feature implementation offered as part of the Cluster API project, infrastructure providers can swap it out for a different one. | ||
|
||
## H | ||
|
||
### Horizontal Scaling | ||
|
||
TBD | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The ability to add more machines based on policy and well defined metrics. For example, add a machine to a cluster when CPU load average > (X) for a period of time (Y). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. should have added this earlier. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How about if we leave adding that to another PR? I'd like everyone to get in the habit of updating this document as we go along and write other docs. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The trick is to determine who will submit the PR and when? For non-trivial changes, I would recommend opening an issue. For trivial changes, it seems easier just to make the change and save the time of an additional lgtm/approve cycle. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. FWIW, I'd be willing to make this change today. Along with adding a link to the glossary to the GitBook... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm still working out the process myself, so if you want me to make the changes here, that's fine. But I also don't mind filing a separate PR, or having you do it. |
||
|
||
### Host | ||
|
||
see [Server](#server) | ||
|
||
## I | ||
|
||
### Infrastructure provider | ||
|
||
A source of computational resources (e.g. machines, networking, etc.). Examples for cloud include AWS, Azure, Google, etc.; for bare metal include VMware, MAAS, metal3.io, etc. When there is more than one way to obtain resources from the same infrastructure provider (e.g. EC2 vs. EKS) each way is referred to as a variant. | ||
|
||
### Instance | ||
|
||
see [Server](#server) | ||
|
||
### Immutability | ||
|
||
A resource that does not mutate. In kubernetes we often state the instance of a running pod is immutable or does not change once it is run. In order to make a change, a new pod is run. In the context of [Cluster API](#cluster-api) we often refer to an running instance of a [Machine](#machine) is considered immutable, from a [Cluster API](#cluster-api) perspective. | ||
|
||
## K | ||
|
||
### Kubernetes-conformant | ||
|
||
Or __Kubernetes-compliant__ | ||
|
||
A cluster that passes the Kubernetes conformance tests. | ||
|
||
### K/K | ||
|
||
Refers to the [main Kubernetes git repository](https://github.com/kubernetes/kubernetes) or the main Kubernetes project. | ||
|
||
## M | ||
|
||
### Machine | ||
|
||
Or __Machine Resource__ | ||
|
||
The Custom Resource for Kubernetes that represents a request to have a place to run kubelet. | ||
|
||
See also: [Server](#server) | ||
|
||
### Manage a cluster | ||
|
||
Perform create, scale, upgrade, or destroy operations on the cluster. | ||
|
||
### Management cluster | ||
|
||
The cluster where one or more Infrastructure Providers run, and where resources (e.g. Machines) are stored. Typically referred to when you are provisioning multiple clusters. | ||
|
||
## O | ||
|
||
### Operating system | ||
|
||
Or __OS__ | ||
|
||
A generically understood combination of a kernel and system-level userspace interface, such as Linux or Windows, as opposed to a particular distribution. | ||
|
||
## P | ||
|
||
### Provider | ||
|
||
See [Infrastructure Provider](#user-content-infrastructure-provider) | ||
|
||
### Provider implementation | ||
|
||
Existing Cluster API implementations consist of generic and infrastructure provider-specific logic. The [infrastructure provider](#infrastructure-provider)-specific logic is currently maintained in infrastructure provider repositories. | ||
|
||
## S | ||
|
||
### Scaling | ||
|
||
Unless otherwise specified, this refers to horizontal scaling. | ||
|
||
### Server | ||
|
||
The infrastructure that backs a [Machine Resource](#user-content-machine), typically either a cloud instance, virtual machine, or physical host. | ||
|
||
## W | ||
|
||
### Workload cluster | ||
|
||
A cluster whose lifecycle is managed by the Management cluster. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- "@timothysc"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done