Skip to content

docs: add new Calico variables #160

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 19, 2023
Merged

docs: add new Calico variables #160

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 34 additions & 2 deletions docs/content/calico-cni.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,11 +6,43 @@ When deploying a cluster with CAPI, deployment and configuration of CNI is up to
lifecycle hooks, this handler deploys Calico CNI on the new cluster via `ClusterResourceSets` at the
`AfterControlPlaneInitialized` phase.

Deployment of Calico is opt-in La cluster must be labelled with `capiext.labs.d2iq.io/cni=calico` for the lifecycle hook
to perform any actions. The hook creates two `ClusterResourceSets`: one to deploy the Tigera Operator, and one to deploy
Deployment of Calico is opt-in using the following configuration for the lifecycle hook to perform any actions.
The hook creates two `ClusterResourceSets`: one to deploy the Tigera Operator, and one to deploy
Calico via the Tigera `Installation` CRD. The Tigera Operator CRS is shared between all clusters in the operator,
whereas the Calico installation CRS is unique per cluster.

To enable the meta handler enable the `clusterconfigvars` and `clusterconfigpatch`
external patches on `ClusterClass`.

```yaml
apiVersion: cluster.x-k8s.io/v1beta1
kind: ClusterClass
metadata:
name: <NAME>
spec:
patches:
- name: cluster-config
external:
generateExtension: "clusterconfigpatch.capi-runtime-extensions"
discoverVariablesExtension: "clusterconfigvars.capi-runtime-extensions"
```

On the cluster resource then specify this `cni` value:

```yaml
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
name: <NAME>
spec:
topology:
variables:
- name: clusterConfig
value:
cni:
provider: calico
```

As ClusterResourceSets must exist in the same name as the cluster they apply to, the lifecycle hook copies default
ConfigMaps from the same namespace as the CAPI runtime extensions hook pod is running in. This enables users to
configure defaults specific for their environment rather than compiling the defaults into the binary.
Expand Down
9 changes: 4 additions & 5 deletions docs/content/cluster-config.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ ClusterClasses, allowing for a single configuration variable with nested values.
with the least configuration. The included patches are usable individually, but require declaring all the individual
patch and variable handlers in the ClusterClass.

To enable the API server certificate SANs enable the `clusterconfigvars` and `clusterconfigpatch`
To enable the meta handler enable the `clusterconfigvars` and `clusterconfigpatch`
external patches on `ClusterClass`.

```yaml
Expand All @@ -23,7 +23,7 @@ spec:
discoverVariablesExtension: "clusterconfigvars.capi-runtime-extensions"
```

On the cluster resource then specify desired certificate SANs values:
On the cluster resource then specify desired values:

```yaml
apiVersion: cluster.x-k8s.io/v1beta1
Expand All @@ -49,7 +49,6 @@ spec:
additionalNo:
- no-proxy-1.example.com
- no-proxy-2.example.com
cni:
provider: calico
```

Applying this configuration will result in the certificate SANs being correctly set in the
`KubeadmControlPlaneTemplate`.