Prevent inter-namespace communication in Kubernetes

Do I need a networking plugin, such as Calico, Flannel or Weave?

No matter what you need a networking plugin, but not all plugins support the NetworkPolicy API object. According to the Declare Network Policy walkthrough, the following is a (probably non-exhaustive) list of plugins that do support NetworkPolicy:

• Calico
• Cilium
• Kube-router
• Romana
• Weave Net

Without a plugin that supports NetworkPolicy, creating the resource would have no effect.

Which one should I choose?

As for which one you should choose, stackoverflow is not the place for soliciting that kind of advice. What I can recommend is reading the overview/features documentation for the various options available. Maybe try one or two different plugins in a local development cluster to get a feel for how difficult or easy they are to install, maintain, and update.

How can I allow all network traffic, but only within a particular namespace?

Given your example setup, I think the following NetworkPolicy resources would address your need:

For pods in namespace-a, only allow ingress from namspace-a pods, denying ingress from any other source. Egress is unrestricted:

apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata:  name: test-network-policy  namespace: namespace-aspec:  policyTypes:  - Ingress  podSelector: {}  ingress:  - from:    - namespaceSelector:        matchLabels:          name: namespace-a

For pods in namespace-b, only allow ingress from namspace-b pods, denying ingress from any other source. Egress is unrestricted:

apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata:  name: test-network-policy  namespace: namespace-bspec:  policyTypes:  - Ingress  podSelector: {}  ingress:  - from:    - namespaceSelector:        matchLabels:          name: namespace-b

Note that this assumes you have set the name: namespace-a and name: namespace-b labels on your namespaces, similar to this:

apiVersion: v1kind: Namespacemetadata:  name: namespace-a  labels:    name: namespace-a    other: labelname

I only point this out to avoid confusing you with regard to the fact that the labels I showed above happen to match up with your hypothetical namespace names. The labels can be arbitrary and potentially inclusive of mulitple namespaces -- for example you might have namespace-a and namespace-c both with a label called other: labelname which would allow you to select multiple namespaces using a single namespaceSelector in your NetworkPolicy resource.