Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability to set wireguard IP via node annotation #221

Open
jawabuu opened this issue Aug 9, 2021 · 2 comments
Open

Add ability to set wireguard IP via node annotation #221

jawabuu opened this issue Aug 9, 2021 · 2 comments

Comments

@jawabuu
Copy link

jawabuu commented Aug 9, 2021

In cases where one needs prior knowledge of the nodes IP to for example;

  1. 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,
  2. Check Node Label e.g. kilo.squat.ai/wireguard-ip:"<IPV4 value>"
  3. If label exists, check if IP is valid for the kilo subnet and is available.
  4. Use the IP for the kilo interface
    @squat
@squat squat changed the title Add ability to set wireguard IP via node label Add ability to set wireguard IP via node annotation Aug 9, 2021
@jawabuu
Copy link
Author

jawabuu commented Aug 9, 2021

This is mostly useful for clsters using kilo as CNI

@squat
Copy link
Owner

squat commented Aug 9, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants