Connectivity

Connectivity

Network → Connectivity answers "can pod A reach pod B?" from the network policies in the cluster, and explains which policy and which rule decide. It reads Kubernetes NetworkPolicies and, as far as they map to L3/L4 rules, Cilium and Calico policies.

Sextant reasons from the policy objects, not from live traffic: nothing is sent between pods and no pod is entered. A NetworkPolicy has an effect only when the cluster's network plugin (CNI) enforces it.

Contents: The check · Allowed, Denied, Unknown · The policy map · In the details · What is evaluated · What Sextant answers "Unknown" for

The check

On the Check tab choose:

• Source: a Pod, Namespace and labels (a pod that would have these labels, such as app=web, tier=api), or an IP address outside the cluster.
• Destination: a Pod, a Service (and its port), Namespace and labels, or an IP address outside the cluster.
• Port (a number, or the name of a container port on the destination pod) and Protocol.

Press Check. The result has two sides, because both must allow the traffic:

• Egress from the source: is the source isolated for egress (does a policy with Egress select it)? If so, which rule of which policy allows the traffic, or that none does.
• Ingress to the destination: the same for ingress.

Each policy that selects a side is listed with its rules, whether each rule matches, and why not ("The pod's labels app=web do not match app=api", "Namespace shop has the labels … which do not match …", "The rule is for port 8080"). For a Service, the traffic is checked against every pod behind it at the target port ("Allowed to 2 of 3 pods behind the Service"); ExternalName Services and Services without a selector are explained.

Beside the answer Sextant checks DNS: when the source is isolated for egress and its policies do not allow UDP port 53 to kube-dns in kube-system, it cannot resolve names even where a connection is allowed (and a warning when only UDP, not TCP, is allowed).

You can also start a check from a pod's details: Check connectivity… fills in the pod as the source.

Allowed, Denied, Unknown

Answer	Means
Allowed	Both sides allow this traffic by the policies Sextant evaluated.
Denied	One side is isolated and none of its policies allow this traffic (or a deny rule matches).
Unknown	Sextant cannot tell from the objects. The reasons are listed.

Sextant never answers "Allowed" when it is not sure. Anything it cannot decide makes the answer Unknown — see below.

Pods using the host network are not subject to NetworkPolicy, and an address outside the cluster has no policy of its own side; the answer says so.

The policy map

The Policy map tab shows, for one namespace, which pods are isolated for ingress and for egress and by which policies, and what those policies allow, in words. Every NetworkPolicy's and Cilium/Calico policy's details have a Namespace policy map button that opens it.

In the details

• In plain words on every NetworkPolicy, CiliumNetworkPolicy, CiliumClusterwideNetworkPolicy and Calico NetworkPolicy / GlobalNetworkPolicy: which pods it selects, each rule as a sentence ("Pods matching app=web in namespace shop, on TCP port 8080"), rules that are ignored because policyTypes leaves them out, a policy that isolates and allows nothing, and a warning when it does not allow DNS.
• Network policies on every pod: isolated or not, for ingress and for egress, with the policies that select it, and Check connectivity….

What is evaluated

Policies	How
Kubernetes NetworkPolicy (networking.k8s.io/v1)	Exactly as the API defines it: policyTypes defaulting, rules ORed, peers ORed and ports ORed, a podSelector and namespaceSelector in one peer ANDed, ipBlock with except (IPv4 and IPv6), named ports resolved on the destination pod, endPort ranges.
Cilium (CiliumNetworkPolicy, CiliumClusterwideNetworkPolicy)	The L3/L4 subset: endpoint selectors, fromEndpoints/toEndpoints, CIDR rules, the entities all, world and cluster, ports, deny rules (which win over allows), enableDefaultDeny; note that in Cilium an empty rule ingress: [{}] matches nothing.
Calico (projectcalico.org/v3 NetworkPolicy and GlobalNetworkPolicy, or their crd.projectcalico.org CRDs)	The default tier: policies in order (Kubernetes NetworkPolicies count as order 1000), the first matching Allow or Deny rule decides, Log goes on; Calico's selector language, nets/notNets, ports and protocol.

The page watches only what a question needs: pods and policies of the namespaces you pick, Services where asked, namespaces' labels, cluster-wide policies, and the DNS pods.

What Sextant answers "Unknown" for

• A list it could not read (no permission to list pods or policies of a namespace, or namespaces' labels).
• An ipBlock that contains a pod IP: whether ipBlock applies to pod traffic depends on the network plugin.
• Features it does not model: Cilium L7 rules, toFQDNs, toServices, fromRequires, CIDR groups, authentication; Calico tiers other than default, Pass, service-account and service matches, network sets, http matches.
• Any object of a policy kind it does not evaluate, in its namespace (or everywhere, for a cluster-wide kind): AdminNetworkPolicy, BaselineAdminNetworkPolicy, ClusterNetworkPolicy, Antrea NetworkPolicy and ClusterNetworkPolicy, OVN-Kubernetes EgressFirewall and AdminPolicyBasedExternalRoute, GKE FQDNNetworkPolicy. These can deny what NetworkPolicies allow, so ignoring them would give a wrong "Allowed".
• Both Cilium and Calico policies selecting the same pod.
• Discovery failed, so which policy kinds exist is not known.

AI agents (through the MCP server) and Extensions get nothing new from this page.

Next: Using Sextant.