|
| 1 | +# IPAM Provider Specification |
| 2 | + |
| 3 | +## Overview |
| 4 | + |
| 5 | +The IPAM provider is responsible for handling the IP addresses for the machines in a cluster. |
| 6 | + |
| 7 | +IPAM providers are optional when using Cluster API. Infrastructure providers need to [implement explicit support](#infrastructure-provider) to be usable in conjunction with IPAM providers. |
| 8 | + |
| 9 | +<aside class="note"> |
| 10 | + |
| 11 | +Note that the IPAM contract is single-stack. If you need both v4 and v6 addresses, two pools and two IPAddressClaims are necessary. |
| 12 | + |
| 13 | +</aside> |
| 14 | + |
| 15 | +## Data Types |
| 16 | + |
| 17 | +An IPAM provider must define one or more API types for IP address pools. The types: |
| 18 | + |
| 19 | +1. Must belong to an API group served by the Kubernetes apiserver |
| 20 | +2. Must be implemented as a CustomResourceDefinition. |
| 21 | + The CRD name must have the format produced by `sigs.k8s.io/cluster-api/util/contract.CalculateCRDName(Group, Kind)`. |
| 22 | +3. Must have the standard Kubernetes "type metadata" and "object metadata" |
| 23 | +4. Should have a status.conditions field with the following: |
| 24 | + 1. A Ready condition to represent the overall operational state of the component. It can be based on the summary of more detailed conditions existing on the same object, e.g. instanceReady, SecurityGroupsReady conditions. |
| 25 | + |
| 26 | +## Behaviour |
| 27 | + |
| 28 | +IPAM providers must handle any IPAddressClaim resources that reference IP address pools that are managed by the provider and create an IPAddress resource for it. IPAddressClaims are usually created by infrastructure providers. |
| 29 | + |
| 30 | +### IPAM Provider |
| 31 | + |
| 32 | +An IPAM provider must watch for new, updated and deleted IPAddressClaims that reference an IP address pool that is manged by the provider in their `spec.poolRef` field. |
| 33 | + |
| 34 | +#### Normal IPAddressClaim |
| 35 | + |
| 36 | +1. If the IPAddressClaim does not reference a pool managed by the provider in it's `spec.poolRef`, abort the reconciliation. |
| 37 | +2. If the related Cluster is paused, abort reconciliation |
| 38 | + 1. The related Cluster is referenced using the `spec.clusterName` field or a `cluster.x-k8s.io/cluster-name` label (the latter is deprecated). |
| 39 | + 2. If the paused field is empty and the `cluster.x-k8s.io/paused` annotation is not present, reconciliation can continue. |
| 40 | + 3. If the referenced cluster is not found, abort reconciliation. |
| 41 | + 4. If the referenced cluster has `spec.paused` set or a `cluster.x-k8s.io/paused` annotation, skip reconciliation |
| 42 | +3. Add any required provider-specific finalziers (you probably need one) |
| 43 | +4. Allocate an IP address for the claim |
| 44 | +5. Create an IPAddress object |
| 45 | + 1. It should have the same name as the claim. |
| 46 | + 2. It must have a owner reference with `controller: true` and `blockOwnerDeletion: true` to the Claim |
| 47 | + 3. It must have a owner reference with `controller: false` and `blockOwnerDeletion: true` to the referenced Pool |
| 48 | + 4. It should have a Finalizer that prevents accidental deletion, e.g. `ipam.cluster.x-k8s.io/protect-address`. |
| 49 | +6. Set the `status.addressRef` on the IPAddressClaim to the created IPAddress |
| 50 | + |
| 51 | +#### Deleted IPAddressClaim |
| 52 | + |
| 53 | +1. If the related Cluster is paused, abort reconciliation (see 2. above) |
| 54 | +2. Deallocate the IP address |
| 55 | +3. Delete the IPAddress object |
| 56 | + 1. Remove any Finalizers that were set to prevent deletion |
| 57 | +4. Remove the Finalizer from the claim |
| 58 | + |
| 59 | +#### Clusterctl Move |
| 60 | + |
| 61 | +In order for Pools to be moved alongside clusters, they need to have a `cluster.x-k8s.io/cluster-name` label. |
| 62 | + |
| 63 | +### Infrastructure Provider |
| 64 | + |
| 65 | +In order to consume IP addresses from an IP address pool, an IPAddressClaim resource needs to be created, which will then be fulfilled with an IPAddress resource. Since the IPAddressClaim needs to reference an IP pool, you'll need to add a property to your infrastructure Machine that allows to specify the pool. |
| 66 | + |
| 67 | +<aside class="note"> |
| 68 | + |
| 69 | +Note that the IPAM contract is single-stack. If you need both v4 and v6 addresses, two pools and two IPAddressClaims are necessary. |
| 70 | + |
| 71 | +</aside> |
| 72 | + |
| 73 | +1. Create an IPAddressClaim |
| 74 | + 1. The `spec.poolRef` must reference the pool you want to use |
| 75 | + 2. It should have an owner reference to the infrastructure Machine (or the intermediate resource) it is created for (required to support `clusterctl move`). The reference should have `controller: true` and `blockOwnerDeletion: true` set. |
| 76 | + 3. It's `spec.clusterName` field should be set (or it should have a `cluster.x-k8s.io/cluster-name` label) |
| 77 | + 4. Ideally it's name is derived from the infrastructure Machine's name |
| 78 | +2. Wait until an IP is allocated, ideally by watching the IPAddressClaim and waiting for `status.addressRef` to be set |
| 79 | +3. Fetch the IPAddress resource which contains the allocated address |
| 80 | + |
| 81 | +When the infrastructure Machine is deleted, the claim should be deleted as well. The infrastructure Machine deletion should be blocked until the claim is deleted (handled by the API server if the owner relation is set up correctly). |
0 commit comments