Flat reachability
Internal workloads can communicate across the cluster network.
Investigation 023 - Cluster Networking Principles
The request arrived.
Where does it belong?
Inside the platform, a service has a stable address and a derived name. A browser knows only shop.example.com. What translates that public intent without exposing the platform beneath it?
shop.example.comrequest arrivedstorefront? products? cart?
Prologue
The network delivered the request. The platform still cannot place it.
A customer enters https://shop.example.com/products. Public DNS supplies an address. The connection reaches the platform's edge.
External intent
The browser asks for the public hostname and the products path.
Inherited network
Internal workloads can reach stable services by cluster-aware names.
Missing translation
The browser knows none of those internal names or virtual addresses.
Mystery
Something must decide which internal service should receive the request.
First Principles
External expectation and internal organization are different representations.
A public endpoint describes how the outside world approaches a platform. An internal service describes how the platform has organized application behavior. Their lifetimes and owners differ.
Stable service identity
Callers inside the platform do not track changing workload addresses.
Derived names
Internal names converge from authoritative service state.
Those contracts solve communication for a caller already inside. They do not tell an external request how to enter.
Naive Architecture
Expose each service directly.
Every node already has an address the outside world can contact. Let a node forward a public connection to the service that owns it.
External Clientpublic address
Node Networkdirect entry
Serviceinternal destination
No shared boundary
One service becomes reachable without another routing component.
Local ownership
Each team exposes the application it already operates.
Valid at small scale
An internal tool or a few independent services may need nothing more.
The Architecture That Almost Worked
Scale by repeating direct exposure.
Three independent applications receive three endpoints. New services repeat the pattern. Responsibility stays local, failures stay separate, and no shared component becomes critical.
Internetmany clients
Node Addresses + Portsone mapping per service
Internal Servicesindependent owners
The design remains plausible until independent applications become one public product.
Breaking Our Design
Four independent episodes discover one controlled boundary.
Each experiment begins from its own state, earns one architectural step, and stops before the next episode's answer.
EPISODE 01
Every Node Becomes an Entry Point
Pressure. One externally reachable node forwards traffic to a service that remains healthy inside the platform.
Prediction. Replacing infrastructure should not change how an external client reaches the still-available service.
Experiment
Expose node-a, then replace it while the service remains available.
Observation
Internal service identity survives; the old public endpoint does not.
Failure
Infrastructure churn became an external concern.
Discovery
The platform needs one architectural boundary.
Next pressure
Can one address use ports to select services?
Boundary
The boundary is not implemented yet.
Independent simulation: public node identity versus stable internal service identity.
Public nodenode-a / 198.51.100.20
Client endpoint198.51.100.20
Internal servicestorefront available
External resultnot tested
Prediction: replacing infrastructure should not change a public route to an available service.
EPISODE 02
Port Numbers Are Not Routing
Pressure. One public address must distinguish a growing set of internal services.
Prediction. Assigning one port per service should remain simple as the service count grows.
Experiment
Grow from 5 to 20 to 100 assignments, then duplicate one.
Observation
Registry entries and client mappings grow with services.
Failure
The namespace collides and clients require synchronization.
Discovery
Per-service port conventions create a namespace and registry ownership burden and a client-synchronization burden. Both grow with participants, and assignments can collide.
Next pressure
What information distinguishes requests?
Boundary
No universal failure threshold is asserted.
Independent simulation: one public address and a growing coordination surface.
Services5
Registry entries5
Client mappings5
Port namespaceunique so far
Prediction: one port per service should remain a simple convention.
EPISODE 03
Routing Decisions Need More Than Addresses
Pressure. Requests for /products and /cart share one public address, port, and hostname.
Prediction. The transport envelope should contain enough information to choose the intended service.
Experiment
Compare envelopes, then inspect request content.
Observation
The envelopes match; the paths differ.
Failure
Transport reaches the platform but cannot choose the application.
Discovery
Destination choice needs application-level information.
Next pressure
Who owns that shared decision?
Boundary
No API, syntax, or routing policy is selected.
Independent simulation: two requests delivered to the same platform endpoint.
Request A203.0.113.10:443 / shop.example.com
Request B203.0.113.10:443 / shop.example.com
Transport comparisonnot compared
Intended servicesunknown
Prediction: address, port, and hostname should reveal the internal destination.
EPISODE 04
Every Service Now Owns the Edge
Pressure. Four application teams independently own one public identity and four repeated edge responsibilities.
Prediction. Independent ownership should preserve one coherent platform boundary.
Experiment
Count assignments, then let one team change its version.
Observation
Four responsibilities become sixteen assignments and diverge.
Failure
Applications collectively own platform behavior.
Discovery
One platform-owned boundary owns the four responsibilities once.
Contract
Controlled-boundary ownership is earned.
Boundary
No security mechanism or internal isolation is solved.
Independent simulation: four teams repeating responsibilities that conceptually exist once.
Application teams4
Responsibility assignments16
Ownership versionsv1 / v1 / v1 / v1
Boundary ownerfour application teams
Prediction: four teams can independently own one public identity, routing decisions, incoming request records, and boundary protection.
Optional Episode Review
The Turning Point
Keep public addressing stable.
Translate intent at one platform-owned boundary.
Public Requestexternal expectation
Controlled Boundaryplatform owned
Internal Servicestable destination
The boundary mediates between two addressing models. It does not merge them.
The External Access Contract
Five responsibilities. One owner.
Translate external requests into internal service communication while keeping internal architecture invisible to external clients.
Own public identity
The boundary presents the platform's public identity. Applications do not own how the platform identifies itself externally.
Accept external traffic
External requests enter through one architectural boundary, independent of the number of internal services.
Translate intent
The boundary turns application-level request information into internal service destinations.
Hide internal architecture
Workload addresses, service addresses, node topology, and deployment structure remain private.
Centralize edge responsibilities
Platform-wide edge responsibilities are owned once rather than duplicated across applications.
Ownership defines where these responsibilities belong. It does not prove any particular security mechanism, policy, or implementation.
Only Now: Kubernetes
Ingress and Gateway API are bounded realizations of this contract.
Kubernetes Ingress describes HTTP and HTTPS routes from outside a cluster to Services. An implementation-specific controller must realize that description; creating the resource alone does not create a working boundary.
The Kubernetes project states that the Ingress API is frozen and recommends Gateway instead. Gateway API is its successor and offers a broader, role-oriented family of routing APIs. Neither API is the universal architecture: both are ways to express parts of the controlled-boundary contract.
This investigation does not teach their syntax, select a controller, or claim that either option provisions identity, authentication, authorization, rate limiting, filtering, or internal isolation by itself.
The architecture is controlled boundary entry. Ingress and Gateway API are Kubernetes options for expressing it.
Engineering Reflection
Timeless Engineering Principle
When external expectations differ from internal organization, one dedicated boundary must own the translation between them.
Architectural Honesty
Small, independent systems
One application or a few intentionally separate endpoints may justify the simpler design.
One product, many services
Shared public identity and application-level intent create responsibilities no individual service should own.
Costs Accepted
The boundary must be operated, observed, and kept available.
A boundary failure can affect several services at once.
External requests cross another component before reaching a service.
Boundary changes require coordination across platform and application owners.
Was direct exposure wrong?
No. It remains economical when services are few and intentionally independent.
Did the contract solve edge security?
No. It located ownership of boundary protection. Mechanisms and policies remain separate work.
Investigation Exercise
Compare ten public services with one public boundary.
Predict the client knowledge and ownership assignments required by ten direct endpoints.
Record public identity, route, incoming request record, and boundary protection ownership for each service.
Compare the repeated assignments with one boundary that forwards to stable internal services.
Separate business ownership from responsibilities that exist once for the platform.
Run the synthesis trace after writing your prediction.
Bridge to INV-024
External entry is controlled.
Internal reachability is still universal.
External clients use one stable public boundary.
The boundary translates public intent into internal service communication.
Application teams no longer duplicate ownership of the platform's edge.
But the flat network still lets every internal workload reach every other workload.
Reachability establishes capability. It does not establish authorization.
The boundary controls entry. The next mystery asks which communication paths should exist once inside.
Intellectual Lineage
This investigation inherits decomposition and continuous control ideas established earlier in the book and grounded in control theory, Borg, and Omega. It applies that lineage to ownership of an external boundary; it does not claim Borg or Omega invented Kubernetes ingress.
Deliberate Simplifications Ledger
Boundary implementations, controllers, and infrastructure provisioningUnassigned future investigation
Identity provisioning, authentication, authorization, filtering, and rate limitingUnassigned future investigation
Streaming protocols, multi-cluster traffic, and global balancingUnassigned future investigation
Internal communication authorization and isolationINV-024