You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/book/src/reference/glossary.md
+75-8Lines changed: 75 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,6 +23,13 @@ The process of turning a server into a Kubernetes node. This may involve assembl
23
23
24
24
A temporary cluster that is used to provision a Target Management cluster.
25
25
26
+
### Bootstrap provider
27
+
28
+
Refers to a [provider](#provider) that implements a solution for the [bootstrap](#bootstrap) process.
29
+
Bootstrap provider's interaction with Cluster API is based on what is defined in the [Cluster API contract](#contract).
30
+
31
+
See [CABPK](#CABPK).
32
+
26
33
# C
27
34
---
28
35
@@ -83,6 +90,12 @@ Cluster API Provider VMware Cloud Director
83
90
### CAPZ
84
91
Cluster API Provider Azure
85
92
93
+
### Cloud provider
94
+
95
+
Or __Cloud service provider__
96
+
97
+
Refers to an information technology (IT) company that provides computing resources (e.g. AWS, Azure, Google, etc.).
98
+
86
99
### Cluster
87
100
88
101
A full Kubernetes deployment. See Management Cluster and Workload Cluster.
@@ -98,23 +111,48 @@ Or __Cluster API project__
98
111
99
112
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.
100
113
114
+
See [core provider](#core-provider)
115
+
101
116
### Cluster API Runtime
102
117
103
118
The Cluster API execution model, a set of controllers cooperating in managing the Kubernetes cluster lifecycle.
104
119
120
+
### Contract
121
+
122
+
Or __Cluster API contract__
123
+
124
+
Defines a set of rules a [provider](#provider) is expected to comply with in order to interact with Cluster API.
125
+
Those rules can be in the form of CustomResourceDefinition (CRD) fields and/or expected behaviors to be implemented.
126
+
105
127
### Control plane
106
128
107
129
The set of Kubernetes services that form the basis of a cluster. See also [https://kubernetes.io/docs/concepts/#kubernetes-control-plane](https://kubernetes.io/docs/concepts/#kubernetes-control-plane) There are two variants:
108
130
109
131
*__Self-provisioned__: A Kubernetes control plane consisting of pods or machines wholly managed by a single Cluster API deployment.
110
-
*__External__: A control plane offered and controlled by some system other than Cluster API (e.g., GKE, AKS, EKS, IKS).
132
+
*__External__ or __Managed__: A control plane offered and controlled by some system other than Cluster API (e.g., GKE, AKS, EKS, IKS).
133
+
134
+
### Control plane provider
135
+
136
+
Refers to a [provider](#provider) that implements a solution for the management of a Kubernetes [control plane][#control-plane].
137
+
Control plane provider's interaction with Cluster API is based on what is defined in the [Cluster API contract](#contract).
138
+
139
+
See [KCP](#KCP).
140
+
141
+
### Core provider
142
+
143
+
Refers to a [provider](#provider) that implements Cluster API core controllers; if you
144
+
consider that the first project that must be deployed in a management Cluster is Cluster API itself, it should be clear why
145
+
the Cluster API project is also referred to as the core provider.
146
+
147
+
See [CAPI](#cluster-api).
111
148
112
149
# D
113
150
---
114
151
115
152
### Default implementation
116
153
117
-
A feature implementation offered as part of the Cluster API project, infrastructure providers can swap it out for a different one.
154
+
A feature implementation offered as part of the Cluster API project and maintained by the CAPI core team; For example
155
+
[KCP](#KCP) is a default implementation for a [control plane provider](#control-plane-provider).
118
156
119
157
# E
120
158
---
@@ -145,7 +183,15 @@ see [Server](#server)
145
183
146
184
### Infrastructure provider
147
185
148
-
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.
186
+
Refers to a [provider](#provider) that implements provisioning of infrastructure/computational resources required by
187
+
the Cluster or by Machines (e.g. VMs, networking, etc.).
188
+
Infrastructure provider's interaction with Cluster API is based on what is defined in the [Cluster API contract](#contract).
189
+
190
+
Clouds infrastructure providers include AWS, Azure, or Google; while VMware, MAAS, or metal3.io can be defined as bare metal providers.
191
+
When there is more than one way to obtain resources from the same infrastructure provider (e.g. EC2 vs. EKS in AWS) each way is referred to as a variant.
192
+
193
+
See e.g. [CAPA][#CAPA], [CAPC][#CAPC], [CAPD][#CAPD], [CAPG][#CAPG], [CAPH][#CAPH], [CAPIBM][#CAPIBM], [CAPN][#CAPN],
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 a running instance of a [Machine](#machine) as being immutable, from a [Cluster API](#cluster-api) perspective.
161
207
208
+
### IPAM provider
209
+
210
+
Refers to a [provider](#provider) that allows Cluster API to interact with IPAM solutions.
211
+
IPAM provider's interaction with Cluster API is based on the `IPAddressClaim` and `IPAddress` API types.
212
+
162
213
# K
163
214
---
164
215
@@ -243,16 +294,27 @@ The pivot process is also used for deleting a management cluster and could also
243
294
244
295
### Provider
245
296
246
-
See [Infrastructure Provider](#infrastructure-provider)
297
+
Or __Cluster API provider__
298
+
299
+
This term was originally used as abbreviation for [Infrastructure provider](#infrastructure-provider), but currently it is used
300
+
to refer to any project that can be deployed and provides functionality to the Cluster API management Cluster.
301
+
302
+
See [Bootstrap provider](#bootstrap-provider), [Control plane provider](#control-plane-provider), [Core provider](#core-provider),
Refers to the YAML artifact a provider publishes as part of their releases which is required to use the provider components,
251
-
it usually contains Custom Resource Definitions (CRDs), Deployments (to run the controller manager), RBAC, etc.
307
+
Refers to the YAML artifact published as part of the release process for [providers](#provider);
308
+
it usually includes Custom Resource Definitions (CRDs), Deployments (to run the controller manager), RBAC, etc.
309
+
310
+
In some cases, the same expression is used to refer to the instances of above components deployed in a management cluster.
252
311
253
-
### Provider implementation
312
+
See [Provider repository](#provider-repository)
254
313
255
-
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.
314
+
### Provider repository
315
+
316
+
Refers to the location where the YAML for [provider components](#provider-components) are hosted; usually a provider repository hosts
317
+
many version of provider components, one for each released version.
256
318
257
319
# R
258
320
---
@@ -263,6 +325,11 @@ An external component which is part of a system built on top of Cluster API that
263
325
264
326
See [Runtime SDK](#runtime-sdk)
265
327
328
+
### Runtime Extension provider
329
+
330
+
Refers to a [provider](#provider) that implements one or more [runtime extensions](#runtime-extension).
331
+
Runtime Extension provider's interaction with Cluster API are based on the Open API spec for [runtime hooks](#runtime-hook).
332
+
266
333
### Runtime Hook
267
334
268
335
A single, well identified, extension point allowing applications built on top of Cluster API to hook into specific moments of the [Cluster API Runtime](#cluster-api-runtime), e.g. [BeforeClusterUpgrade](../tasks/experimental-features/runtime-sdk/implement-lifecycle-hooks.md#beforeclusterupgrade), [TopologyMutationHook](#topology-mutation-hook).
Copy file name to clipboardExpand all lines: docs/book/src/user/concepts.md
+8-5Lines changed: 8 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,21 +4,22 @@
4
4
5
5
## Management cluster
6
6
7
-
A Kubernetes cluster that manages the lifecycle of Workload Clusters. A Management Cluster is also where one or more Infrastructure Providers run, and where resources such as Machines are stored.
7
+
A Kubernetes cluster that manages the lifecycle of Workload Clusters. A Management Cluster is also where one or more providers run, and where resources such as Machines are stored.
8
8
9
9
### Workload cluster
10
10
11
11
A Kubernetes cluster whose lifecycle is managed by a Management Cluster.
12
12
13
13
## Infrastructure provider
14
14
15
-
A source of computational resources, such as compute and networking. For example, cloud Infrastructure Providers include AWS, Azure, and Google, and bare metal Infrastructure Providers include VMware, MAAS, and metal3.io.
15
+
A component responsible for the provisioning of infrastructure/computational resources required by the Cluster or by Machines (e.g. VMs, networking, etc.).
16
+
For example, cloud Infrastructure Providers include AWS, Azure, and Google, and bare metal Infrastructure Providers include VMware, MAAS, and metal3.io.
16
17
17
18
When there is more than one way to obtain resources from the same Infrastructure Provider (such as AWS offering both EC2 and EKS), each way is referred to as a variant.
18
19
19
20
## Bootstrap provider
20
21
21
-
The Bootstrap Provider is responsible for:
22
+
A component responsible for turning a server into a Kubernetes node as well as for:
22
23
23
24
1. Generating the cluster certificates, if not otherwise specified
24
25
1. Initializing the control plane, and gating the creation of other nodes until it is complete
@@ -28,11 +29,13 @@ The Bootstrap Provider is responsible for:
28
29
29
30
The [control plane](https://kubernetes.io/docs/concepts/overview/components/) is a set of components that serve the Kubernetes API and continuously reconcile desired state using [control loops](https://kubernetes.io/docs/concepts/architecture/controller/).
30
31
31
-
*__Machine-based__ control planes are the most common type. Dedicated machines are provisioned, running [static pods](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/) for components such as [kube-apiserver](https://kubernetes.io/docs/admin/kube-apiserver/), [kube-controller-manager](https://kubernetes.io/docs/admin/kube-controller-manager/) and [kube-scheduler](https://kubernetes.io/docs/admin/kube-scheduler/).
32
+
*__Self-provisioned__: A Kubernetes control plane consisting of pods or machines wholly managed by a single Cluster API deployment.
33
+
e.g kubeadm uses [static pods](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/) for running components such as [kube-apiserver](https://kubernetes.io/docs/admin/kube-apiserver/), [kube-controller-manager](https://kubernetes.io/docs/admin/kube-controller-manager/) and [kube-scheduler](https://kubernetes.io/docs/admin/kube-scheduler/)
34
+
on control plane machines.
32
35
33
36
*__Pod-based__ deployments require an external hosting cluster. The control plane components are deployed using standard *Deployment* and *StatefulSet* objects and the API is exposed using a *Service*.
34
37
35
-
*__External__ control planes are offered and controlled by some system other than Cluster API, such as GKE, AKS, EKS, or IKS.
38
+
*__External__ or __Managed__control planes are offered and controlled by some system other than Cluster API, such as GKE, AKS, EKS, or IKS.
36
39
37
40
The default provider uses kubeadm to bootstrap the control plane. As of v1alpha3, it exposes the configuration via the `KubeadmControlPlane` object. The controller, `capi-kubeadm-control-plane-controller-manager`, can then create Machine and BootstrapConfig objects based on the requested replicas in the `KubeadmControlPlane` object.
0 commit comments