You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In cases where one needs prior knowledge of the nodes IP to for example;
Create host entries that resolve hostnames to kilo created wireguard IPs
A node label that can be set on cluster creation could be implemented to achieve this.
Suggesting to use a label as for most k8s distros, this can be set on node/cluster creation.
This label should indicate a preferred wireguard IP to be set by kilo and ignored if another node already exists with the IP.
This means all other functionality can stay the same.
So in short,
Check Node Label e.g. kilo.squat.ai/wireguard-ip:"<IPV4 value>"
If label exists, check if IP is valid for the kilo subnet and is available.
Kilo uses annotations on the node objects to override and force values that would otherwise be autonomously determined. Let's align this proposal with that practice, e.g. kilo.squat.ai/force-wireguard-ip. I think we should likely use the force- prefix to align with the current practices within Kilo. More importantly, it allows kilo to understand the provenance of a value. Otherwise it will cause problems as nodes do not know if the value is out of date and needs to be updated as the cluster topology has changed or if the value was explicitly set by the administrator.
In cases where one needs prior knowledge of the nodes IP to for example;
A node label that can be set on cluster creation could be implemented to achieve this.
Suggesting to use a label as for most k8s distros, this can be set on node/cluster creation.
This label should indicate a
preferred
wireguard IP to be set by kilo and ignored if another node already exists with the IP.This means all other functionality can stay the same.
So in short,
kilo.squat.ai/wireguard-ip:"<IPV4 value>"
@squat
The text was updated successfully, but these errors were encountered: