Day 32/40 Days of K8s: Networking in Kubernetes !!

In Kubernetes, networking plays an important role in managing containerized applications.

Before heading into the topic, these are some common questions that everybody will have with respect to networking in kubernetes.

❓Who assigns IP address to pods

❓How pod-pod communication happens if on same node or different nodes

❓How service discovery happens and who facilitate this

❓How and who takes care of networking within the cluster

Let's understand with an Example...

When a user initiates a command like kubectl run nginx --image=nginx, a chain of events happens within the Kubernetes cluster. The API server receives the command, sends to scheduler which is responsible for deciding which node in the cluster should host the new pod, taking into account factors like resource availability and node constraints,Taints and Tolerations, Nodeaffinity and antiaffinity etc…

Once the scheduler has made its decision, it communicates with the kubelet running on the chosen node.The kubelet is an agent that manages the lifecycle of pods on its node. It interacts with the Container Runtime Interface (CRI) to request the container runtime, such as containerd,CRIO or Docker, to create and start the container.

The container runtime, in turn utilizes runc, a low-level container runtime to handle the actual creation and execution of the container. Once the container is up and running, the container runtime passes the networking configuration task to the Container Network Interface (CNI) plugin. The CNI plugin sets up the network interface for the container, connecting it to the cluster network.

Networking is further managed by kube-proxy, which ensures that network traffic is correctly routed to the appropriate pods based on service definitions. CoreDNS (or kube-dns) provides DNS resolution within the cluster, allowing pods to communicate with each other using service names.

K8S Networking

• Container - Container communication: Two containers in a same pod can talk to each other using local host , as they share the same IP address of underlying host (which is pod IP).
  Example: sidecar container(prometheus), nginx container

  Create a multi-container-pod with two containers: one running nginx and another running busybox using this yaml

    apiVersion: v1
    kind: Pod
    metadata:
      name: multi-container-pod
      labels:
        app: multi-container
    spec:
      containers:
      - name: nginx-container
        image: nginx:latest
        ports:
        - containerPort: 80
      - name: busybox-container
        image: busybox:latest
        command: ['sh', '-c', 'while true; do echo hello from the busybox; sleep 10; done']
  

  

  Test communication between the containers using localhost, you can exec into one of the containers and ping the other container's service

  

Pod-Pod - Same/different node: In k8's, pods can talk to each other using their respective IP addresses be it on same nodes or different nodes.

• Each pod will have unique IP address , in case of multi pods it gets unique IP from the CIDR network range of pod.

• The Container Network Interface (CNI) is a set of standards and plugins that manage network configuration for Pods. It ensures each Pod gets its IP address and handles connectivity between Pods.

• The communication between pods on different nodes is facilitated by the CNI plugin installed in the cluster.
  Common CNI plugins include Calico, Flannel, Weave, and Cilium.

• These plugins create an overlay network that allows pod-to-pod communication across different nodes.
  Example: nginx pod, busy box pod within same node , alpine,busybox and nginx pod on different nodes

Create three pods (nginx, busybox, and alpine) and expose them via a ClusterIP service in Kubernetes.

Test Pod-to-Pod Connectivity Using Pod IPs:

Exec into one of the pods (e.g: busybox) and use wget or curl to test connectivity to another pod using its IP.

Test Pod-to-Service Connectivity

In k8's, pods are ephemeral and they get new IP every time when they come up, so service is used as static IP that will expose or route traffic to pods.

SVC - acts like static IP(endpoint), load balancer, SVC discovery

How does Service discovery happens ?

1. Selectors and labels: Service use these to identify which are its targets pods/backends.

2. Kube-proxy: Responsible for svc discovery and networking to route the traffic to the pods from svc.

To test connectivity between the alpine pod and the nginx service, use the service name instead of the pod IP address

Now, use the service Cluster IP address on it's port instead of service name.

External traffic access to service in the cluster

In order to expose an application to outside world we have 2 choices: Ingress and Service.

1. Service: Expose your applications to outside but it creates load balancer for each service(in case of cloud) and allocates external-IP which costs more, doesn't offer enterprise level capabilities like (Advanced load balancing ad routing techniques, WAF, SSL/TLS, DDOS, API's..etc)

2. Ingress: Efficiently manages incoming traffic from outside world, distribute incoming traffic to pods, Ingress controller implements ingress rules defined in ingress resource.

   This method helps to manage the traffic flowing in and out from k8s cluster, we will explore ingress in next coming video.

Conclusion :

K8s networking is essential to understand and CNI is responsible for implementing networking. Each pod gets unique IP and CNI ensures pod to pod communication happens seamless within the cluster.

So, to restrict this standard behaviour of pod-pod communication using IPs, we have network policies in place where it restricts or allow communication between pods to pods, namespaces to namespaces and application to application.

#Kubernetes #Kubeadm #Networking #40DaysofKubernetes #CKASeries