mirror of
https://codeberg.org/scottslowe/learning-tools.git
synced 2026-03-11 09:04:37 +00:00
Add Terraform configuration for CAPI-Velero infrastructure. Add `kubeadm` configuration files for bootstrapping clusters. Signed-off-by: Scott Lowe <scott.lowe@scottlowe.org> |
||
|---|---|---|
| .. | ||
| infra.tf | ||
| instances.tf | ||
| kubeadm-cp-mgmt-a.yaml | ||
| kubeadm-cp-mgmt-b.yaml | ||
| kubeadm-wkr-mgmt-a.yaml | ||
| kubeadm-wkr-mgmt-b.yaml | ||
| output.tf | ||
| provider.tf | ||
| README.md | ||
| securitygroups.tf | ||
| terraform.tfvars.example | ||
| variables.tf | ||
Infrastructure for CAPI-Velero Testing
This repository contains the files necessary to create an environment for testing the use of Velero with Cluster API. This includes a Terraform configuration for creating the required AWS infrastructure, and kubeadm configuration files for bootstrapping the resulting instances into a Kubernetes cluster.
Prerequisites/Assumptions
- This repository and these instructions assume the presence of IAM roles and policies that enable the AWS cloud provider. Refer to this blog post for more information.
Instructions
- Create a
terraform.tfvarsfile using the includedterraform.tfvars.examplefile as an example. - Review the default values in
variables.tfand override them, as needed, with additional values in theterraform.tfvarsfile created in step 1. - Review the IAM instance profile specified in
instances.tfand make sure that the names there match the names of IAM instance profiles in your AWS account that enable/support the AWS cloud provider. - Run
terraform planand review the output. - If the output of step 4 is acceptable, run
terraform applyto create the infrastructure. - Using SSH, log into each of the instances created in step 4 and ensure that the local hostname matches the EC2 Private DNS entry. Running
sudo hostnamectl set-hostname $(curl -s http://169.254.169.254/latest/meta-data/local-hostname)will make sure the hostname is set correctly. (Note that SSH access is via a bastion host, so some local SSH configuration may be necessary.) - After step 5 and step 6 are completes, use
terraform outputto customize thekubeadm-cp-mgmt-a.yamlfile. Specifically, change the value of the "controlPlaneEndpoint" line to reflect the correct DNS name of the load balancer created for the "mgmt-a" cluster. Also change the value of the "name" field under "nodeRegistration" fromHOSTNAMEto the full hostname set in step 6. - Repeat step 7, but for the
kubeadm-cp-mgmt-b.yamlfile and using the correct DNS name of the load balancer created for the "mgmt-b" cluster. - Use
rsyncorscpto copy the modifiedkubeadm-cp-mgmt-a.yamlandkubeadm-cp-mgmt-b.yamlto the control plane instances for the "mgmt-a" and "mgmt-b" clusters, respectively. Name the fileskubeadm.yamlon the destination systems. - On the control plane instances for the "mgmt-a" and "mgmt-b" clusters (you can use
terraform outputto get the information on these instances), runkubeadm init --config kubeadm.yaml. - Using the information displayed by the
kubeadm initcommand on each of the control plane nodes, customize thekubeadm-wkr-mgmt-a.yamlandkubeadm-wkr-mgmt-b.yamlfiles. Specifically, you will need to supply the value of the bootstrap token, the SHA256 hash of the control plane certificate, the DNS name of the control plane endpoint, and the hostname of the system (which, in step 6, you set to same value as the EC2 Private DNS entry). - Copy the files modified in step 11 to the worker instances for the "mgmt-a" and "mgmt-b" clusters, respectively. Name the files
kubeadm.yamlon the destination systems. - On each of the worker instances, run
kubeadm join --config kubeadm.yaml. - When step 13 completes, install a CNI plugin. Refer to the CNI plugin's documentation for specifics.
Upon the completion of the above steps, you will have a functional Kubernetes cluster that is ready to be made into a Cluster API management cluster using clusterctl init. These management clusters can then be used for testing the use of Velero for backing up and restoring Cluster API objects.