mirror of
https://github.com/k8snetworkplumbingwg/whereabouts.git
synced 2025-06-03 06:42:26 +00:00
59f1052972
* build: generate ip pool clientSet/informers/listers
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* vendor: update vendor stuff
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: vendor net-attach-def-client types
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* config: look for the whereabouts config file in multiple places
The reconciler controller will have access to the whereabouts
configuration via a mount point. As such, we need a way to specify its
path.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* reconcile-loop: requires the IP ranges in normalized format
The IP reconcile loop also requires the IP ranges in a normalized
format; as such, we export it into a function, which will be used in a
follow-up commit.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* config: allow IPAM config parsing from a NetConfList
Currently whereabouts is only able to parse network configurations in
the strict [0] format - i.e. **do not accept** a plugin list - [1].
The `ip-control-loop` must recover the full plugin configuration, which
may be in the network configuration format.
This commit allows whereabouts to now understand both formats.
Furthermore, the current CNI release - v1.0.Z - removed the support for
[0], meaning that only the configuration list format is now supported
[2].
[0] - https://github.com/containernetworking/cni/blob/v0.8.1/SPEC.md#network-configuration
[1] - https://github.com/containernetworking/cni/blob/v0.8.1/SPEC.md#network-configuration-lists
[2] - https://github.com/containernetworking/cni/blob/master/SPEC.md#released-versions
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* reconcile-loop: add a controller
Listen to pod deletion, and for every deleted pod, assure their IPs
are gone.
The rough algorithm goes like this:
- for every network-status in the pod's annotations:
- read associated net-attach-def from the k8s API
- extract the range from the net-attach-def
- find the corresponding IP pool
- look for allocations belonging to the deleted pod
- delete them using `IPManagement(..., types.Deallocate, ...)`
All the API reads go through the informer cache, which is kept updated
whenever the objects are updated on the API.
The dockerfiles are also updated, to ship this new binary.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* e2e tests: remove manual cluster reconciliation
This would leave the `ip-control-loop` as the reconciliation tool.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* unit tests: assure stale IPAllocation cleanup
This commit adds a unit where it is checked that the pod deletion leads
to the cleanup of a stale IP address.
This commit features the automatic provisioning of the controller informer cache
with the data present on the fake clientset tracker (the "fake" datastore).
This way, users can just create the client with provisioned data, and
that'll trickle down to the informer cache of the pod controller.
Because the `network-attachment-definitions` resources feature dashes,
the heuristic function that guesses - yes, guesses. very deterministic
... - the name of the resource can't be used - [0]. As such, it was
needed to create an alternate `newFakeNetAttachDefClient` where it is
possible to specify the correct resource name.
[0] -
|
||
|---|---|---|
| .. | ||
| go-restful | ||