Getting an IP before the container queries DHCP

LXD
,
1

I’m currently knee deep in yak hair.
After having gotten LXD containers to stay up-and-running (by faking a correct, static IP), we switched to getting the IP from dnsmasq, and it all fell apart again:

yak trace

we are using profiles as abstraction for the Kubernetes Pod. This makes sense, as some configuration set in the profile will be taken over into the container. in that regard, it also maps astonishingly well to the Pod model of Kubernetes!

With two exceptions:

  1. The Pod is the object that carries the IP. This makes sense, when you consider that the Pod can live longer than a container. A container could die and be restarted, while the Pod continues to exist.

  2. The Pod is also immutable. Once we report an IP, that must continue to be the same.

In LXD only a container can have an IP address, and the only way to get IP address is to start and ask for one via DHCP.
If we wait for the container to come up, our reporting will look like this:

nil
nil
nil
nil
NetworkConfig { Ip: "" } # container comes up here
# but has no IPv4 yet, because it's slooooooow
NetworkConfig { Ip: "10.137.67.18" } # before we ever get here
# kubernetes decided that nil is different from NetworkConfig { Ip: "" }
# and requested for the Pod to be killed

With this in mind, i’d like to

  • generate the MAC address
  • ask for a dhcp lease, and
  • write mac & IP into profile

at profile-creation time.

Good idea?

So, given this context, the question still remains:

Is this a good idea?
Is there any better approach?

If it is a good idea, what’s the best go-lang library to generate MAC addresses, and which to ask for DHCP lease?

2

You can also set the IP address using cloud-init, on those container images that support cloud-init.

4

while technically true, it’s only true for a small sub-set of images.

i would still need to ensure the IP is unique, which is something DHCP would do for me.
so, from multiple points of view, this solution is not idea.

but perhaps i should edit that part of my question to be more clear.

5

I do not understand the full details of your question.

What I understand is that for some reason the containers do not get an IP address fast enough for your setup, using DHCP.

And you are trying to replicate the process of getting an IP address with DHCP, by reimplementing with the aim to get faster DHCP leases.

Personally, I would invest in troubleshooting why the containers do not get those leases fast enough, or how to relax the timeout so that a small delay does not cause a failure.

Apart from that, you can wait for a more experienced member to give some insight.