Kubernetes Networking

Topics Are:

Services, Ingress, Network Policies, DNS, CNI Plugins

Services

Services provide a way to expose a set of pods to the network. A service is an abstract way to expose an application running on a set of Pods as a network service. A Service can be exposed in a variety of ways such as ClusterIP, NodePort, and LoadBalancer.

ClusterIP Service

ClusterIP Services are used for communication between Pods within the same Kubernetes cluster.

The Service gets exposed on a static IP that's unique within the cluster. When you make a request to that IP, the Service takes care of redirecting traffic to one of the Pods it's associated with. And if there's more than one Pod, the Service will automatically balance the traffic, so no single Pod gets bogged down by too many requests.

Here is an example of a .yaml file describing a ClusterIP Service object:

apiVersion: v1
kind: Service
metadata:
 name: nginx-clusterip
spec:
 type: ClusterIP
 selector:
   run: app-nginx
 ports:
 - port: 80
   protocol: TCP        

This YAML file defines a Kubernetes Service object of type ClusterIP. Below is an explanation of the important fields in the file:

• kind:?Specifies the type of Kubernetes object that is being defined. Here we are defining a Service.
• name:?Specifies the name of the Service, in this case, "nginx-clusterip".
• type:?Specifies the type of Service, in this case, a ClusterIP Service.
• selector:?Specifies a label selector that defines which Pods should be exposed by this Service. In this example, the Service will expose all Pods that have the label "run" with the value "app-nginx". It's a way of telling Kubernetes: "This Service should sit 'in front' of this collection of Pods. All incoming traffic to this Service should be redirected to one of these Pods."
• port:?Specifies the network port that the Service should expose. In this example, the Service exposes port 80.

NodePort Service

The NodePort Service is useful when you need to?expose your application to external clients. This means all traffic that is coming from?outside of the cluster.

When you create a NodePort Service, Kubernetes opens a port (in the range of 30000 and 32767) on all of its worker nodes. Note that the same port number is used across all of them. All traffic incoming to the worker node's IP address, and that specific port, is redirected to a Pod linked with that Service.

apiVersion: v1
kind: Service
metadata:
 name: nginx-nodeport
spec:
 type: NodePort
 selector:
   run: app-nginx
 ports:
 - nodePort: 30001
   port: 80
   targetPort: 80        

This YAML file defines a Kubernetes Service object of type "NodePort". The "selector" block instructs the NodePort Service to send incoming traffic to one of the Pods with this label. In this case, the "run: app-nginx" label.

In the "ports" block, we have defined three ports:

• nodePort:?Tells Kubernetes which port to "open" to the outside world on all of the worker nodes. This makes them accept incoming connections, from outside the cluster, on the port we chose here, 30001.
• port:?Specifies the port that should be "open" to the cluster, internally. Incoming connections will be accepted on this port, only if they come from within the cluster. External connections won't be accepted on this port.
• targetPort:?The Service will forward incoming connections to one of the Pods it exposes. "targetPort" specifies on which port of the Pod to send traffic to. E.g., with this config, even if traffic comes to port 30001 on the node, it will be?sent to port 80 of the Pod?(the "targetPort").

LoadBalancer Service

A LoadBalancer Service is another way you can?expose your application to external clients. However,?it only works when you're using Kubernetes on a cloud platform that supports this Service type.

The LoadBalancer Service detects the cloud computing platform on which the cluster is running and creates an appropriate load balancer in the cloud provider’s infrastructure. The load balancer will have its own unique, publicly accessible IP address. For example, if the cluster is running on?Amazon Web Services?(AWS), the Service will create an Elastic Load Balancer (ELB) to distribute incoming traffic across multiple nodes in the cluster.

apiVersion: v1
kind: Service
metadata:
 name: nginx-load-balancer
spec:
 type: LoadBalancer
 selector:
   run: app-nginx
 ports:
 - port: 80
   targetPort: 80        

