skip to content

When a platform starts a workload, what creates its network interface and gives it an address?

level: middleimportance: nice to knowfreq 28%

answer

  1. the platform delegates this work
  2. before the first process runs
  3. attach, then detach
  4. the address comes from the host's range
  5. allocation state lives with the driver

basics

~20 s

Not the platform itself. It defines a small contract and calls a pluggable attachment driver before the workload's first process starts, handing it the workload's private network view; the driver builds the interface, takes an address from the host's range and returns it.

solid answer

~50 s

Container platforms deliberately do not implement workload networking. They define an attach and detach contract and call a pluggable driver on the host. At start, the platform hands the driver the workload's identity and a handle to its private network view; the driver creates the interface inside that view, allocates an address - often by chaining to a second plugin that owns the host's range and tracks what is in use - writes the routes needed to reach the rest of the fleet, and returns the address, which the platform records. At stop it is called again to tear the interface down and release the address. It is pluggable because encapsulated, natively routed and provider-supplied designs are genuinely different implementations of the same contract, and a platform that hard-coded one of them could not run on the others.

code

pseudocode · 15 lines
pseudocode
on workload_start(workload_id, network_view):
    result = attachment_driver.attach(
        workload_id  = workload_id,
        network_view = network_view,
        host_range   = range_assigned_to_this_host)

    if result.failed:
        # no process has been started yet; nothing to log
        leave workload unstarted and report attach failure

    record(workload_id, result.address)
    start_first_process(workload_id)

on workload_stop(workload_id):
    attachment_driver.detach(workload_id)   # returns the address to the range

go deeper

for a junior

Recall that the platform calls out to a separate, pluggable driver to give a workload its interface and address, rather than doing that work itself.

for a middle

Walk the sequence in order - create the view, call attach before the first process, allocate from the host's range, write routes, return the address, detach on stop - and say why it is pluggable.

for a senior

Use it diagnostically. Attach precedes the first process, so an attach failure produces no application output at all, and the driver's own state is where leaked addresses hide.

for a principal

Treat the driver as fleet infrastructure: it is on the critical path of every start, a copy runs on every host, and its upgrade is a drained, host-by-host rollout rather than a deployment.

## The handoff When a workload starts, its private network view begins empty: a loopback and nothing else. Something has to put an interface in it, give that interface an address, and arrange for packets to find their way out to the rest of the fleet. The platform does not do this itself. It defines a contract and calls out to a **pluggable attachment driver** installed on the host. The sequence is short and always the same shape: 1. The platform creates the workload's private network view. 2. It calls the driver with the workload's identity and a handle to that view - **before the first process starts**. 3. The driver creates an interface inside the view and connects its other end to whatever the host uses to move packets. 4. It obtains an address, usually by calling a second, chained plugin that owns this host's range and keeps the record of which addresses are in use. 5. It writes the routes the workload needs to reach other workloads and the wider network. 6. It returns the address, which the platform records and publishes so the rest of the system can find the workload. 7. At stop, the platform calls detach, and the driver removes the interface and releases the address back to the host's range. ## Why it is a plug-in and not a feature Because the implementations behind step 3 and step 5 are not variations on a theme - they are different designs. One wraps every cross-host packet in host-to-host traffic and needs nothing from the network. Another hands each host's range to the surrounding fabric and routes workload addresses natively. A third has the surrounding infrastructure hand out addresses from its own space directly to each workload. A platform that baked in any one of them would be unusable on estates that require another, so it commits only to **when** it calls out and **what** it passes, never to how the packet path is built. That is also why the vocabulary in this area is generic: attach, detach, an address returned. Everything interesting is on the other side of the contract. ## What this buys you when reading a failure | observation | what it points at | |---|---| | workload created but no process ever ran, no application output | attach failed; the evidence is in the driver's output on the host | | start latency climbs with churn, application start times unchanged | the driver is on the critical path of every start | | addresses used exceeds live workloads by a wide margin | releases are not completing, or the hold window is long | | one host misbehaves after a maintenance window | that host's driver is at a different version from the rest | The first row is the one worth internalising. Attach happens **before** the first process, so a workload that fails there has produced no application logs at all - there was no application. Teams routinely burn an hour reading an empty log stream and concluding the image is broken. ## Operational consequences worth naming - **It is on the hot path of every start.** With thousands of short-lived replicas, the driver's per-attach latency is a visible part of how fast the fleet can turn over. - **A copy runs on every host.** Changing it is a fleet-wide operation, rolled host by host, not a single deployment. - **It owns state the platform cannot see.** The record of which addresses are in use is the driver's, so a leaked allocation - an address never released because a teardown was interrupted - is invisible from above and shows up much later as a range that fills without explanation. - **Its failure mode is placement, not traffic.** When the driver is unhealthy, workloads do not start; traffic between already-running workloads is untouched, because the driver is not in the packet path after attach.

  • A workload never starts and has no application output at all. How does that point at attachment?
    Because attach runs before the first process does. If it fails, the workload exists but nothing inside it ever ran, so there is no application output to read - the absence is the evidence. The explanation lives in the driver's own output on that host, alongside whatever the platform recorded for the failed start, and not in the log stream everyone reaches for first.
  • Why is upgrading the attachment driver a fleet-wide operation rather than a deployment?
    A copy runs on every host and every workload start goes through it, so a version that allocates addresses differently, writes routes differently or changes its own state format affects the whole fleet. It is rolled host by host, with workloads drained off each one first, and with the previous version's allocation records accounted for - a half-migrated fleet can strand addresses that nothing will ever release.

saying these in an interview costs you the question

  • Thinks the orchestrator implements the packet path itself.
  • Assumes every platform attaches workloads to a network the same way.
  • Says the driver runs once per host at boot, not per workload.
  • Reads a workload stuck with no output as an image problem.
  • Forgets that the record of used addresses lives with the driver.