Trusted answers to developer questions
Trusted Answers to Developer Questions

Related Tags

networking
kubernetes
communitycreator
containers
microservices

What is networking in Kubernetes?

Educative Team

Grokking Modern System Design Interview for Engineers & Managers

Ace your System Design Interview and take your career to the next level. Learn to handle the design of applications like Netflix, Quora, Facebook, Uber, and many more in a 45-min interview. Learn the RESHADED framework for architecting web-scale applications by determining requirements, constraints, and assumptions before diving into a step-by-step design process.

Answers Code

Overview

When working with Kubernetes, we have different microservices running in different containers.

Containers and microservices

Now, these different containers might be part of the same pod or present in different pods. Very often these microservices need to interact with each other. This is where the concept of networking comes into place.

Networking

We’ll be taking a look at networking in two situations in this article:

  1. Pod internal
  2. Between different pods

We have already learned a bit about a Kubernetes service in a previous shot.

To give you a brief recap, services in K8s (Kubernetes) gives us a stable IPInternet Protocol address that doesn’t change all the time. And they also can be configured to allow access from the outside world, which is not possible by default.

Modifying the env. variable to run microservices

  • Let’s assume that microservice A is requesting microservice B.

  • If microservice B is running locally on port 5000, the code in microservice A will look something like this:


const response = await axios.get(`http://localhost:5000/something/`);

The example above is in JavaScript, but the concepts discussed will be true regardless of the language and framework you use.


  • Since we aren’t running the microservices locally, let’s modify the code to use an environment variable:

const response = await axios.get(`http://${process.env.SOME_ADDRESS}/something/`);

Communication in pod internal

Let’s say that the two different containers are running in the same pod. The change we have to make in this case is fairly simple. For pod internal communication, K8s allows us to send a request to the localhost address. You would use localhost as a value for the environment variable SOME_ADDRESS.

Communication between different pods

When an app running in one pod has to request another app in another pod, the situation gets trickier. There are three different values we can use for the SOME_ADDRESS environment variable in this case.

Let’s have a look at them one by one.

1. Using ClusterIP


kubectl get services

  • If we run the code above, we will be able to see all the services currently running in our K8s cluster.

  • In the output of this command, there will be a column titled ClusterIP. This would show you the IP Address you can use to reach that service from inside the cluster.

  • Since pods are inside the cluster, they would have no problem using this IP Address. We can use the IP address of the service we want to reach as the value of the SOME_ADDRESS environment variable.

  • Manually finding the address each time can be a bit cumbersome, so let’s look at a better way of doing so.

2. Using automatically generated environment variables

  • Kubernetes automatically generates environment variables, which we can directly use in our code, that have info about all the services running in our cluster.

  • The pattern for these generated variables is based on the name of the service. If your service has the name some-service, then the generated environment variable for that would be: SOME_SERVICE_SERVICE_HOST.

  • You take your service name, make it all caps, replace - with _ and add _SERVICE_HOST in the end.

  • The code snippet above would now look like this:


const response = await axios.get(`http://${process.env.SOME_SERVICE_SERVICE_HOST}/something/`);

3. Using CoreDNS

  • K8s clusters, by default, come with a built-in service called CoreDNS. This is a Domain Name Service (DNS), which helps create domain names.

  • Here we’re talking about cluster internal domain names. These can’t be used outside the cluster but are perfect for inter-pod communication.

  • CoreDNS creates domain names such as:


"service name" + "." + "namespace the service is a part of"

By default, our deployments and services get assigned to the default namespace unless we specify otherwise. So, in this case, the value for our environment variable would be: some-service.default.

Conclusion

And this is it! You can now facilitate communication between different microservices successfully regardless of whether or not they are in the same pod.

RELATED TAGS

networking
kubernetes
communitycreator
containers
microservices
Copyright ©2022 Educative, Inc. All rights reserved

Grokking Modern System Design Interview for Engineers & Managers

Ace your System Design Interview and take your career to the next level. Learn to handle the design of applications like Netflix, Quora, Facebook, Uber, and many more in a 45-min interview. Learn the RESHADED framework for architecting web-scale applications by determining requirements, constraints, and assumptions before diving into a step-by-step design process.

Answers Code
Keep Exploring