I’m fine with this being the general idea. But it seems a bit unfortunate to make it be the only idea.

> You are normally running several instances of your frontend so that it can crash without impacting the user experience, or so it can get deployed to in a rolling manner, etc.

Err, the classic way to do this is to hand off the listening socket from one server instance to the next. You can’t do this if your orchestration tools insist on tearing down the entire network namespace to update the server. Sure, you can use fancy load balancers or software defined networking or firewall kludges to hand off something that functions like a listening socket, but it kind of feels like we lost the plot somehow. The old techniques work, and they often worked at the appropriate scale for the application — why are we building new systems can’t be made to work well without extra layers.

In any event, the feature I want isn’t rocket science. I think Kubernetes would need to add two special kinds of Pods:

1. An joinable Pod that explicitly permits other Pods to join with it (this would be a genuine Pod with some special attributes).

2. A subsidiary Pod that depends on a joinable Pod and joins its network namespace. This would almost be a real pod except that it would have no network namespace of its own and hence no normal managed hostname or addresses.

#2 is a bit weird, but there’s precedent. A hostNetwork: true Pod is already weird in exactly the same way.