|
| 1 | +# Cluster API bootstrap provider MicroK8s |
| 2 | +## What is the Cluster API bootstrap provider MicroK8s? |
| 3 | + |
| 4 | +Cluster API bootstrap provider MicroK8s (CABPM) is a component responsible for generating a cloud-init script to turn a Machine into a Kubernetes Node. This implementation uses [MicroK8s](https://github.com/canonical/microk8s) for Kubernetes bootstrap. |
| 5 | + |
| 6 | +### Resources |
| 7 | + |
| 8 | +* [CABPM Repository](https://github.com/canonical/cluster-api-bootstrap-provider-microk8s) |
| 9 | +* [Official MicroK8s site](https://microk8s.io) |
| 10 | + |
| 11 | +## CABPM configuration options |
| 12 | + |
| 13 | +MicroK8s defines a `MicroK8sControlPlane` definition as well as the `MachineDeployment` to configure the control plane and worker nodes respectively. The `MicroK8sControlPlane` is linked in the cluster definition as shown in the following example: |
| 14 | + |
| 15 | +```yaml |
| 16 | +apiVersion: cluster.x-k8s.io/v1beta1 |
| 17 | +kind: Cluster |
| 18 | +spec: |
| 19 | + controlPlaneRef: |
| 20 | + apiVersion: controlplane.cluster.x-k8s.io/v1beta1 |
| 21 | + kind: MicroK8sControlPlane |
| 22 | + name: capi-aws-control-plane |
| 23 | +``` |
| 24 | +
|
| 25 | +A control plane manifest section includes the Kubernetes version, the replica number as well as the `MicroK8sConfig`: |
| 26 | + |
| 27 | +```yaml |
| 28 | +apiVersion: controlplane.cluster.x-k8s.io/v1beta1 |
| 29 | +kind: MicroK8sControlPlane |
| 30 | +spec: |
| 31 | + controlPlaneConfig: |
| 32 | + initConfiguration: |
| 33 | + addons: |
| 34 | + - dns |
| 35 | + - ingress |
| 36 | + replicas: 3 |
| 37 | + version: v1.23.0 |
| 38 | + ...... |
| 39 | +``` |
| 40 | + |
| 41 | +The worker nodes are configured through the `MachineDeployment` object: |
| 42 | + |
| 43 | +```yaml |
| 44 | +apiVersion: cluster.x-k8s.io/v1beta1 |
| 45 | +kind: MachineDeployment |
| 46 | +metadata: |
| 47 | + name: capi-aws-md-0 |
| 48 | + namespace: default |
| 49 | +spec: |
| 50 | + clusterName: capi-aws |
| 51 | + replicas: 2 |
| 52 | + selector: |
| 53 | + matchLabels: null |
| 54 | + template: |
| 55 | + spec: |
| 56 | + clusterName: capi-aws |
| 57 | + version: v1.23.0 |
| 58 | + bootstrap: |
| 59 | + configRef: |
| 60 | + apiVersion: bootstrap.cluster.x-k8s.io/v1beta1 |
| 61 | + kind: MicroK8sConfigTemplate |
| 62 | + name: capi-aws-md-0 |
| 63 | +...... |
| 64 | +--- |
| 65 | +apiVersion: bootstrap.cluster.x-k8s.io/v1beta1 |
| 66 | +kind: MicroK8sConfigTemplate |
| 67 | +metadata: |
| 68 | + name: capi-aws-md-0 |
| 69 | + namespace: default |
| 70 | +spec: |
| 71 | + template: |
| 72 | + spec: {} |
| 73 | +``` |
| 74 | + |
| 75 | +In both the `MicroK8sControlPlane` and `MicroK8sConfigTemplate` you can set a `MicroK8sConfig` object. In the `MicroK8sControlPlane` case `MicroK8sConfig` is under `MicroK8sConfig.spec.controlPlaneConfig` whereas in `MicroK8sConfigTemplate` it is under `MicroK8sConfigTemplate.spec.template.spec`. |
| 76 | + |
| 77 | +Some of the configuration options available via `MicroK8sConfig` are: |
| 78 | + |
| 79 | + * `MicroK8sConfig.spec.initConfiguration.joinTokenTTLInSecs`: the time-to-live (TTL) of the token used to join nodes, defaults to 10 years. |
| 80 | + * `MicroK8sConfig.spec.initConfiguration.httpsProxy`: the https proxy to be used, defaults to none. |
| 81 | + * `MicroK8sConfig.spec.initConfiguration.httpProxy`: the http proxy to be used, defaults to none. |
| 82 | + * `MicroK8sConfig.spec.initConfiguration.noProxy`: the no-proxy to be used, defaults to none. |
| 83 | + * `MicroK8sConfig.spec.initConfiguration.addons`: the list of addons to be enabled, defaults to dns. |
| 84 | + * `MicroK8sConfig.spec.clusterConfiguration.portCompatibilityRemap`: option to reuse the security group ports set for kubeadm, defaults to true. |
| 85 | + |
| 86 | +### How does CABPM work? |
| 87 | + |
| 88 | +The main purpose of the MicroK8s bootstrap provider is to translate the users needs to the a number of cloud-init files applicable for each type of cluster nodes. There are three types of cloud-inits: |
| 89 | + |
| 90 | + - The first node cloud-init. That node will be a control plane node and will be the one where the addons are enabled. |
| 91 | + - The control plane node cloud-init. The control plane nodes need to join a cluster and contribute to its HA. |
| 92 | + - The worker node cloud-init. These nodes join the cluster as workers. |
| 93 | + |
| 94 | +The cloud-init scripts are saved as secrets that then the infrastructure provider uses during the machine creation. For more information on cloud-init options, see [cloud config examples](https://cloudinit.readthedocs.io/en/latest/topics/examples.html). |
0 commit comments