This repository contains a controller to manage static IP address allocations in Cluster API Provider Metal3.
For more information about this controller and related repositories, see metal3.io.
| IPAM version | CAPM3 version | Cluster API version | IPAM Release |
|---|---|---|---|
| v1alpha1 (v1.1.X) | v1beta1 (v1.1.X) | v1beta1 (v1.1.X) | v1.1.X |
| v1alpha1 (v1.2.X) | v1beta1 (v1.2.X) | v1beta1 (v1.2.X) | v1.2.X |
| v1alpha1 (v1.3.X) | v1beta1 (v1.3.X) | v1beta1 (v1.3.X) | v1.3.X |
| v1alpha1 (v1.4.X) | v1beta1 (v1.4.X) | v1beta1 (v1.4.X) | v1.4.X |
| v1alpha1 (v1.5.X) | v1beta1 (v1.5.X) | v1beta1 (v1.5.X) | v1.5.X |
| v1alpha1 (v1.6.X) | v1beta1 (v1.6.X) | v1beta1 (v1.6.X) | v1.6.X |
| v1alpha1 (v1.7.X) | v1beta1 (v1.7.X) | v1beta1 (v1.7.X) | v1.7.X |
| v1alpha1 (v1.8.X) | v1beta1 (v1.8.X) | v1beta1 (v1.8.X) | v1.8.X |
| v1alpha1 (v1.9.X) | v1beta1 (v1.9.X) | v1beta1 (v1.9.X) | v1.9.X |
| v1alpha1 (v1.10.X) | v1beta1 (v1.10.X) | v1beta1 (v1.10.X) | v1.10.X |
| v1alpha1 (v1.11.X) | v1beta1 (v1.11.X) | v1beta1 (v1.11.X) | v1.11.X |
| v1alpha1 (v1.12.X) | v1beta1 (v1.12.X) | v1beta2 (v1.12.X) | v1.12.X |
| v1alpha1 (v1.13.X) | v1beta2 (v1.13.X) | v1beta2 (v1.13.X) | v1.13.X |
See metal3-dev-env for an end-to-end development and test environment for cluster-api-provider-metal3 and baremetal-operator.
See the API Documentation for details about the objects used with this controller. You can also see the cluster deployment workflow for the outline of the deployment process.
- A running Kubernetes cluster (e.g. kind)
- Clusterctl
- Kustomize
- envsubst
Deploys IPAM CRDs, RBAC, webhooks, and the controller.
Note: clusterctl will automatically install cert-manager if it is not already
present.
clusterctl init --ipam metal3make generate-examples
make deploy-exampleskubectl get ippool -n metal3-ipam-system
kubectl get ipaddress.ipam.metal3.io -n metal3-ipam-system# Clean up generated files
make delete-examplesTo clean up environment delete your cluster or delete the IPAM namespace
kubectl delete namespace metal3-ipam-systemWhen kubectl apply and kubectl delete are executed for an IPClaim in rapid
succession (within the same second), the IPClaim may be deleted, but the
associated IPAddress might not be removed as expected, potentially leading to
resource inconsistencies. This is not a common or typical use case. In normal
scenarios, the operations work as expected. Since this issue occurs only under
rare timing conditions, it has been classified as a low-priority item. We plan
to address it in a future and it is currently documented as a known limitation.