Skip to content

Network

Visualizes how traffic actually flows through your cluster — the Ingress → Service → Pod topology, endpoint health, and optionally the cloud VPC underneath it.

Tier: Free

What it does

Network visualizes how traffic actually flows through your cluster, and optionally the cloud network underneath it. The topology DAG shows Ingress → Service → Pod as SVG bezier edges with hover adjacency glow, so you can see the actual path a request takes rather than inferring it from separate resource lists. Endpoint health scoring and an issues bar surface anything misconfigured at a glance, before you have to read the graph line by line.

A Cloud toggle overlays VPC/VNet and subnet cards, auto-detected from each node's providerID across AWS, GCP, or Azure. IP utilization bars are drawn for AWS and Azure, which report live address allocations; on GCP the subnet CIDR and size are shown without a bar, since the subnet list carries no free-IP count. The Cloud overlay and the credentials it uses are Pro. Pod network bandwidth is shown via Prometheus; if you don't run Prometheus, pod bandwidth trend charts are also available with zero setup via the Metrics tab's kubelet cadvisor scrape, which is on by default (metrics.kubeletScrape.enabled).

The topology auto-refreshes every 15 seconds, so it reflects recent changes without a manual reload.

Network Analyzer

The map shows how traffic is WIRED. The analyzer answers whether a specific connection would actually be allowed: pick a source and a destination, and KubeManta evaluates the path hop by hop — pod selectors, namespace selectors, IP blocks, ports and default-deny, in both directions — then shows the chain with the blocking rule named. "Pod A cannot reach Service B" becomes "this NetworkPolicy in that namespace denies egress on that port", which is the difference between knowing something is broken and knowing what to change.

This is STATIC analysis: it reads the policies rather than sending traffic, so it is instant, safe on a production cluster, and available to viewers on every plan.

An optional active probe (Pro, admin, and Expert Mode) confirms or refutes the static prediction by actually attempting the connection — an ephemeral container in the source pod, or a host-network debug pod when the source is a node. It is admission-aware: before launching anything it checks whether the cluster's own policies (PodSecurity, Gatekeeper, Kyverno) would permit the probe, and falls back to the static answer with an explanation rather than surfacing a raw webhook rejection. The two together are the useful pair — static says what the rules mean, the probe says what the network does, and a disagreement between them is itself the finding.

What the arrows mean

An arrow from a Service to a Pod means that pod is currently receiving traffic — it is in one of the Service's EndpointSlices. It does not mean the pod merely matches the Service's label selector.

The difference is the useful part. A pod can match the selector and still receive nothing: a failing readiness probe, a port that does not resolve, a pod still starting. Those pods are not drawn as connected; instead the Service reports them, because "selected but not serving" is a diagnosis rather than a line on a diagram.

It also means a Service with no selector at all — the standard way to front a database outside the cluster, with endpoints managed by hand — shows its real backends instead of appearing isolated.

Draining pods are counted separately. During a rolling update the pods being shut down appear as terminating, not as failures, so a healthy deploy no longer reads as an outage. They count toward the total ("2/3 pods, 1 draining") so the Service does not look like it is losing capacity either.

Where the cluster provides them, zones and address families (IPv4/IPv6) appear on the Service, since both change where traffic actually goes.

On clusters too old for EndpointSlices the panel falls back to the older Endpoints API and says so — that path cannot distinguish draining from broken, carries one address family, and stops at 1000 endpoints per Service.

Services that are not what they look like

  • ExternalName shows what it points at, as an external node. It has no pods by design, so it is never marked unhealthy for having none.
  • Headless (no cluster IP) says so: DNS returns pod addresses directly, which is how StatefulSet members are addressed one by one.
  • NodePort / LoadBalancer show the node port and the assigned address. A LoadBalancer with no address reads as waiting rather than as an ordinary service — on bare metal with no provisioner it stays that way indefinitely.
  • A Service with no endpoints at all is an error, not a healthy service with an empty list. Nothing is behind it and every connection is refused.
  • A named targetPort that no backing pod declares is reported. The Service and the pods both look fine in isolation, and traffic goes nowhere.

Gateway API

If your cluster runs Gateway API, Gateway and HTTPRoute/GRPCRoute appear alongside Ingress rather than instead of it — most clusters run one, some run both during a migration.

The fact worth having on screen is attachment. A route whose parentRef was refused looks perfectly healthy as an object: it exists, it is well-formed, and it routes nothing. The refusal lives only in the route's status, and the usual causes are a Gateway that does not allow routes from that namespace, no listener matching the hostname, or hostnames that do not intersect. The panel shows the route as not attached and repeats the controller's own reason, which is normally specific enough to act on.

A Gateway that is not Programmed is called out too: the object exists, but no data plane is serving it, so nothing reaches any route attached to it.

Routes attached to a Gateway in another namespace are not drawn as connected here — that Gateway is outside the namespace being displayed, and drawing an edge to something not on screen would suggest a link that cannot be inspected.

