Home > OS >  In which cases do we need container networks in kubernetes while we already have kubernetes Service?
In which cases do we need container networks in kubernetes while we already have kubernetes Service?

Time:09-23

why do we need point-to-point connection between pods while we have workloads abstraction and networking mechanism(Service/kube-proxy/Ingress etc.) over it?

what is the default cni?

btw I see a lot of overlap features between istio and container networks, imo they can achieve identical objectives, the only difference is that isio is high-level and cni is low-level and more efficient, is that correct?

CodePudding user response:

Kubernetes networking has some requirements:

pods on a node can communicate with all pods on all nodes without NAT agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that node pods in the host network of a node can communicate with all pods on all nodes without NAT

and CNI(Container Network Interface) setup a standard interface, all implements(calico, flannel) need follow it.

So it aims to resolve the kubernetes networking.

The SVC is different, it's supplied a virtual address to proxy the pods, sine pods is ephemeral and its ip will changing but the address of svc is immutable.

For the istio, it's another thing, it make the connection between microservice as infrastructure and pull out this part from business code (think about spring cloud).

CodePudding user response:

why do we need point-to-point connection between pods while we have workloads abstraction and networking mechanism(Service/kube-proxy/Ingress etc.) over it?

In general, you will find everything about networking in a cluster in this documentation. You can find more information about pod networking:

Every Pod gets its own IP address. This means you do not need to explicitly create links between Pods and you almost never need to deal with mapping container ports to host ports. This creates a clean, backwards-compatible model where Pods can be treated much like VMs or physical hosts from the perspectives of port allocation, naming, service discovery, load balancing, application configuration, and migration.

Kubernetes imposes the following fundamental requirements on any networking implementation (barring any intentional network segmentation policies):

  • pods on a node can communicate with all pods on all nodes without NAT
  • agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that node

Note: For those platforms that support Pods running in the host network (e.g. Linux):

  • pods in the host network of a node can communicate with all pods on all nodes without NAT

Then you are asking:

what is the default cni?

There is no single default CNI in a kubernetes cluster. It depends on what type you meet, where and how you set up the cluster etc. As you can see reading this doc about implementing networking model there are many CNI's available in Kubernetes.

Istio is a completely different tool for something else. You can't compare them like that. Istio is a service mesh tool.

Istio extends Kubernetes to establish a programmable, application-aware network using the powerful Envoy service proxy. Working with both Kubernetes and traditional workloads, Istio brings standard, universal traffic management, telemetry, and security to complex deployments.

  • Related