scope-probe appears to have connection to everything

[rade]

I wonder whether this is somehow a consequence of #1863 and associated DNS tracking PRs.

[2opremio]

@rade Where did this happen? Do you have a report?

[rade]

just look at the kube-system namespace in Weave Cloud Dev in Weave Cloud Dev.

[2opremio]

The probes are doing a good job tagging the containers as being in the host network and tagging the pause container as not making connections

so, I am suspecting a regression on #1653 (or perhaps #1597 )

[2opremio]

I found out what's happening. We are taking Pod IPs as unique when matching short-lived connections against them. This is perfectly fine for pods using their own networking namespace like the following:

However, pods in the host networking namespace inherit their IP from the host. For instance:

This causes Scope to attribute all the host connections to a single POD running in the host networking namespace.

No regression here, this has been broken since we started tracking POD connections.

The way to fix this is to check whether the pod runs in the host networking namespace to discard the short-lived connections from/to its IP. Unfortunately, this will also discard legitimate short-lived connections coming from the POD.

[rade]

Hmm. We should be able to disambiguate these connections, and "assign" them to the right pod, by taking into account the port - the IP+port combo of the source of outbound connections and the destination of inbound connections should be associated with an individual process, which in turn will give us the pod.

[2opremio]

We don't have PIDs for short-lived connections. So we have the exact same problem for Pods as we have for containers.

In other words, we can't currently disambiguate them. ebpf should change this.

[2opremio]

You have a more thorough explanation in #1260