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
1. Add the cluster-api-operator plugin index to krew:
14
-
```bash
15
-
kubectl krew index add operator https://github.com/kubernetes-sigs/cluster-api-operator.git
16
-
```
17
-
18
-
2. Install the cluster-api-operator plugin:
19
-
```bash
20
-
kubectl krew install operator/clusterctl-operator
21
-
```
22
-
23
-
3. Verify the installation:
24
-
```bash
25
-
kubectl operator
26
-
```
27
-
28
-
This should print help information for the kubectl operator plugin.
29
-
30
-
The `cluster-api-operator` plugin is now installed and ready to use with `kubectl`.
31
-
32
-
### Optionally: installing as a `clusterctl` plugin
33
-
Typically the plugin is installed under `~/.krew/bin/kubectl-operator`, which would be present under your `$PATH` after correct `krew` installation. If you want to use plugin with `clusterctl`, you need to rename this file to be prefixed with `clusterctl-` instead, like so:
@@ -4,18 +4,20 @@ To install Cluster API providers in an air-gapped environment using the operator
4
4
5
5
1. Configure the operator for an air-gapped environment:
6
6
- Manually fetch and store a helm chart for the operator.
7
-
- Provide image overrides for the operator in from an accessible image repository.
7
+
- Provide image overrides for the operator from an accessible image repository.
8
8
2. Configure providers for an air-gapped environment:
9
-
- Provide fetch configuration for each provider from an accessible location (e.g., an internal GitHub repository) or from pre-created ConfigMaps within the cluster.
9
+
- Provide fetch configuration for each provider from an accessible location: e.g., an OCI artifact, internal Github/Gitlab repository URL or from pre-created ConfigMaps within the cluster.
10
10
- Provide image overrides for each provider to pull images from an accessible image repository.
11
11
12
12
**Example Usage:**
13
13
14
14
As an admin, I need to fetch the Azure provider components from within the cluster because I am working in an air-gapped environment.
15
15
16
+
### Using ConfigMap
17
+
16
18
In this example, there is a ConfigMap in the `capz-system` namespace that defines the components and metadata of the provider.
17
19
18
-
The Azure InfrastructureProvider is configured with a `fetchConfig` specifying the label selector, allowing the operator to determine the available versions of the Azure provider. Since the provider's version is marked as `v1.9.3`, the operator uses the components information from the ConfigMap with matching label to install the Azure provider.
20
+
The Azure InfrastructureProvider is configured with a `fetchConfig` specifying the label selector, allowing the operator to determine the available versions of the Azure provider. Since the provider's version is marked as `v1.9.3`, the operator uses the components information from the ConfigMap with a matching label to install the Azure provider.
19
21
20
22
```yaml
21
23
---
@@ -47,39 +49,145 @@ spec:
47
49
provider-components: azure
48
50
```
49
51
50
-
### Situation when manifests do not fit into configmap
52
+
### Using OCI Artifact
53
+
54
+
OCI artifact files can follow these naming patterns:
Versioned files allow to use single image for hosting multiple provider manifests and versions simultaneously, without overlapping each other.
71
+
72
+
Typed allow to store multiple provider types inside single image, which is needed for example for `bootstrap` and `control-plane` providers.
73
+
74
+
Example layout for a `kubeadm` provider may look like:
75
+
- `metadata.yaml`
76
+
- `control-plane-components.yaml`
77
+
- `bootstrap-components.yaml`
78
+
79
+
To fetch provider components which are stored as an OCI artifact, you can configure `fetchConfig.oci` field to pull them directly from an OCI registry:
To securely authenticate with an OCI registry, environment variables are used for user credentials. The following environment variables are involved:
98
+
99
+
- **`OCI_USERNAME`**: The username for the OCI registry.
100
+
- **`OCI_PASSWORD`**: The password associated with the username.
101
+
- **`OCI_ACCESS_TOKEN`**: A token used for authentication.
102
+
- **`OCI_REFRESH_TOKEN`**: A refresh token to obtain new access tokens.
103
+
104
+
### Fetching Provider Components from a secure OCI Registry
105
+
106
+
To fetch provider components stored as an OCI artifact, you can configure the `fetchConfig.oci` field to pull them directly from an OCI registry. The `configSecret` field references a Kubernetes `Secret` that should contain the necessary OCI credentials (such as username and password, or token), ensuring that sensitive information is securely stored.
107
+
108
+
Here’s an example of how to configure the `InfrastructureProvider` resource to fetch a specific version of a provider component from an OCI registry:
109
+
110
+
```yaml
111
+
apiVersion: operator.cluster.x-k8s.io/v1alpha2
112
+
kind: InfrastructureProvider
113
+
metadata:
114
+
name: azure
115
+
namespace: capz-system
116
+
spec:
117
+
version: v1.9.3
118
+
configSecret:
119
+
name: azure-variables # Secret containing the OCI registry credentials
120
+
fetchConfig:
121
+
oci: "my-oci-registry.example.com/my-provider:v1.9.3" # Reference to the OCI artifact (provider)
122
+
```
123
+
124
+
The reference secret can could contain OCI authentication data:
125
+
126
+
```yaml
127
+
apiVersion: v1
128
+
kind: Secret
129
+
metadata:
130
+
name: azure-variables # Name of the secret referenced in the InfrastructureProvider
131
+
namespace: capz-system # Namespace where the secret resides
132
+
type: Opaque
133
+
data:
134
+
OCI_USERNAME: <secret>
135
+
OCI_PASSWORD: <secret>
136
+
OCI_ACCESS_TOKEN: <secret>
137
+
OCI_REFRESH_TOKEN: <secret>
138
+
```
139
+
140
+
### Using Github/Gitlab URL
141
+
142
+
If the provider components are hosted at a specific repository URL, you can use `fetchConfig.url` to retrieve them directly.
## Situation when manifests do not fit into ConfigMap
51
159
52
-
There is a limit on the [maximum size](https://kubernetes.io/docs/concepts/configuration/configmap/#motivation) of a configmap - 1MiB. If the manifests do not fit into this size, Kubernetes will generate an error and provider installation fail. To avoid this, you can archive the manifests and put them in the configmap that way.
160
+
There is a limit on the [maximum size](https://kubernetes.io/docs/concepts/configuration/configmap/#motivation) of a ConfigMap - 1MiB. If the manifests do not fit into this size, Kubernetes will generate an error and provider installation will fail. To avoid this, you can archive the manifests and put them in the ConfigMap that way.
53
161
54
-
For example, you have two files: `components.yaml` and `metadata.yaml`. To create a working config map you need:
162
+
For example, you have two files: `components.yaml`and `metadata.yaml`. To create a working ConfigMap, you need:
55
163
56
-
1. Archive components.yaml using `gzip` cli tool
164
+
1. Archive components.yaml using `gzip` CLI tool:
57
165
58
166
```sh
59
167
gzip -c components.yaml > components.gz
60
168
```
61
169
62
-
2. Create a configmap manifest from the archived data
170
+
2. Create a ConfigMap manifest from the archived data:
1. Add the cluster-api-operator plugin index to krew:
14
+
```bash
15
+
kubectl krew index add operator https://github.com/kubernetes-sigs/cluster-api-operator.git
16
+
```
17
+
18
+
2. Install the cluster-api-operator plugin:
19
+
```bash
20
+
kubectl krew install operator/clusterctl-operator
21
+
```
22
+
23
+
3. Verify the installation:
24
+
```bash
25
+
kubectl operator
26
+
```
27
+
28
+
This should print help information for the kubectl operator plugin.
29
+
30
+
The `cluster-api-operator` plugin is now installed and ready to use with `kubectl`.
31
+
32
+
### Optionally: installing as a `clusterctl` plugin
33
+
Typically the plugin is installed under `~/.krew/bin/kubectl-operator`, which would be present under your `$PATH` after correct `krew` installation. If you want to use plugin with `clusterctl`, you need to rename this file to be prefixed with `clusterctl-` instead, like so:
# Using the `preload` Plugin for Kubernetes Operator
2
+
3
+
## Overview
4
+
5
+
The `preload` subcommand allows users to preload provider `ConfigMaps` into a management cluster from an OCI (Open Container Initiative) artifact, known provider source, or URL override. Users can supply any number of provider stings or discover and use existing provider manifests from the cluster.
6
+
7
+
## Command Syntax
8
+
The basic syntax for using the `preload` command is:
9
+
10
+
```sh
11
+
kubectl operator preload [flags]
12
+
```
13
+
14
+
## Flags and Options
15
+
| Flag | Short | Description |
16
+
|------|-------|-------------|
17
+
|`--kubeconfig`|| Path to the kubeconfig file for the source management cluster. Uses default discovery rules if unspecified. |
18
+
|`--existing`|`-e`| Discover all providers in the cluster and prepare `ConfigMap` for each of them. |
19
+
|`--core`|| Specifies the core provider and version (e.g., `cluster-api:v1.1.5`). Defaults to the latest release. |
20
+
|`--infrastructure`|`-i`| Specifies infrastructure providers and versions (e.g., `aws:v0.5.0`). |
21
+
|`--bootstrap`|`-b`| Specifies bootstrap providers and versions (e.g., `kubeadm:v1.1.5`). |
22
+
|`--control-plane`|`-c`| Specifies control plane providers and versions (e.g., `kubeadm:v1.1.5`). |
23
+
|`--ipam`|| Specifies IPAM providers and versions (e.g., `infoblox:v0.0.1`). |
24
+
|`--runtime-extension`|| Specifies runtime extension providers and versions (e.g., `my-extension:v0.0.1`). |
25
+
|`--addon`|| Specifies add-on providers and versions (e.g., `helm:v0.1.0`). |
26
+
|`--target-namespace`|`-n`| Specifies the target namespace where the operator should be deployed. Defaults to `capi-operator-system`. |
27
+
|`--artifact-url`|`-u`| Specifies the URL of the OCI artifact containing component manifests. |
28
+
29
+
## Examples
30
+
31
+
### Load CAPI Operator Manifests from an OCI Source
32
+
```sh
33
+
kubectl operator preload --core cluster-api
34
+
```
35
+
This command loads the `cluster-api` core provider manifests into the management cluster. If no version is specified, the latest release is used.
36
+
37
+
### Load CAPI Operator Manifests from Existing Providers in the Cluster
38
+
```sh
39
+
kubectl operator preload -e
40
+
```
41
+
This command discovers all existing providers in the cluster and prepares ConfigMaps containing their manifests.
42
+
43
+
### Prepare Provider ConfigMap from OCI for a Specific Infrastructure Provider
0 commit comments