This LoadBalancer Service will be named "nginx-load-balancer". The traffic it receives on?port: 80?will be sent to one of the Pods labeled?run: app-nginx, on?targetPort: 80?of those Pods.

ExternalName Service

An ExternalName Service in Kubernetes is useful when you have a service that is running outside your Kubernetes cluster, such as a database, and you want to access it from within your cluster.

apiVersion: v1
kind: Service
metadata:
 name: db-prod
spec:
 type: ExternalName
 externalName: db-prod.example.com         

The following is an explanation of the key fields:

• name:?This field specifies the name of the Service object, in this case, "db-prod".
• type:?This field specifies the type of Service. In this case, the value is "ExternalName", indicating that this Service maps to an external service, not a service inside the Kubernetes cluster.
• externalName:?This field specifies the location at which that external service can be reached at, in this case, "db-prod.example.com".

Kubernetes Ingress

It is the same in the Kubernetes world as well. Ingress means the traffic that enters the cluster and egress is the traffic that exits the cluster.

Ingress is a native Kubernetes resource like pods, deployments, etc. Using ingress, you can?maintain the DNS routing configurations. The ingress controller does the actual routing by reading the routing rules from ingress objects stored in etcd.

Kubernetes Ingress Resource

The Kubernetes Ingress resource is a native kubernetes resource where you specify the DNS routing rules. This means, that you map the external DNS traffic to the internal Kubernetes service endpoints.

It requires an ingress controller for routing the rules specified in the ingress object. Let’s have a look at a very basic ingress resource.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  namespace: dev
spec:
  rules:
  - host: test.apps.example.com
    http:
      paths:
      - backend:
          serviceName: hello-service
          servicePort: 80        

The above declaration means, that all calls to?test.apps.example.com?should hit the service named?hello-service?residing in the dev namespace.

As you can see, all it has is routing rules. You can add multiple routing endpoints for path-based routing, you can add TLS configuration, etc.

Kubernetes Network Policies

This is?Kubernetes?assets that control the traffic between?pods. Kubernetes network policy lets developers?secure?access to and from their applications. This is how we can?restrict?a user for access.

Any request that is successfully?authenticated?(including an anonymous request) is then?authorized. The default?authorization?mode is?always?allowed, which allows all?requests. In Kubernetes, you must be?authenticated?(logged in) before your request can be?authorized?(granted permission to access).

Network Policy In Pods

All Pods in Kubernetes communicate with each other which are present in the cluster. By default all Pods are?non-isolated?however Pods become?isolated?by having a Kubernetes Network Policy in Kubernetes. Once we have it in a?namespace?choosing a specific pod, that will restrict all the incoming and outing traffic of the pods.

Network Policy Specification

PodSelector –?Each of these includes a?pod selector?that selects the grouping of pods to which the policy applies. This selects particular Pods in the same namespace as the Kubernetes Network Policy which should be allowed as ingress sources or egress destinations.

Policy Types –?indicates which sorts of arrangements are remembered for this approach,?Ingress,?or?Egress.

Ingress –?Each Network Policies may include a list of allowed ingress rules. This includes inbound traffic whitelist rules.

Egress –?Each Network Policy may include a list of allowed egress rules. This includes outbound traffic whitelist rules.

DNS :

Kubernetes creates DNS records for Services and Pods. You can contact Services with consistent DNS names instead of IP addresses. Kubelet configures Pods' DNS so that running containers can lookup Services by name rather than IP.

CNI PLUGINS:

Container Network Interface, a Cloud Native Computing Foundation venture, comprises of detail and?libraries?for writing plugins to configure network interfaces in?Linux containers

• Kubernetes?1.25 supports Container Network Interface (CNI)?plugins?for cluster?networking. You must use a?CNI?plugin that is compatible with your cluster and that suits your needs. Different?plugins?are available (both open- and closed- source)?in?the wider?Kubernetes?ecosystem. A?CNI?plugin is required to implement the?Kubernetes?network model.

Thanks For Reading!!!!!