DHCP has many shortcomings which we're currently doing our best to work around. For example:
- No stable lease identity for any given container (workaround: record MAC and create reservations for each container)
- Each container requires a DHCP daemon (workaround: Proxmox host-managed dhcp)
- IP addresses aren't known until after a container is online (no current workaround)
Each of these could be easily mitigated by allowing the API server (create-a-contianer/manager) to select an IP address when a container is first requested (before even enqueueing the create job). Then the Node can be instructed to create the container with the given IP and not have to rely on the DHCP server.
This does come with some extra limitations, the largest of which is the API server needs to know the IP address of the DNS server (the current dnsmasq server, aka the agent) which it currently does not - we rely on DNSMasq's behavior of giving out itself as the DNS server. This can be mitigated with an agent checkin which we will need eventually anyways.
DHCP has many shortcomings which we're currently doing our best to work around. For example:
Each of these could be easily mitigated by allowing the API server (create-a-contianer/manager) to select an IP address when a container is first requested (before even enqueueing the create job). Then the Node can be instructed to create the container with the given IP and not have to rely on the DHCP server.
This does come with some extra limitations, the largest of which is the API server needs to know the IP address of the DNS server (the current dnsmasq server, aka the agent) which it currently does not - we rely on DNSMasq's behavior of giving out itself as the DNS server. This can be mitigated with an agent checkin which we will need eventually anyways.