Hi, sometimes there is a delay (about 1~10 minutes) in apply network policy to new Pods in my k3s cluster (they runs v1.25.4+k3s1). how can i fix/research this?

Ask yourself: • what cni am I using • Is it network policies specifically provided by the cni • Did you disable the kube-proxy to let the cni handle this Kubernetes component • What version of iptables is on the os - iptables have been giving problems before • Look at the k3s logs via e.g. journalctl on the worker on where the pod to be applied the network policy is running

I’m using flannel that bundled in k3s, with

wireguard-native

backend. theres no external cni, and k3s flannel should providing network policy engine out-of-the-box and also not need to disable kube-proxy (please correct me if its wrong). iptables:

iptables v1.8.7 (nf_tables)

, Ubuntu 22.04 there is no additional info on

journalctl -u k3s-agent

. when I running

date; while ! echo</dev/tcp/redis/6379; do date; sleep 10; done ; date; echo "succeess"

and container’s log is this:

(strip)
Tue Dec 27 12:02:28 UTC 2022
bash: connect: Connection refused
bash: /dev/tcp/redis/6379: Connection refused
Tue Dec 27 12:02:39 UTC 2022

Tue Dec 27 12:02:49 UTC 2022
succeess

that time’s

k3s-agent

log is only

level=debug msg="cgroupv2 io stats: skipping over unmappable dbytes=0 entry"

,

level=debug msg="cgroupv2 io stats: skipping over unmappable dios=0 entry"

,

level=debug msg="Wrote ping"

, even I enabled

--debug

flag.

So you have default rule of deny all .. that’s why there’s a connection refused to redis in the container logs?

So you have default rule of deny all .. that’s why there’s a connection refused to redis in the container logs?

And then up til 10 minutes later the connection goes through because you have a rule that opens up the connection to redis?

thats right, redis have a ingress NetworkPolicy that only allows connections from app.

What about just general journalctl - any useful info?

there is no useful info…

I can read that flannel do actually not robustly support network policies.

You would need to combine flannel with calico to bring you > https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel - canal

I considered to use another CNIs, but it means I need to install calico separately, but I want to keep simple (k3s only needs

curl | sh

with some env vars for install; thats one of reasons to use k3s), so I prefer to resolve this with k3s-included flannel/network policy provider if possible… but I will take a look again, thanks.

I can understand why you want to keep things simple … but if they don’t work with what you have they’re simply not working 😄