8

I'm a beginner in Kubernetes and I have a situation as following: I have two differents Pods: PodA and PodB. Firstly, I want to expose PodA to the outside world, so I create a Service (type NodePort or LoadBalancer) for PodA, which is not difficult to understand for me.

Then I want PodA communicate to PodB, and after several hours googling, I found the answer is that I also need to create a Service (type ClusterIP if I want to keep PodB only visible inside the cluster) for PodB, and if I do so, I can let PodA and PodB comminucate to each other. But the problem is I also found this article. According to this webpage, they say that the communication between pods on the same node can be done via cbr0, a Network Bridge, or the communication between pods on different nodes can be done via a route table of the cluster, and they don't mention anything to the Service object (which means we don't need Service object ???).

In fact, I also read the documents of K8s and I found in the Cluster Networking

Cluster Networking
...
2. Pod-to-Pod communications: this is the primary focus of this document.
...

where they also focus on to the Pod-to-Pod communications, but there is no stuff relevant to the Service object.

So, I'm really confusing right now and my question is: Could you please explain to me the connection between these stuff in the article and the Service object? The Service object is a high-level abstract of the cbr0 and route table? And in the end, how can the Pods can communicate to each other?

If I misunderstand something, please, point it out for me, I really appreciate that.

Thank you guys !!!

nxh6991
  • 377
  • 5
  • 13
  • if your podA needs to connect to the podB through a ClusterIP, the application doesn't need to know nothing about the cni used by the cluster. – c4f4t0r May 14 '20 at 19:47

4 Answers4

3

Motivation behind using a service in a Kubernetes cluster.

Kubernetes Pods are mortal. They are born and when they die, they are not resurrected. If you use a Deployment to run your app, it can create and destroy Pods dynamically.

Each Pod gets its own IP address, however in a Deployment, the set of Pods running in one moment in time could be different from the set of Pods running that application a moment later.

This leads to a problem: if some set of Pods (call them “backends”) provides functionality to other Pods (call them “frontends”) inside your cluster, how do the frontends find out and keep track of which IP address to connect to, so that the frontend can use the backend part of the workload?

That being said, a service is handy when your deployments (podA and podB) are dynamically managed.

Khalid K
  • 356
  • 2
  • 5
2

Your PodA can always communicate with PodB if it knows the address or the DNS name of PodB. In a cluster environment, there may be multiple replicas of PodB, or an instance of PodB may die and be replaced by another instance with a different address and different name. A Service is an abstraction to deal with this situation. If you use a Service to expose your PodB, then all pods in the cluster can talk to an instance of PodB using that service, which has a fixed name and fixed address no matter how many instances of PodB exists and what their addresses are.

Burak Serdar
  • 46,455
  • 3
  • 40
  • 59
  • Thank you for your answer, so my understand is the `cbr0` or `route table` that I mentionned in my question are the low-level in K8s, whereas the `Service` is a high-level that we, the programmers, can use to deal with the problem? Am I right, please? I'm sorry if I say something stupid but I just want to know if there is a relevance between these stuff or not. – nxh6991 May 14 '20 at 19:30
  • That is correct. k8s manages the routing table on the nodes to implement the high-level networking you should be using. The bridges, routing tables, etc. are the components of the underlying network. K8s implements a software-defined network using those primitives. As I said, you can reach pods directly without a service because the network is configured to support that, but service gives you a fixed name and address regardless of the location and name of the target pod. – Burak Serdar May 14 '20 at 19:39
0

First, I read it as you are dealing with two applications, e.g. ApplicationA and ApplicationB. Don't use the Pod abstraction when you reason about your architecture. On Kubernetes, you are dealing with a distributed system, and it is designed so that you should have multiple instances of your Application, e.g. for High Availability. Each instance of your application is a Pod.

Deploy your applications ApplicationA and ApplicationB as a Deployment resource. Then it is easy do do rolling upgrades without downtime, and Kubernetes will restart any instance of your application if it crash.

For every Deployment or for you, application, create one Service resource, (e.g. ServiceA and ServiceB). When you communicate from ApplicationA to another application, use the Service, e.g. ServiceB. The service will load balance your requests to the instances of the other application, and you can upgrade your Deployment without downtime.

Jonas
  • 121,568
  • 97
  • 310
  • 388
0

1.Cluster networking : As the name suggests, all the pods deployed in the cluster will be connected by implementing any kubernetes network model like DANM, flannel Check this link to see how to create a cluster network. Creating cluster network

With the CNI installed (by implementing cluster network), every pod will get an IP.

2.Service objects created with type ClusterIP, points to the this IPs (via endpoint) created internally to communicate.

Answering your question, Yes, The Service object is a high-level abstract of the cbr0 and route table.

You can use service object to communicate between pods. You can also implement service mesh like envoy / Istio if the network is complex.

Harika
  • 11
  • 4