[docs][glossary] Add page that lists all standardized k8s terms (#5657)
* Add comprehensive glossary page Additional Authors: * Andrew Chen <chenopis@users.noreply.github.com> * Steve Perry <steveperry-53@users.noreply.github.com> * incorporate Tim's feedback * address zach's comments * address more comments * add additional crosslinking * Add platform developer, tweak formatting for disambiguation cases or multiparagraph definitions.
This commit is contained in:
Jessica Yao
committed by
Zach Corleissen
Zach Corleissen
parent
8da72ca938
commit
b22947afc3
@@ -1,13 +1,13 @@
|
||||
id: _example
|
||||
name: Example K8s Term
|
||||
formerly:
|
||||
aka:
|
||||
- Slang K8s Term
|
||||
- Misnomer
|
||||
- Formerly Known as Prince
|
||||
related:
|
||||
- Less Fancy K8s Term
|
||||
- Tangential Term
|
||||
- Commonly Used With
|
||||
- id-of-less-fancy-k8s-term
|
||||
- id-of-tangential-term
|
||||
- id-of-commonly-used-with-term
|
||||
tags:
|
||||
- Some Tag
|
||||
short-description: |
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
id: application-architect
|
||||
name: Application Architect
|
||||
related:
|
||||
- application-developer
|
||||
tags:
|
||||
- user-type
|
||||
short-description: |
|
||||
A person responsible for the high-level design of an application.
|
||||
long-description: >
|
||||
An architect ensures that an app's implementation allows it to interact with its surrounding components in a scalable, maintainable way.
|
||||
Surrounding components include databases, logging infrastructure, and other microservices.
|
||||
@@ -0,0 +1,11 @@
|
||||
id: application-developer
|
||||
name: Application Developer
|
||||
related:
|
||||
- application-architect
|
||||
tags:
|
||||
- user-type
|
||||
short-description: |
|
||||
A person who writes an application that runs in a Kubernetes cluster.
|
||||
long-description: >
|
||||
An application developer focuses on one part of an application.
|
||||
The scale of their focus may vary significantly in size.
|
||||
@@ -0,0 +1,10 @@
|
||||
id: approver
|
||||
name: Approver
|
||||
tags:
|
||||
- community
|
||||
short-description: |
|
||||
A person who can review and approve Kubernetes code contributions.
|
||||
long-description: >
|
||||
While code review is focused on code quality and correctness, approval is focused on the holistic acceptance of a contribution.
|
||||
Holistic acceptance includes backwards/forwards compatibility, adhering to API and flag conventions, subtle performance and correctness issues, interactions with other parts of the system, and others.
|
||||
Approver status is scoped to a part of the codebase.
|
||||
@@ -0,0 +1,8 @@
|
||||
id: cla
|
||||
name: CLA (Contributor License Agreement)
|
||||
tags:
|
||||
- community
|
||||
short-description: |
|
||||
Terms under which a [contributor](#term-contributor) grants a license to an open source project for their contributions.
|
||||
long-description: |
|
||||
CLAs help resolve legal disputes involving contributed material and intellectual property (IP).
|
||||
@@ -0,0 +1,12 @@
|
||||
id: cluster-architect
|
||||
name: Cluster Architect
|
||||
related:
|
||||
- cluster
|
||||
- cluster-operator
|
||||
tags:
|
||||
- user-type
|
||||
short-description: |
|
||||
A person who designs infrastructure that involves one or more Kubernetes clusters.
|
||||
|
||||
long-description: |
|
||||
Cluster architects are concerned with best practices for distributed systems, for example: high availability and security.
|
||||
@@ -0,0 +1,16 @@
|
||||
id: cluster-operator
|
||||
name: Cluster Operator
|
||||
aka:
|
||||
- Cluster Administrator
|
||||
related:
|
||||
- cluster
|
||||
- cluster-architect
|
||||
tags:
|
||||
- user-type
|
||||
short-description: |
|
||||
A person who configures, controls, and monitors clusters.
|
||||
|
||||
long-description: |
|
||||
Their primary responsibility is keeping a cluster up and running, which may involve periodic maintenance activities or upgrades.<br>
|
||||
|
||||
**NOTE:** Cluster operators are different from the [Operator pattern](https://coreos.com/operators) that extends the Kubernetes API.
|
||||
@@ -0,0 +1,9 @@
|
||||
id: cluster
|
||||
name: Cluster
|
||||
tags:
|
||||
- fundamental
|
||||
- operation
|
||||
short-description: |
|
||||
A set of machines, called nodes, that run containerized applications managed by Kubernetes.
|
||||
long-description: |
|
||||
A cluster has several worker nodes and at least one master node.
|
||||
@@ -0,0 +1,11 @@
|
||||
id: code-contributor
|
||||
name: Code Contributor
|
||||
aka:
|
||||
- Community Developer
|
||||
tags:
|
||||
- community
|
||||
- user-type
|
||||
short-description: |
|
||||
A person who develops and contributes code to the Kubernetes open source codebase.
|
||||
long-description: |
|
||||
They are also an active [community member](#term-community-member) who participates in one or more [Special Interest Groups (SIGs)](#term-sig).
|
||||
@@ -0,0 +1,9 @@
|
||||
id: container
|
||||
name: Container
|
||||
tags:
|
||||
- fundamental
|
||||
- workload
|
||||
short-description: |
|
||||
A lightweight and portable executable image that contains software and all of its dependencies.
|
||||
long-description: |
|
||||
Containers decouple applications from underlying host infrastructure to make deployment easier in different cloud or OS environments, and for easier scaling.
|
||||
@@ -0,0 +1,8 @@
|
||||
id: contributor
|
||||
name: Contributor
|
||||
tags:
|
||||
- community
|
||||
short-description: |
|
||||
Someone who donates code, documentation, or their time to help the Kubernetes project or community.
|
||||
long-description: |
|
||||
Contributions include pull requests (PRs), issues, feedback, [special interest group (SIG)](#term-sig) participation, or organizing community events.
|
||||
@@ -0,0 +1,9 @@
|
||||
id: cronjob
|
||||
name: CronJob
|
||||
tags:
|
||||
- core-object
|
||||
- workload
|
||||
short-description: |
|
||||
Manages a [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) that runs on a periodic schedule.
|
||||
long-description: |
|
||||
Similar to a line in a *crontab* file, a [CronJob](/docs/concepts/workloads/controllers/cron-jobs/#writing-a-cron-job-spec) object specifies a schedule using the [Cron](https://en.wikipedia.org/wiki/Cron) format.
|
||||
@@ -0,0 +1,10 @@
|
||||
id: deployment
|
||||
name: Deployment
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
- workload
|
||||
short-description: |
|
||||
An API object that manages a replicated application.
|
||||
long-description: |
|
||||
Each replica is represented by a [Pod](#term-pod), and the Pods are distributed among the nodes of a cluster.
|
||||
@@ -0,0 +1,15 @@
|
||||
id: developer
|
||||
name: Developer (disambiguation)
|
||||
aka:
|
||||
- Kubernetes Developer
|
||||
tags:
|
||||
- community
|
||||
- user-type
|
||||
short-description: |
|
||||
May refer to: [*Application Developer*](#term-application-developer), [*Code Contributor*](#term-code-contributor), or [*Platform Developer*](#term-platform-developer).
|
||||
long-description: |
|
||||
This overloaded term may have different meanings depending on the context. It could mean:
|
||||
|
||||
* [**Application Developer**](#term-application-developer): A person who writes an application that runs in a Kubernetes cluster.
|
||||
* [**Code Contributor**](#term-code-contributor): A person who develops and contributes code to the Kubernetes open source codebase.
|
||||
* [**Platform Developer**](#term-platform-developer): A person who customizes the Kubernetes platform to fit the needs of their project—for example, by extending the API.
|
||||
@@ -0,0 +1,11 @@
|
||||
id: downstream
|
||||
name: Downstream (disambiguation)
|
||||
related:
|
||||
- upstream
|
||||
tags:
|
||||
- community
|
||||
short-description: |
|
||||
May refer to: code in the Kubernetes ecosystem that depends upon the core Kubernetes codebase or a forked repo.
|
||||
long-description: |
|
||||
* In the **Kubernetes Community**: Conversations often use *downstream* to mean the ecosystem, code, or third-party tools that rely on the core Kubernetes codebase. For example, a new feature in Kubernetes may be adopted by applications *downstream* to improve their functionality.
|
||||
* In **GitHub** or **git**: The convention is to refer to a forked repo as *downstream*, whereas the source repo is considered *upstream*.
|
||||
@@ -0,0 +1,9 @@
|
||||
id: helm-chart
|
||||
name: Helm Chart
|
||||
tags:
|
||||
- tool
|
||||
short-description: |
|
||||
A package of pre-configured Kubernetes resources that can be managed with the Helm tool.
|
||||
long-description: |
|
||||
Charts provide a reproducible way of creating and sharing Kubernetes applications.
|
||||
A single chart can be used to deploy something simple, like a memcached Pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on.
|
||||
@@ -0,0 +1,10 @@
|
||||
id: ingress
|
||||
name: Ingress
|
||||
tags:
|
||||
- networking
|
||||
- architecture
|
||||
- extension
|
||||
short-description: |
|
||||
An API object that manages external access to the services in a cluster, typically HTTP.
|
||||
long-description: |
|
||||
Ingress can provide load balancing, SSL termination and name-based virtual hosting.
|
||||
@@ -0,0 +1,12 @@
|
||||
id: istio
|
||||
name: Istio
|
||||
tags:
|
||||
- networking
|
||||
- architecture
|
||||
- extension
|
||||
short-description: |
|
||||
An open platform (not Kubernetes-specific) that provides a uniform way to integrate microservices, manage traffic flow, enforce policies, and aggregate telemetry data.
|
||||
long-description: >
|
||||
Adding Istio does not require changing application code.
|
||||
It is a layer of infrastructure between a service and the network, which when combined with service deployments, is commonly referred to as a service mesh.
|
||||
Istio's control plane abstracts away the underlying cluster management platform, which may be Kubernetes, Mesosphere, etc.
|
||||
@@ -0,0 +1,18 @@
|
||||
id: kops
|
||||
name: Kops
|
||||
tags:
|
||||
- tool
|
||||
- operation
|
||||
short-description: |
|
||||
A CLI tool that helps you create, destroy, upgrade and maintain production-grade, highly available, Kubernetes clusters. *NOTE: Officially supports AWS only, with GCE and VMware vSphere in alpha*.
|
||||
long-description: |
|
||||
`kops` provisions your cluster with:
|
||||
|
||||
* Fully automated installation
|
||||
* DNS-based cluster identification
|
||||
* Self-healing: everything runs in Auto-Scaling Groups
|
||||
* Limited OS support (Debian preferred, Ubuntu 16.04 supported, early support for CentOS & RHEL)
|
||||
* High availability (HA) support
|
||||
* The ability to directly provision, or generate terraform manifests
|
||||
|
||||
You can also build your own cluster using [`kubeadm`](#term-kubeadm) as a building block. `kops` builds on the kubeadm work.
|
||||
@@ -0,0 +1,9 @@
|
||||
id: kubeadm
|
||||
name: Kubeadm
|
||||
tags:
|
||||
- tool
|
||||
- operation
|
||||
short-description: |
|
||||
A tool for quickly installing Kubernetes and setting up a secure cluster.
|
||||
long-description: |
|
||||
You can use kubeadm to install both the control plane and the worker node components.
|
||||
@@ -0,0 +1,9 @@
|
||||
id: kubectl
|
||||
name: Kubectl
|
||||
tags:
|
||||
- tool
|
||||
- fundamental
|
||||
short-description: |
|
||||
A command line tool for communicating with a [Kubernetes API](#term-kubernetes-api) server.
|
||||
long-description: |
|
||||
You can use kubectl to create, inspect, update, and delete Kubernetes objects.
|
||||
@@ -0,0 +1,12 @@
|
||||
id: kubernetes-api
|
||||
name: Kubernetes API
|
||||
tags:
|
||||
- fundamental
|
||||
- architecture
|
||||
short-description: |
|
||||
The application that serves Kubernetes functionality through a RESTful interface and stores the state of the cluster.
|
||||
long-description: >
|
||||
Kubernetes resources and "records of intent" are all stored as API objects, and modified via RESTful calls to the API.
|
||||
The API allows configuration to be managed in a declarative way.
|
||||
Users can interact with the Kubernetes API directly, or via tools like `kubectl`.
|
||||
The core Kubernetes API is flexible and can also be extended to support custom resources.
|
||||
@@ -0,0 +1,8 @@
|
||||
id: maintainer
|
||||
name: Maintainer
|
||||
tags:
|
||||
- community
|
||||
short-description: |
|
||||
A highly experienced [contributor](#term-contributor), active in multiple areas of Kubernetes, who has cross-area ownership and write access to a project's GitHub repository.
|
||||
long-description: |
|
||||
Maintainers work holistically across the project to maintain its health and success and have made substantial contributions, both through code development and broader organizational efforts.
|
||||
@@ -0,0 +1,10 @@
|
||||
id: member
|
||||
name: Member
|
||||
tags:
|
||||
- community
|
||||
short-description: |
|
||||
A continuously active [contributor](#term-contributor) in the K8s community.
|
||||
long-description: >
|
||||
Members can have issues and PRs assigned to them and participate in [special interest groups (SIGs)](#term-sig) through GitHub teams.
|
||||
Pre-submit tests are automatically run for members' PRs.
|
||||
A member is expected to remain an active contributor to the community.
|
||||
@@ -0,0 +1,9 @@
|
||||
id: minikube
|
||||
name: Minikube
|
||||
tags:
|
||||
- fundamental
|
||||
- tool
|
||||
short-description: |
|
||||
A tool for running Kubernetes locally.
|
||||
long-description: |
|
||||
Minikube runs a single-node cluster inside a VM on your computer.
|
||||
@@ -0,0 +1,10 @@
|
||||
id: platform-developer
|
||||
name: Platform Developer
|
||||
aka:
|
||||
- Kubernetes Developer
|
||||
tags:
|
||||
- user-type
|
||||
short-description: |
|
||||
A person who customizes the Kubernetes platform to fit the needs of their project.
|
||||
long-description: >
|
||||
A platform developer may, for example, use [Custom Resources](/docs/concepts/api-extension/custom-resources/) or [Extend the Kubernetes API with the aggregation layer](/docs/concepts/api-extension/apiserver-aggregation/) to add functionality to their instance of Kubernetes, specifically for their application.
|
||||
@@ -0,0 +1,16 @@
|
||||
id: pod
|
||||
name: Pod
|
||||
related:
|
||||
- container
|
||||
- sidecar
|
||||
- deployment
|
||||
- statefulset
|
||||
tags:
|
||||
- core-object
|
||||
- fundamental
|
||||
short-description: |
|
||||
The smallest and simplest Kubernetes object. A Pod represents a set of running [containers](#term-container) on your cluster.
|
||||
long-description: >
|
||||
A Pod is typically set up to run a single primary container.
|
||||
It can also run optional sidecar containers that add supplementary features like logging.
|
||||
Pods are commonly managed by a [Deployment](#term-deployment).
|
||||
@@ -0,0 +1,9 @@
|
||||
id: rbac
|
||||
name: RBAC (Role-Based Access Control)
|
||||
tags:
|
||||
- security
|
||||
- fundamental
|
||||
short-description: |
|
||||
Manages authorization decisions, allowing admins to dynamically configure access policies through the [Kubernetes API](#term-kubernetes-api).
|
||||
long-description: |
|
||||
RBAC utilizes *roles*, which contain permission rules, and *role bindings*, which grant the permissions defined in a role to a set of users.
|
||||
@@ -0,0 +1,8 @@
|
||||
id: reviewer
|
||||
name: Reviewer
|
||||
tags:
|
||||
- community
|
||||
short-description: |
|
||||
A person who reviews code for quality and correctness on some part of the project.
|
||||
long-description: |
|
||||
Reviewers are knowledgeable about both the codebase and software engineering principles. Reviewer status is scoped to a part of the codebase.
|
||||
@@ -0,0 +1,9 @@
|
||||
id: service
|
||||
name: Service
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
short-description: |
|
||||
An API object that describes how to access applications, such as a set of [Pods](#term-pod), and can describe ports and load-balancers.
|
||||
long-description: |
|
||||
The access point can be internal or external to the cluster.
|
||||
@@ -0,0 +1,11 @@
|
||||
id: sig
|
||||
name: SIG (special interest group)
|
||||
tags:
|
||||
- community
|
||||
short-description: |
|
||||
[Members](#term-member) who collectively manage an ongoing piece or aspect of the larger Kubernetes open source project.
|
||||
long-description: >
|
||||
Members within a SIG have a shared interest in advancing a specific area, such as architecture, API machinery, or documentation.
|
||||
SIGs must follow the [SIG Governance](https://github.com/kubernetes/community/blob/master/sig-governance.md) guidelines but can have their own contribution policy and channels of communication.
|
||||
|
||||
For more information, see the [kubernetes/community](https://github.com/kubernetes/community) repo and the current list of [SIGs and Working Groups](https://github.com/kubernetes/community/blob/master/sig-list.md).
|
||||
@@ -1,18 +1,18 @@
|
||||
id: statefulset
|
||||
name: StatefulSet
|
||||
formerly:
|
||||
aka:
|
||||
- PetSet
|
||||
related:
|
||||
- Deployment
|
||||
- Pod
|
||||
- deployment
|
||||
- pod
|
||||
tags:
|
||||
- Storage
|
||||
- Workload
|
||||
- API Object
|
||||
- core-object
|
||||
- workload
|
||||
- storage
|
||||
short-description: |
|
||||
Manage the deployment and scaling of a set of Pods, *and provide guarantees about ordering*. They do so by maintaining a *unique*, sticky identity for each of their Pods.
|
||||
Manages the deployment and scaling of a set of [Pods](#term-pod), *and provides guarantees about the ordering and uniqueness* of these Pods.
|
||||
|
||||
long-description: |
|
||||
Like Deployments, StatefulSets manage Pods that are based on an identical container spec. However, although their specs are the same, the Pods in a StatefulSet are not interchangeable. Each Pod has a persistent identifier that it maintains across any rescheduling.
|
||||
Like a [Deployment](#term-deployment), a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.
|
||||
|
||||
StatefulSets also operate according to the Controller pattern. You define your desired state in a StatefulSet *object*, and the StatefulSet *controller* makes any necessary updates to the get there from the current state.
|
||||
A StatefulSet operates under the same pattern as any other Controller. You define your desired state in a StatefulSet *object*, and the StatefulSet *controller* makes any necessary updates to get there from the current state.
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
id: upstream
|
||||
name: Upstream (disambiguation)
|
||||
related:
|
||||
- downstream
|
||||
tags:
|
||||
- community
|
||||
short-description: |
|
||||
May refer to: core Kubernetes or the source repo from which a repo was forked.
|
||||
long-description: |
|
||||
* In the **Kubernetes Community**: Conversations often use *upstream* to mean the core Kubernetes codebase, which the general ecosystem, other code, or third-party tools relies upon. For example, [community members](#term-member) may suggest that a feature is moved upstream so that it is in the core codebase instead of in a plugin or third-party tool.
|
||||
* In **GitHub** or **git**: The convention is to refer to a source repo as *upstream*, whereas the forked repo is considered *downstream*.
|
||||
@@ -0,0 +1,10 @@
|
||||
id: wg
|
||||
name: WG (working group)
|
||||
tags:
|
||||
- community
|
||||
short-description: |
|
||||
Facilitates the discussion and/or implementation of a short-lived, narrow, or decoupled project for a committee, [SIG](#term-sig), or cross-SIG effort.
|
||||
long-description: |
|
||||
Working groups are a way of organizing people to accomplish a discrete task, and are relatively easy to create and deprecate when inactive.
|
||||
|
||||
For more information, see the [kubernetes/community](https://github.com/kubernetes/community) repo and the current list of [SIGs and working groups](https://github.com/kubernetes/community/blob/master/sig-list.md).
|
||||
Reference in New Issue
Block a user