Clusters without the Gateway API CRDs see exactly what they saw before. Nothing is added, and no empty section implies something is missing.

Reading a NetworkPolicy

Clicking a NetworkPolicy shows what it actually permits, not just that it exists: which pods it applies to, and per direction the peers it allows (pod selectors, namespace selectors, and IP blocks including any except carve-outs) with their ports.

Three states are called out in words, because each one is the opposite of the obvious reading:

  • Deny all — the direction is enforced and the policy lists no rules. Nothing may connect. An empty section would read as "unrestricted", which is backwards.
  • Any source / any destination — a rule exists but names no peers, which permits everything. In YAML this is one character away from deny-all and means the opposite, so the panel says which pods can then connect, and on what ports.
  • Not restricted by this policy — the direction is absent from the policy's policyTypes. That is a third state, not a synonym for denied: this policy simply says nothing about that direction.

The policy list carries the same conclusion in one word — any source or deny all — because a policy that permits everything and one that permits nothing otherwise look identical in a list, and a NetworkPolicy merely existing tends to read as "this is restricted". If your databases show any source, they accept connections from any pod in the namespace.

This is a description of your policies, not a security score; ranking issues is the Security tab's job.

What applies to this pod

Selecting a pod shows the combined effect of every NetworkPolicy in the namespace, per direction, because no single policy object answers the question. Policies are additive: a pod matched by two ingress policies gets the union of their allowed peers, and being matched by any policy in a direction switches that direction from allow-by-default to deny-by-default for everything the policies do not name.

Three states, each the opposite of the obvious reading:

  • Not restricted — no policy selects this pod in that direction, so everything is permitted. An empty list here does not mean nothing may connect.
  • Denied — a policy selects it and names no peers. One character away from the case below, in YAML, and its exact opposite.
  • Restricted — only the named peers, and nothing else.

AdminNetworkPolicy and BaselineAdminNetworkPolicy are folded into the verdict, in the order the cluster applies them: ANP first, by priority, with Pass deferring downward; then the namespaced NetworkPolicies; then BANP as the fallback. The panel names which tier decided, so a verdict a platform-team policy is responsible for does not read as something the namespace chose.

It also distinguishes "the CRDs are not installed, or could not be read" from "installed, and none apply here" — the panel states which tiers it actually weighed rather than implying it weighed all three.

Is anything actually enforcing these policies?

Every posture on this screen — "deny all", "any source", the per-pod verdicts — is a claim about permitted traffic, and every one of them is FALSE on a cluster whose CNI ships no policy controller. flannel has none. The AWS VPC CNI has one that does nothing unless you enable it. On those clusters a NetworkPolicy is stored by the API server and enforced by nobody: an unlocked lock.

So KubeManta says which it is, in a banner above the policy list, and the answer is deliberately THREE-VALUED:

  • Enforcing — a policy controller was identified. No banner; the postures below mean what they say.
  • No controller is enforcing these policies — shown in red, naming the CNI it found. Every rule below is decorative until that changes.
  • KubeManta cannot tell — shown in amber. The CNI could not be identified, so enforcement is unknown.

"Cannot tell" never collapses into "enforcing". Reassuring you about a control that is not running would be worse than saying nothing, which is exactly why this rides on the same data as the postures rather than a separate call that could quietly fail.

Finding one policy among a hundred

The policy list is grouped by the workload each policy governs rather than being one flat wall of chips, and it PAGES. Ordering is load-bearing: groups with findings come first, then the rest by name — on a cluster with ~118 policy chips two findings were effectively invisible, and a finding on page 7 is more invisible still.

The filter box above the list narrows by policy, workload or pod name, and the count beside the heading always states how many of the total you are looking at, so a filter can never be mistaken for a small cluster. Searching the MAP highlights the match along with its cards and its edges, so a name you know leads to the part of the graph it belongs to.

Setup

Reach Network from the OBSERVE group in the sidebar. Click any node — Ingress, Service, or Pod — to open its detail panel. The Cloud toggle appears only on a cluster whose nodes carry an AWS, GCP or Azure providerID, and the overlay itself needs both a Pro license and cloud credentials configured under Admin → Cloud.

Troubleshooting

When troubleshooting connectivity, check the issues bar first — it surfaces endpoint mismatches before you have to trace the graph by eye, and it's usually the fastest way to spot a Service with no matching Pod selector or an Ingress pointing at a Service that doesn't exist. If the Cloud overlay stays empty after enabling the toggle, check the license tier first — the overlay is Pro, and on Free the request is refused and the layer stays blank rather than reporting anything; then confirm cloud credentials are configured and valid under Admin → Cloud. If bandwidth numbers are missing, check whether Prometheus is configured, or read the kubelet cadvisor scrape's per-node failure reason under Metrics — Network's bandwidth view depends on the same sources.

Generated from KubeManta 1.2.0 — this page is rendered from the product's own documentation, so it cannot drift from what ships. Manifest built 2026-09-12T02:14:45Z.