Revert "Introduce custom Jekyll tags for better glossary integration" (#6160)
This reverts commit 46d9cbe5ae.
This commit is contained in:
Jessica Yao
committed by
Zach Corleissen
Zach Corleissen
parent
aaffdb8ca4
commit
f3edbd3822
@@ -1,6 +1,5 @@
|
||||
id: _example
|
||||
name: Example K8s Term
|
||||
full-link: kubernetes.io/docs/link-to-long-dedicated-docs-page
|
||||
aka:
|
||||
- Slang K8s Term
|
||||
- Misnomer
|
||||
@@ -11,17 +10,8 @@ related:
|
||||
- id-of-commonly-used-with-term
|
||||
tags:
|
||||
- Some Tag
|
||||
short-description: >
|
||||
Required.
|
||||
Markdown allowed (e.g. for cross-linking).
|
||||
One or two lines that provide a minimum definition.
|
||||
Do not repeat the term.
|
||||
Prefer fragments.
|
||||
End with a period.
|
||||
long-description: >
|
||||
Optional.
|
||||
Markdown allowed.
|
||||
Longer additional text to appear after (in conjunction with) short description.
|
||||
Provide where the short description is not sufficient as the intro paragraph to a topic.
|
||||
Write complete but concise sentences.
|
||||
short-description: |
|
||||
Required. One or two lines that provide a minimum definition. Do not repeat the term. Write about the plural of the term. Prefer fragments. Model after tooltips. End with a period.
|
||||
long-description: |
|
||||
Optional. Longer additional text to appear after (in conjunction with) short description. Provide where the short description is not sufficient as the intro paragraph to a topic. Write complete but concise sentences.
|
||||
**See /_includes/templates/glossary/README.md for the official style guide.**
|
||||
|
||||
@@ -4,7 +4,7 @@ related:
|
||||
- application-developer
|
||||
tags:
|
||||
- user-type
|
||||
short-description: >
|
||||
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.
|
||||
|
||||
@@ -4,7 +4,7 @@ related:
|
||||
- application-architect
|
||||
tags:
|
||||
- user-type
|
||||
short-description: >
|
||||
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.
|
||||
|
||||
@@ -2,7 +2,7 @@ id: approver
|
||||
name: Approver
|
||||
tags:
|
||||
- community
|
||||
short-description: >
|
||||
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.
|
||||
|
||||
@@ -1,9 +1,8 @@
|
||||
id: cla
|
||||
name: CLA (Contributor License Agreement)
|
||||
full-link: https://github.com/kubernetes/community/blob/master/CLA.md
|
||||
tags:
|
||||
- community
|
||||
short-description: >
|
||||
Terms under which a {% glossary_tooltip text="contributor" term_id="contributor" %} grants a license to an open source project for their contributions.
|
||||
long-description: >
|
||||
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).
|
||||
|
||||
@@ -5,7 +5,8 @@ related:
|
||||
- cluster-operator
|
||||
tags:
|
||||
- user-type
|
||||
short-description: >
|
||||
short-description: |
|
||||
A person who designs infrastructure that involves one or more Kubernetes clusters.
|
||||
long-description: >
|
||||
|
||||
long-description: |
|
||||
Cluster architects are concerned with best practices for distributed systems, for example: high availability and security.
|
||||
|
||||
@@ -7,8 +7,9 @@ related:
|
||||
- cluster-architect
|
||||
tags:
|
||||
- user-type
|
||||
short-description: >
|
||||
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>
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ name: Cluster
|
||||
tags:
|
||||
- fundamental
|
||||
- operation
|
||||
short-description: >
|
||||
short-description: |
|
||||
A set of machines, called nodes, that run containerized applications managed by Kubernetes.
|
||||
long-description: >
|
||||
long-description: |
|
||||
A cluster has several worker nodes and at least one master node.
|
||||
|
||||
@@ -5,7 +5,7 @@ aka:
|
||||
tags:
|
||||
- community
|
||||
- user-type
|
||||
short-description: >
|
||||
short-description: |
|
||||
A person who develops and contributes code to the Kubernetes open source codebase.
|
||||
long-description: >
|
||||
They are also an active {% glossary_tooltip text="community member" term_id="member" %} who participates in one or more {% glossary_tooltip text="Special Interest Groups (SIGs)" term_id="sig" %}.
|
||||
long-description: |
|
||||
They are also an active [community member](#term-community-member) who participates in one or more [Special Interest Groups (SIGs)](#term-sig).
|
||||
|
||||
@@ -1,10 +1,9 @@
|
||||
id: container
|
||||
name: Container
|
||||
full-link: /docs/concepts/overview/what-is-kubernetes/#why-containers
|
||||
tags:
|
||||
- fundamental
|
||||
- workload
|
||||
short-description: >
|
||||
short-description: |
|
||||
A lightweight and portable executable image that contains software and all of its dependencies.
|
||||
long-description: >
|
||||
long-description: |
|
||||
Containers decouple applications from underlying host infrastructure to make deployment easier in different cloud or OS environments, and for easier scaling.
|
||||
|
||||
@@ -2,7 +2,7 @@ id: contributor
|
||||
name: Contributor
|
||||
tags:
|
||||
- community
|
||||
short-description: >
|
||||
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, {% glossary_tooltip text="special interest groups (SIG)" term_id="sig" %} participation, or organizing community events.
|
||||
long-description: |
|
||||
Contributions include pull requests (PRs), issues, feedback, [special interest group (SIG)](#term-sig) participation, or organizing community events.
|
||||
|
||||
@@ -1,10 +1,9 @@
|
||||
id: cronjob
|
||||
name: CronJob
|
||||
full-link: /docs/concepts/workloads/controllers/cron-jobs/
|
||||
tags:
|
||||
- core-object
|
||||
- workload
|
||||
short-description: >
|
||||
Manages a [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) that runs on a periodic schedule.
|
||||
long-description: >
|
||||
Similar to a line in a *crontab* file, a Cronjob object specifies a schedule using the [Cron](https://en.wikipedia.org/wiki/Cron) format.
|
||||
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.
|
||||
|
||||
@@ -1,11 +1,10 @@
|
||||
id: deployment
|
||||
name: Deployment
|
||||
full-link: /docs/concepts/workloads/controllers/deployment/
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
- workload
|
||||
short-description: >
|
||||
short-description: |
|
||||
An API object that manages a replicated application.
|
||||
long-description: >
|
||||
Each replica is represented by a {% glossary_tooltip term_id="pod" %}, and the Pods are distributed among the nodes of a cluster.
|
||||
long-description: |
|
||||
Each replica is represented by a [Pod](#term-pod), and the Pods are distributed among the nodes of a cluster.
|
||||
|
||||
@@ -5,7 +5,11 @@ aka:
|
||||
tags:
|
||||
- community
|
||||
- user-type
|
||||
short-description: >
|
||||
May refer to: {% glossary_tooltip text="Application Developer" term_id="application-developer" %}, {% glossary_tooltip text="Code Contributor" term_id="code-contributor" %}, or {% glossary_tooltip text="Platform Developer" term_id="platform-developer" %}.
|
||||
long-description: >
|
||||
This overloaded term may have different meanings depending on the context
|
||||
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.
|
||||
|
||||
@@ -4,7 +4,7 @@ related:
|
||||
- upstream
|
||||
tags:
|
||||
- community
|
||||
short-description: >
|
||||
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.
|
||||
|
||||
@@ -1,9 +1,8 @@
|
||||
id: helm-chart
|
||||
name: Helm Chart
|
||||
full-link: https://github.com/kubernetes/helm/blob/master/docs/charts.md
|
||||
tags:
|
||||
- tool
|
||||
short-description: >
|
||||
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.
|
||||
|
||||
@@ -1,13 +1,10 @@
|
||||
id: ingress
|
||||
name: Ingress
|
||||
full-link: /docs/concepts/services-networking/ingress/
|
||||
aka:
|
||||
- Ingress controller
|
||||
tags:
|
||||
- networking
|
||||
- architecture
|
||||
- extension
|
||||
short-description: >
|
||||
short-description: |
|
||||
An API object that manages external access to the services in a cluster, typically HTTP.
|
||||
long-description: >
|
||||
long-description: |
|
||||
Ingress can provide load balancing, SSL termination and name-based virtual hosting.
|
||||
|
||||
@@ -1,11 +1,10 @@
|
||||
id: istio
|
||||
name: Istio
|
||||
full-link: https://istio.io/docs/concepts/what-is-istio/overview.html
|
||||
tags:
|
||||
- networking
|
||||
- architecture
|
||||
- extension
|
||||
short-description: >
|
||||
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.
|
||||
|
||||
@@ -1,10 +1,9 @@
|
||||
id: kops
|
||||
name: Kops
|
||||
full-link: /docs/getting-started-guides/kops/
|
||||
tags:
|
||||
- tool
|
||||
- operation
|
||||
short-description: >
|
||||
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:
|
||||
@@ -16,4 +15,4 @@ long-description: |
|
||||
* High availability (HA) support
|
||||
* The ability to directly provision, or generate terraform manifests
|
||||
|
||||
You can also build your own cluster using {% glossary_tooltip term_id="kubeadm" %} as a building block. `kops` builds on the kubeadm work.
|
||||
You can also build your own cluster using [`kubeadm`](#term-kubeadm) as a building block. `kops` builds on the kubeadm work.
|
||||
|
||||
@@ -1,10 +1,9 @@
|
||||
id: kubeadm
|
||||
name: Kubeadm
|
||||
full-link: /docs/admin/kubeadm/
|
||||
tags:
|
||||
- tool
|
||||
- operation
|
||||
short-description: >
|
||||
short-description: |
|
||||
A tool for quickly installing Kubernetes and setting up a secure cluster.
|
||||
long-description: >
|
||||
long-description: |
|
||||
You can use kubeadm to install both the control plane and the worker node components.
|
||||
|
||||
@@ -1,10 +1,9 @@
|
||||
id: kubectl
|
||||
name: Kubectl
|
||||
full-link: /docs/user-guide/kubectl-overview/
|
||||
tags:
|
||||
- tool
|
||||
- fundamental
|
||||
short-description: >
|
||||
A command line tool for communicating with a {% glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" %} server.
|
||||
long-description: >
|
||||
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.
|
||||
|
||||
@@ -1,10 +1,9 @@
|
||||
id: kubernetes-api
|
||||
name: Kubernetes API
|
||||
full-link: /docs/concepts/overview/kubernetes-api/
|
||||
tags:
|
||||
- fundamental
|
||||
- architecture
|
||||
short-description: >
|
||||
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.
|
||||
|
||||
@@ -2,7 +2,7 @@ id: maintainer
|
||||
name: Maintainer
|
||||
tags:
|
||||
- community
|
||||
short-description: >
|
||||
A highly experienced {% glossary_tooltip text="contributor" term_id="contributor" %}, active in multiple areas of Kubernetes, who has cross-area ownership and write access to a project's GitHub repository.
|
||||
long-description: >
|
||||
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.
|
||||
|
||||
@@ -2,9 +2,9 @@ id: member
|
||||
name: Member
|
||||
tags:
|
||||
- community
|
||||
short-description: >
|
||||
A continuously active {% glossary_tooltip text="contributor" term_id="contributor" %} in the K8s 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 {% glossary_tooltip text="special interest groups (SIGs)" term_id="sig" %} through GitHub teams.
|
||||
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.
|
||||
|
||||
@@ -1,10 +1,9 @@
|
||||
id: minikube
|
||||
name: Minikube
|
||||
full-link: /docs/getting-started-guides/minikube/
|
||||
tags:
|
||||
- fundamental
|
||||
- tool
|
||||
short-description: >
|
||||
short-description: |
|
||||
A tool for running Kubernetes locally.
|
||||
long-description: >
|
||||
long-description: |
|
||||
Minikube runs a single-node cluster inside a VM on your computer.
|
||||
|
||||
@@ -4,7 +4,7 @@ aka:
|
||||
- Kubernetes Developer
|
||||
tags:
|
||||
- user-type
|
||||
short-description: >
|
||||
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.
|
||||
|
||||
@@ -1,6 +1,5 @@
|
||||
id: pod
|
||||
name: Pod
|
||||
full-link: /docs/concepts/workloads/pods/pod-overview/
|
||||
related:
|
||||
- container
|
||||
- sidecar
|
||||
@@ -9,9 +8,9 @@ related:
|
||||
tags:
|
||||
- core-object
|
||||
- fundamental
|
||||
short-description: >
|
||||
The smallest and simplest Kubernetes object. A Pod represents a set of running {% glossary_tooltip text="containers" term_id="container" %} on your cluster.
|
||||
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 {% glossary_tooltip term_id="deployment" %}.
|
||||
Pods are commonly managed by a [Deployment](#term-deployment).
|
||||
|
||||
@@ -1,10 +1,9 @@
|
||||
id: rbac
|
||||
name: RBAC (Role-Based Access Control)
|
||||
full-link: /docs/admin/authorization/rbac/
|
||||
tags:
|
||||
- security
|
||||
- fundamental
|
||||
short-description: >
|
||||
Manages authorization decisions, allowing admins to dynamically configure access policies through the {% glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" %}.
|
||||
long-description: >
|
||||
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.
|
||||
|
||||
@@ -2,7 +2,7 @@ id: reviewer
|
||||
name: Reviewer
|
||||
tags:
|
||||
- community
|
||||
short-description: >
|
||||
short-description: |
|
||||
A person who reviews code for quality and correctness on some part of the project.
|
||||
long-description: >
|
||||
long-description: |
|
||||
Reviewers are knowledgeable about both the codebase and software engineering principles. Reviewer status is scoped to a part of the codebase.
|
||||
|
||||
@@ -1,10 +1,9 @@
|
||||
id: service
|
||||
name: Service
|
||||
full-link: /docs/concepts/services-networking/service/
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
short-description: >
|
||||
An API object that describes how to access applications, such as a set of {% glossary_tooltip text="Pods" term_id="pod" %}, and can describe ports and load-balancers.
|
||||
long-description: >
|
||||
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.
|
||||
|
||||
@@ -1,11 +1,10 @@
|
||||
id: sig
|
||||
name: SIG (special interest group)
|
||||
full-link: https://github.com/kubernetes/community/blob/master/sig-list.md#master-sig-list
|
||||
tags:
|
||||
- community
|
||||
short-description: >
|
||||
{% glossary_tooltip text="Community members" term_id="member" %} who collectively manage an ongoing piece or aspect of the larger Kubernetes open source project.
|
||||
long-description: |
|
||||
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.
|
||||
|
||||
|
||||
@@ -1,6 +1,5 @@
|
||||
id: statefulset
|
||||
name: StatefulSet
|
||||
full-link: /docs/concepts/workloads/controllers/statefulset/
|
||||
aka:
|
||||
- PetSet
|
||||
related:
|
||||
@@ -10,9 +9,10 @@ tags:
|
||||
- core-object
|
||||
- workload
|
||||
- storage
|
||||
short-description: >
|
||||
Manages the deployment and scaling of a set of {% glossary_tooltip text="Pods" term_id="pod" %}, *and provides guarantees about the ordering and uniqueness* of these Pods.
|
||||
short-description: |
|
||||
Manages the deployment and scaling of a set of [Pods](/docs/concepts/workloads/pods/pod), *and provides guarantees about the ordering and uniqueness* of these Pods.
|
||||
|
||||
long-description: |
|
||||
Like a {% glossary_tooltip term_id="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.
|
||||
Like a [Deployment](/docs/concepts/workloads/controllers/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.
|
||||
|
||||
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.
|
||||
|
||||
@@ -4,7 +4,7 @@ related:
|
||||
- downstream
|
||||
tags:
|
||||
- community
|
||||
short-description: >
|
||||
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.
|
||||
|
||||
@@ -1,10 +1,9 @@
|
||||
id: wg
|
||||
name: WG (working group)
|
||||
full-link: https://github.com/kubernetes/community/blob/master/sig-list.md#master-working-group-list
|
||||
tags:
|
||||
- community
|
||||
short-description: >
|
||||
Facilitates the discussion and/or implementation of a short-lived, narrow, or decoupled project for a committee, {% glossary_tooltip text="SIG" term_id="sig" %}, or cross-SIG effort.
|
||||
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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user