flannel: allow input ipam parameters as basis for delegate #532
Conversation
| // IPAM field "replaces" that of types.NetConf which is incomplete | ||
| IPAM map[string]interface{} `json:"ipam,omitempty"` |
There was a problem hiding this comment.
Why use a string map rather than a struct ?
(It came as a surprise to me that containernetworking/cni does not define any useful IPAM struct, but even so, why don't you?)
There was a problem hiding this comment.
Even though my own use case is about the routes, I thought it would be nice to allow transparently passing any IPAM parameter that could apply to the delegate (bridge or other). In order not to limit the possibilities there, a string map looked appropriate to me (I'm not aware of any way to unmarshal into a struct while preserving and giving access to all extra fields not defined in the struct).
You will see in flannel_linux.go:getDelegateIPAM() that the incoming string map, when present, is used as basis for the delegate ipam.
|
@rajatchopra does this look sane to you? Would you use an override capability for flannel IPAM? |
This change allows providing an 'ipam' section as part of the
input network configuration for flannel. It is then used as
basis to construct the ipam parameters provided to the delegate.
All parameters from the input ipam are preserved except:
* 'subnet' which is set to the flannel host subnet
* 'routes' which is complemented by a route to the flannel
network.
One use case of this feature is to allow adding back the routes
to the cluster services and/or to the hosts (HostPort) when
using isDefaultGateway=false. In that case, the bridge plugin
does not install a default route and, as a result, only pod-to-pod
connectivity would be available.
Example:
{
"name": "cbr0",
"cniVersion": "0.3.1",
"type": "flannel",
"ipam": {
"routes": [
{
"dst": "192.168.242.0/24"
},
{
"dst": "10.96.0.0/12"
}
],
"unknown-param": "value"
},
"delegate": {
"hairpinMode": true,
"isDefaultGateway": false
}
...
}
This results in the following 'ipam' being provided to the delegate:
{
"routes" : [
{
"dst": "192.168.242.0/24"
},
{
"dst": "10.96.0.0/12"
},
{
"dst" : "10.1.0.0/16"
}
],
"subnet" : "10.1.17.0/24",
"type" : "host-local"
"unknown-param": "value"
}
where "10.1.0.0/16" is the flannel network and "10.1.17.0/24" is
the host flannel subnet.
Note that this also allows setting a different ipam 'type' than
"host-local".
Signed-off-by: David Verbeiren <david.verbeiren@tessares.net>
dverbeir
force-pushed
the
flannel_ipam_routes
branch
from
55511c2 to
9ce99d3
Compare
|
I re-based on the latest master so the tests pass now. How to move on with this change? Do we need the feedback from @rajatchopra? |
|
seems fine |
(NOTE: This work started under PR #527 which was a combination of this and the addition of logging; now split into 2 PRs)
This change allows providing an 'ipam' section as part of the input network configuration for flannel. It is then used as basis to construct the ipam parameters provided to the delegate.
All parameters from the input ipam are preserved except:
One use case of this feature is to allow adding back the routes to the cluster services and/or to the hosts (HostPort) when using isDefaultGateway=false. In that case, the bridge plugin does not install a default route and, as a result, only pod-to-pod connectivity would be available.
Example:
This results in the following 'ipam' being provided to the delegate:
where "10.1.0.0/16" is the flannel network and "10.1.17.0/24" is the host flannel subnet.
Note that this also allows setting a different ipam 'type' than "host-local".