The Network You Meant to Run

Most production network problems are not failures of a single source of truth. They are failures of comparison.

Kubernetes can tell us what was requested. A process and its metrics can tell us what it is doing. Both answers matter, and neither makes the other redundant. A Service definition is not proof that a socket is bound; an open socket is not proof that it belongs in the deployment.

The new CP Network View puts those two statements next to each other. Its most useful output is not a prettier topology diagram. It is the visible difference between the network we intended to run and the one that is running.

A diagram is a claim

Topology diagrams have a peculiar status in operations. Everyone knows they go stale, yet everybody reaches for one during an incident. It is because the question is spatial: what can talk to what? A table of pods and a page of manifests can contain the answer without making it easy to see.

But a static diagram is only a claim about the intended system. It cannot show whether a rollout left a port silent, whether a service points at ready endpoints, or whether an application acquired a listener that no deployment description accounts for. It can be useful documentation, but it is not operational evidence.

The opposite mistake is to treat a socket table or a traffic dashboard as the whole truth. Those show activity, but leave an operator to remember what was supposed to be there. That is exactly how configuration drift becomes an investigation spread over shell sessions, dashboards, Helm values, and old architecture drawings.

Network View makes the comparison explicit. Its declared side comes from the cluster's pods, Services, and EndpointSlices. Its observed side comes from named jPOS networking metrics, supplemented for non-jPOS workloads by a restricted collector that reads socket state without Kubernetes credentials. The browser receives a single, permissioned snapshot; it does not get direct access to either the cluster API or Prometheus.

Drift has a shape

Once both sides are in the same model, an operator need not infer a mismatch from unrelated facts. The possibilities have useful meanings:

• Declared and observed means the expected listener is present.
• Declared but unobserved means a promised endpoint is silent or unresolved.
• Observed but undeclared means the running system has something nobody described—a deployment mistake, a stale configuration, or an event that deserves a security investigation.

The distinction is deliberately narrower than a generic health check. A pod can be healthy while exposing the wrong port; a Service can exist while no ready endpoint is listening. Conversely, a connection may be legitimate even when the current manifest has drifted away from the deployment that created it. The View does not pretend to decide intent from a packet. It makes the disagreement impossible to overlook and gives the operator a precise place to start.

That precision matters in payment systems. Network changes are often mundane: a missing environment variable, a partial rollout, an endpoint selected by the wrong label. The same evidence can also reveal something much less mundane. Treating every mismatch as either an outage or an intrusion would be noisy and misleading. Treating it as a first-class discrepancy gives the team enough context to decide.

Observability should say when it does not know

The observed side is intentionally built from measurements rather than guesses. jPOS applications report sockets with their operational names and protocols. That is more useful than a list of anonymous address pairs, and it keeps the metric surface away from transaction payloads. Peer labels are bounded to workload names, configured network buckets, or an overflow bucket; unbounded remote-address labels would turn a monitoring feature into a cardinality problem.

There is another important discipline here: incomplete observation must not be rendered as silence. If Prometheus or a particular exporter is unavailable, Network View marks the snapshot as declared-only. It does not paint every declared port red and call that a discovery. An honest degraded view is much more valuable than a confident but fabricated diff.

The same rule applies to history. Network activity can be inspected at a past instant because the observed plane is stored in Prometheus. Kubernetes does not provide the old declaration merely because an operator moved a timeline. The historical view therefore says what it is: current declaration alongside the observation at a specified earlier instant. That is not a limitation to hide; it is the difference between replaying evidence and silently inventing a past topology.

From a view to an operational control

A useful visual surface should not depend on someone happening to watch it. CP evaluates the same declared-versus-observed comparison on the server and notifies operators when a new undeclared listener or unexpected peer appears. It reports transitions rather than repeating the same warning every few minutes. A discrepancy that clears and later returns is a new event; a standing condition remains one investigation.

Not every difference deserves a page. A declared-but-silent service is often a configuration or rollout problem worth seeing in the View, but it is not automatically a security alarm. The alerting path focuses on the observations that are harder to explain away, while the complete diff remains available for routine operational work.

This is the larger point of the feature. Desired state and live state are both necessary, but they become operationally valuable only when a system compares them continuously and truthfully. The interesting part of a network diagram is not the lines that match. It is the line that should be there but is not—and the one that is there without an explanation.