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
@@ -86,6 +93,12 @@ Cluster API Provider VMware Cloud Director
86
93
### CAPZ
87
94
Cluster API Provider Azure
88
95
96
+
### Cloud provider
97
+
98
+
Or __Cloud service provider__
99
+
100
+
Refers to an information technology (IT) company that provides computing resources (e.g. AWS, Azure, Google, etc.).
101
+
89
102
### Cluster
90
103
91
104
A full Kubernetes deployment. See Management Cluster and Workload Cluster.
@@ -101,23 +114,48 @@ Or __Cluster API project__
101
114
102
115
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.
103
116
117
+
See [core provider](#core-provider)
118
+
104
119
### Cluster API Runtime
105
120
106
121
The Cluster API execution model, a set of controllers cooperating in managing the Kubernetes cluster lifecycle.
107
122
123
+
### Contract
124
+
125
+
Or __Cluster API contract__
126
+
127
+
Defines a set of rules a [provider](#provider) is expected to comply with in order to interact with Cluster API.
128
+
Those rules can be in the form of CustomResourceDefinition (CRD) fields and/or expected behaviors to be implemented.
129
+
108
130
### Control plane
109
131
110
132
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:
111
133
112
134
*__Self-provisioned__: A Kubernetes control plane consisting of pods or machines wholly managed by a single Cluster API deployment.
113
-
*__External__: A control plane offered and controlled by some system other than Cluster API (e.g., GKE, AKS, EKS, IKS).
135
+
*__External__ or __Managed__: A control plane offered and controlled by some system other than Cluster API (e.g., GKE, AKS, EKS, IKS).
136
+
137
+
### Control plane provider
138
+
139
+
Refers to a [provider](#provider) that implements a solution for the management of a Kubernetes [control plane][#control-plane].
140
+
Control plane provider's interaction with Cluster API is based on what is defined in the [Cluster API contract](#contract).
141
+
142
+
See [KCP](#KCP).
143
+
144
+
### Core provider
145
+
146
+
Refers to a [provider](#provider) that implements Cluster API core controllers; if you
147
+
consider that the first project that must be deployed in a management Cluster is Cluster API itself, it should be clear why
148
+
the Cluster API project is also referred to as the core provider.
149
+
150
+
See [CAPI](#cluster-api).
114
151
115
152
# D
116
153
---
117
154
118
155
### Default implementation
119
156
120
-
A feature implementation offered as part of the Cluster API project, infrastructure providers can swap it out for a different one.
157
+
A feature implementation offered as part of the Cluster API project and maintained by the CAPI core team; For example
158
+
[KCP](#KCP) is a default implementation for a [control plane provider](#control-plane-provider).
121
159
122
160
# E
123
161
---
@@ -148,7 +186,15 @@ see [Server](#server)
148
186
149
187
### Infrastructure provider
150
188
151
-
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.
189
+
Refers to a [provider](#provider) that implements provisioning of infrastructure/computational resources required by
190
+
the Cluster or by Machines (e.g. VMs, networking, etc.).
191
+
Infrastructure provider's interaction with Cluster API is based on what is defined in the [Cluster API contract](#contract).
192
+
193
+
Clouds infrastructure providers include AWS, Azure, or Google; while VMware, MAAS, or metal3.io can be defined as bare metal providers.
194
+
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.
195
+
196
+
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.
164
210
211
+
### IPAM provider
212
+
213
+
Refers to a [provider](#provider) that allows Cluster API to interact with IPAM solutions.
214
+
IPAM provider's interaction with Cluster API is based on the `IPAddressClaim` and `IPAddress` API types.
215
+
165
216
# K
166
217
---
167
218
@@ -246,16 +297,27 @@ The pivot process is also used for deleting a management cluster and could also
246
297
247
298
### Provider
248
299
249
-
See [Infrastructure Provider](#infrastructure-provider)
300
+
Or __Cluster API provider__
301
+
302
+
This term was originally used as abbreviation for [Infrastructure provider](#infrastructure-provider), but currently it is used
303
+
to refer to any project that can be deployed and provides functionality to the Cluster API management Cluster.
304
+
305
+
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,
254
-
it usually contains Custom Resource Definitions (CRDs), Deployments (to run the controller manager), RBAC, etc.
310
+
Refers to the YAML artifact published as part of the release process for [providers](#provider);
311
+
it usually includes Custom Resource Definitions (CRDs), Deployments (to run the controller manager), RBAC, etc.
312
+
313
+
In some cases, the same expression is used to refer to the instances of above components deployed in a management cluster.
255
314
256
-
### Provider implementation
315
+
See [Provider repository](#provider-repository)
257
316
258
-
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.
317
+
### Provider repository
318
+
319
+
Refers to the location where the YAML for [provider components](#provider-components) are hosted; usually a provider repository hosts
320
+
many version of provider components, one for each released version.
259
321
260
322
# R
261
323
---
@@ -266,6 +328,11 @@ An external component which is part of a system built on top of Cluster API that
266
328
267
329
See [Runtime SDK](#runtime-sdk)
268
330
331
+
### Runtime Extension provider
332
+
333
+
Refers to a [provider](#provider) that implements one or more [runtime extensions](#runtime-extension).
334
+
Runtime Extension provider's interaction with Cluster API are based on the Open API spec for [runtime hooks](#runtime-hook).
335
+
269
336
### Runtime Hook
270
337
271
338
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