The node is addressable
One machine address already exists and can receive traffic.
Investigation 018 · Node Execution Principles
A Pod is one execution group.
Should it borrow the node's address?
INV-017 already earned shared lifecycle, shared fate, and shared network namespace inside one execution group. The mystery now is identity ownership: if the group is the execution unit, should network identity belong to the node or to that running group?
Begin the investigation ↓Node IPSHARED BY MANY GROUPS?
Prologue
Two unrelated HTTP applications both choose port 80.
A platform team starts with the simplest networking design: every execution group borrows the node IP, and port numbers distinguish applications.
Node
Machine has one address: 192.168.10.25.
Group A
Unrelated web app listens on tcp/80.
Group B
Another web app also listens on tcp/80.
Result
The machine cannot bind both to the same endpoint.
The network design, not the applications, created interference.
First Principles
One machine already has one address.
Reusing that address for every execution group is economical and easy to explain. Before rejecting it, we must ask what independent groups require from one shared endpoint namespace.
Can every group borrow it?
We have not yet tested collisions, placement changes, replicas, or ownership.
The simplest network reuses what already exists. Reality must earn any additional identity.
Naive Architecture
Every execution group borrows the node IP.
The node already has identity. Reuse it for all groups and let endpoints differ by port.
Node192.168.10.25
Group Aborrows node IP
Group Bborrows node IP
The Architecture That Almost Worked
One node identity. Many execution groups.
Every group uses the machine address. The machine delivers traffic to the intended group. Address allocation stays trivial and identity grows only with machines.
One address per node
No workload-scale identity pool is required.
Reach the machine first
The network already knows how to address the host.
Groups can share peacefully
The design assumes unrelated applications never require the same endpoint.
The architecture is elegant until two unrelated applications ask for the same endpoint.
Breaking Our Design
Four causal episodes derive one ownership reversal.
EPISODE 01
Two Pods, One Port
Pressure. Two unrelated HTTP workloads on one node both need tcp/80.
Prediction. If borrowed node identity is sufficient, both should run independently.
Experiment
Bind both workloads to node IP tcp/80.
Observation
First bind succeeds, second bind is rejected.
Failure
Independent workloads interfere through shared endpoint namespace.
Discovery
Endpoint namespace cannot be shared by unrelated groups.
Next Pressure
Port patching may avoid this one collision.
Constraint
Collision is architectural, not application error.
Boundary Delta
Identity must separate neighbors.
Local experiment: two groups bind the same endpoint.
Group Apending
Group Bpending
Endpoint192.168.10.25/tcp/80
Run the bind test on shared node identity.
EPISODE 02
Moving Identity
Pressure. Distinct ports patch the first collision, but a later placement selects a different node address for the same workload specification.
Prediction. If the borrowed endpoint represents workload identity, infrastructure placement should not determine it.
Experiment
Place a new instance of the same workload specification on Node B.
Observation
Its borrowed endpoint is determined by Node B rather than the workload instance.
Failure
Placement owns addressability by accident.
Discovery
A running instance needs identity assigned to the group, not borrowed from its node.
Next Pressure
Replica scale now tests neighbor independence.
Constraint
Infrastructure location and workload identity diverge.
Boundary Delta
Addressability cannot be borrowed location.
Local experiment: compare the same workload specification under a new placement.
Current nodeNode A (192.168.10.25)
Endpoint before192.168.10.25/tcp/8080
Endpoint afternot moved
This group currently borrows Node A identity.
EPISODE 03
Identical Neighbors
Pressure. Three identical replicas on one node all require tcp/8080.
Prediction. If port patching solved identity, replicas should coexist without coordination.
Experiment
Add three identical neighbors sharing one node IP.
Observation
One replica binds, others collide.
Failure
Scale-out of identical app self-conflicts.
Discovery
Endpoint namespace must be neighbor-independent.
Next Pressure
Ownership itself is still inverted.
Constraint
Identity cannot depend on nearby workloads.
Boundary Delta
Replica coexistence requires per-group identity.
Local experiment: add identical replicas on one node and bind port 8080.
Replica 1pending
Replica 2pending
Replica 3pending
Replicas all target node IP endpoint tcp/8080.
EPISODE 04
Shared Identity and Ownership Inversion
Pressure. Node identity still governs workload addressability.
Prediction. Correct ownership classification should remove all three prior failures conceptually.
Experiment
Classify responsibilities between node and execution group.
Observation
Wrong owner creates contradictions seen in earlier episodes.
Failure
Node-owned identity couples execution with addressing.
Discovery
Node owns execution duties; execution group owns network identity.
Next Pressure
Formalize contract before naming implementations.
Constraint
Ownership must follow what changes versus what stays stable.
Boundary Delta
Identity ownership moves from node to group.
Local experiment: classify each responsibility owner.
Node identity dutiesnone yet
Current responsibilityRepresent machine location
Group identity dutiesnone yet
Classify all responsibilities to reveal ownership inversion.
Compact Review
The Turning Point
Machines execute groups.
Groups own identity.
This does not yet design networking mechanics. It only derives correct ownership boundaries.
The Network Identity Contract
Five generic guarantees before implementation names.
Running execution-group instances require identity that is exclusive across groups, shared within the group, owned independently of node and neighbors, and used for workload-addressed communication.
| Contract | Guarantee |
|---|---|
| Exclusive identity per execution group | Unrelated groups do not share one network identity. |
| Shared identity within one group | Cooperating processes in the group present one identity externally. |
| Node-independent identity ownership | Placement selects where an instance runs; the node address does not become that instance's identity. |
| Neighbor-independent endpoint namespace | Neighbor replicas do not collide simply because they share a node. |
| Workload-addressed communication | Applications address workloads, not machine location. |
Explicit non-goal: this contract does not promise address persistence across replacement of an execution group.
Only Now: Kubernetes
Kubernetes names this identity as the Pod IP.
After the generic contract is earned, Kubernetes terminology can be introduced: the execution group is the Pod, and the Pod receives its own IP identity.
This chapter does not explain allocation, namespace holder, virtual interfaces, routing, CNI, Services, or DNS.
Name after principle, never before principle.
Engineering Reflection
Infrastructure location must not masquerade as workload identity.
This principle is timeless across distributed systems. If location and identity are coupled, routine operations leak into application semantics.
Architectural Honesty
Identity ownership
Collision and relocation failures are removed by assigning identity to execution groups.
Identity mechanics
Address allocation, uniqueness enforcement, and routing remain later investigations.
Scale Grounding
20,000 nodes × 250 execution groups per node ≈ 5,000,000 identities.
Costs Accepted
Address space
Every running group consumes an identity.
Allocation
Identity assignment and lifecycle become mandatory.
Routing
Connectivity must account for workload-scale identity growth.
Uniqueness
Conflicts must be prevented across the platform.
Intellectual Lineage
Demands clear workload identity independent from underlying machines.
Separates application addressability from host placement to preserve mobility.
Applies INV-017 execution-group boundary to networking identity ownership.
Investigation Exercise
Re-run the causal chain and stop where evidence stops.
Reproduce same-IP same-port conflict.
Place a new instance on another node and observe that borrowed addressing follows infrastructure.
Add identical neighbors and observe collision without coordination.
Classify responsibilities and derive identity inversion.
Run the synthesis trace, or cancel it midway to inspect partial evidence.
Bridge to INV-019
Identity is isolated.
CPU and memory are still finite.
Port collisions are removed by identity ownership, but nodes remain finite physical machines. Multiple groups still compete for shared CPU and memory capacity.
If unmanaged shared identity causes port contention, unmanaged shared CPU and memory cause execution contention.
Deliberate Simplifications Ledger
How a Pod network namespace is created and held across member restartsOpen backlog
How an IP address is allocatedOpen backlog
How uniqueness is guaranteed across the clusterOpen backlog
How virtual network interfaces are attachedOpen backlog
How packets enter and leave a PodOpen backlog
How different network plugins implement these guaranteesOpen backlog
How Pods communicate across different nodesINV-020
How Services provide a stable address across an instance being replacedINV-021
How DNS resolves a name to that stable addressINV-022
Sources
- Kubernetes — Pods
- Kubernetes — Cluster Networking
- Kubernetes — Services, Load Balancing, and Networking
- Burns, Grant, Oppenheimer, Brewer, Wilkes. Borg, Omega, and Kubernetes. ACM Queue, 2016.