Rajendra Rana's blog

#KubeWeek Day 2

Rajendra Rana's photo
Rajendra Rana
·

7 min read

  • Kubernetes Networking

  • Services, Ingress, Network Policies, DNS, and CNI (Container Network Interface) pluginis.

Service

a service is an abstraction that provides a stable network endpoint to a set of pods. Services enable communication between different parts of an application running within a Kubernetes cluster.
Services are defined by a YAML file that includes information such as the service name, the selector that identifies the pods the service should route traffic to, and the type of service (ClusterIP, NodePort, LoadBalancer, or ExternalName).

when using deployment, while updating the image version the pods are terminated and new pods take the place of other pods

Pods are very dynamic i.e. they come and go on the Kubernetes cluster and on any of the available nodes and it would be difficult to access the pods as the pod's IP changes once it's created.

A service object is a logical bridge between pods and end users, which provides a virtual IP address. (VIP)

A service allows clients to reliably connect to the containers running in the pod using the virtual IP address (VIP)

The virtual IP is not an actual IP connected to a network interface, but its purpose is to forward traffic to one or more pods.

kube-proxy is the one that keeps mapping between the VIP and Pods up to date, which queries the API server to learn about new services in the cluster.

although each pod has a unique IP address, those IPs are not exposed outside the cluster.

services help to expose the VIP mapped to the pods and allow the application to receive traffic.

Labels are used to select which pods to be put under a service.

Creating a service will create an endpoint to access the pods/application.

service can be exposed in different ways by specifying a type in the service specification.

kind: Service # Defines to create Service type Object

apiVersion: v1

metadata:

name: demoservice

spec:

ports:

  • port: 80 # Containers port exposed

    targetPort: 80 # Pods port

    selector:

    name: deployment # Apply this service to any pods which has the specific label

    type: ClusterIP # Specifies the service type i.e ClusterIP or NodePort

Types of Kubernetes Services:

  • Cluster IP

  • NodePort

  • LoadBalancer

  • ExternalName

bydefault service can run only between ports 30,000 - 32,767

the set of pods targeted by a service is usually determined by a selector.

Cluster IP

Exposes virtual IP only reachable from within the cluster.

Mainly used to communicate between components and microservices,

NodePort

Make a service accessible from outside the cluster.

Exposes the service on the same port of each selected node in the cluster using NAT

What is Ingress

Ingress is a Kubernetes resource that allows external traffic to access the applications running within a cluster. It acts as a reverse proxy and routes traffic to the appropriate Service based on the incoming request's hostname and path.

Ingress is implemented as a collection of rules that define how external traffic should be routed to the Services within a cluster. These rules are defined using Ingress resources, which are created and managed using the Kubernetes API.

Ingress Resource

An Ingress resource is a collection of rules that define how external traffic should be routed to the Services within a cluster. It consists of the following fields:

  • apiVersion: The API version of the Ingress resource.

  • kind: The kind of resource, which is Ingress in this case.

  • metadata: Metadata about the Ingress resource, including its name and namespace.

  • spec: The specification of the Ingress resource, including the rules for routing traffic.

    Here is an example of an Ingress resource that routes traffic to two different Services based on the incoming request's hostname:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: example.com
    http:
      paths:
      - backend:
          serviceName: service-1
          servicePort: 80
  - host: example.org
    http:
      paths:
      - backend:
          serviceName: service-2
          servicePort: 80

When do you need Ingress

You may need Ingress if you have multiple Services that need to be accessed from the outside world, or if you want to expose your application to the internet using a custom domain name.

For example, if you have a microservice-based application with multiple Services, you can use Ingress to route traffic to the appropriate Service based on the incoming request's hostname and path.

Network Policies

Kubernetes Network Policies are a powerful feature that allows you to control the traffic flow to and from Kubernetes pods. Network Policies are implemented using rules that define what traffic is allowed or denied between pods. This provides a way to enforce security policies and prevent unauthorized access to resources.

Network Policies are defined using a YAML file that specifies the allowed traffic flow between pods. The file contains a list of rules that specify the source and destination pods, protocols, ports, and other parameters. For example, you can create a Network Policy that allows traffic from a specific pod to access a database pod while denying traffic from all other pods.

Network Policies can be applied to a specific namespace or the entire cluster. They are enforced by a network plugin, such as Calico, that intercepts traffic and applies the policy rules. If traffic does not match a rule, it is denied by default.

Network Policies are particularly useful for securing microservices-based architectures, where each service runs in its pod and communicates with other services over the network. By using Network Policies, you can enforce strict security policies and prevent unauthorized access to sensitive data.

DNS

Kubernetes DNS is a built-in DNS service that provides name resolution for Kubernetes services and pods. It allows you to access Kubernetes services and pods by name instead of IP address, making it easier to manage and scale your applications.

Kubernetes DNS works by creating a DNS record for each Kubernetes service and pod. The DNS record is created using the service or pod name, along with the namespace and the cluster domain. For example, if you have a service named "web" in the "my-namespace" namespace, the DNS record for that service would be "web.my-namespace.svc.cluster.local".

Kubernetes DNS is integrated with the Kubernetes API server, which provides automatic updates to the DNS records as services and pods are created or deleted. This ensures that the DNS records are always up-to-date and accurate.

In addition to providing name resolution for Kubernetes services and pods, Kubernetes DNS also supports DNS-based service discovery. This allows you to discover services that are running in other namespaces or even in other clusters.

Kubernetes DNS is a critical component of Kubernetes networking, and it is essential for managing and scaling your applications. By using Kubernetes DNS, you can simplify your application architecture and make it easier to manage and scale your services and pods.

CNI Plugin

Kubernetes CNI (Container Network Interface) Plugin is a networking model that provides a standard interface for integrating networking solutions with Kubernetes. It enables Kubernetes to support multiple network providers and plugins, allowing users to choose the best networking solution for their specific needs.

CNI plugins allow Kubernetes to configure the networking for each pod at runtime. The CNI plugin is responsible for setting up the network interface for each pod and connecting it to the appropriate network. This includes assigning IP addresses, setting up routing tables, and configuring network security policies.

There are several CNI plugins available for Kubernetes, each with its own set of features and capabilities. Some of the most popular CNI plugins include Calico, Flannel, Weave Net, and Cilium.

Calico is a popular CNI plugin that provides network policy enforcement and secure network connectivity for Kubernetes. Flannel is another popular CNI plugin that provides simple, reliable network connectivity for Kubernetes. Weave Net is a CNI plugin that provides a network mesh for Kubernetes, enabling secure communication between pods and nodes. Cilium is a CNI plugin that provides network and security policies for Kubernetes, using eBPF technology for high-performance network filtering.

Conclusion:

Kubernetes networking is a complex and critical part of managing a cluster. Services, ingress, network policies, DNS, and CNI plugins are key concepts that every Kubernetes administrator should understand. By mastering these concepts, you can build scalable, secure, and resilient Kubernetes clusters that can handle any workload.

#KubeWeekChallenge Kubernetesnetworkingservicesingress