This message was deleted.

I read in https://k3d.io/v5.4.1/usage/advanced/calico/?h=networkpolicy:

If you want to use NetworkPolicy you can use Calico in k3s instead of Flannel.

Which implies that when I don't use calico then network policies don't work. Is that correct?

Hey 👋 Exactly, K3s comes with pure Flannel by default, see also https://rancher.com/docs/k3s/latest/en/installation/network-options/ (it's a K3s config, not k3d)

Thanks for the quick response! I'm not familiar with all of these things yet, so I'll have to ask some basic questions. Are network policies not applied/in effect when using Flannel?

No, Flannel does not support Network policies. It's required to at least combine it with e.g. Calico to use Network policies. See the last section in "Networking Details" here: https://github.com/flannel-io/flannel

Thanks! 🙂

Can you provide any more details? Also, since this seems to be K3s itself, you may want to post to #k3s as well 👍

Ah ok, thanks! So the fact that I'm using k3d here should not really matter?

Key inside is still the same, yep. But I also don't know yet what issue you're having.

My frontend application (running in namespace

client

) logs this:

FetchError: request to <http://api.api.svc.cluster.local:8000/organizations> failed, reason: connect ECONNREFUSED 10.42.0.13:8000

My api (running in namespace

api

) has this network policy right now:

apiVersion: <http://networking.k8s.io/v1|networking.k8s.io/v1>
kind: NetworkPolicy
metadata:
  name: api-network-policy
  namespace: api
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Ingress
    - Egress
  ingress: []
#    - ports:
#        - protocol: TCP
#          port: 8000

My test here is to see what happened when I commented out the

ingress

-part of my network policy. With those lines commented out, the frontend gets a

connect ECONNREFUSED

then trying to talk with my api. --- When I have those lines not commented out (I'm recreating the local cluster just to be sure), my frontend is indeed able to communicate with the api. (i.e. it does not log that connect econnrefused-thing)

Yeah looks like others have been confused like me: https://github.com/k3s-io/k3s/issues/1308#issuecomment-620635948

Yeah, new for me as well as I never used it in k3d 🤷‍♂️

Thank you very much for your time!

You're welcome

I think we mention it in the docs, but we include the network policy controller from kube-router

Thorsten: Does it make sense to change the wording of https://k3d.io/v5.4.1/usage/advanced/calico/?h=networkpolicy%3A? I find

If you want to use NetworkPolicy you can use Calico in k3s instead of Flannel.

Confusing when network policies are actually enforced by default. Want me to submit a pr to change the wording?

Oh yes, I guess that makes sense. Also I saw it doesn't mention setting

--disable-network-policy

which is required to use Calico's NetworkPolicy functionality and disable the K3s' built-in one. I'll happily accept a PR🙂

https://github.com/k3d-io/k3d/pull/1081 - please feel free to nitpick

Usually only on tag/release, but I will update it manually

More off-topic, for my own curiosity: Is there a way to update docs for old versions? My change just now applies to multiple versions of k3d. Will my change be visible on multiple version docs? For ex these: • https://k3d.io/v5.4.3/usage/advanced/calico/ • https://k3d.io/v5.4.2/usage/advanced/calico/ • https://k3d.io/v5.4.1/usage/advanced/calico/ Or will it only be visible in the "latest" one?

It's active 👍

I see now that it's visible in https://k3d.io/v5.4.3/usage/advanced/calico/ but not in https://k3d.io/v5.4.2/usage/advanced/calico/. I guess that's ok 🙂

Change will only be active for the most recent version. It would require some Git Fu to update older versions

A shortcoming of mkdocs and similar that's hard to fix without a lot of complexity, I guess?

Well, docs are stored in the same repo as the code, meaning also versioned the same. To get your commit into the v5.4.1 docs for example, we would have to insert it just before/after the v5.4.1 tag, so it won't include v5.4.2 docs. Then use

mike

to re-deploy that version of the docs. Then rebase all the commits after that onto the newly inserted one.

Thanks!