Day 2 Tuesday of the KubeWeek Challenge

Introduction

Welcome to Day 2 of the KubeWeek Challenge!
Today, we’re diving into the crucial aspects of Kubernetes networking, services, ingress, and DNS. These components are the backbone of Kubernetes, enabling seamless communication between applications and the outside world. By the end of this post, you’ll have a solid understanding of how Kubernetes manages networking, how services expose your applications, how ingress controllers manage external traffic, and how DNS simplifies service discovery within your cluster.

What are Kubernetes Services?

In Kubernetes, services play a crucial role in ensuring reliable communication between different parts of your application. While pods in Kubernetes can have unique IPs, these IPs are not stable since pods are ephemeral and can be recreated at any time. Kubernetes services provide a stable endpoint that remains consistent regardless of the underlying pod changes.

Types of Services:

1. ClusterIP: The default service type. It exposes the service within the Kubernetes cluster. This is used for internal communication between services.
2. NodePort: This type of service exposes the service on each node’s IP at a specific port. It makes the service accessible from outside the cluster, but only on the nodes where Kubernetes is running.
3. LoadBalancer: This service type provisions an external load balancer (if your cloud provider supports it), which exposes the service to the internet with a single IP.
4. ExternalName: This service maps a service to a DNS name outside of the Kubernetes cluster.

What is Ingress?

Ingress in Kubernetes is used to manage external access to the services within your cluster, typically HTTP and HTTPS traffic. Unlike services, which expose applications within or outside of the cluster, ingress allows for more sophisticated routing and rules, such as SSL termination and load balancing.

Key Ingress Concepts:

• Ingress Controller: A Kubernetes resource that watches for changes in the ingress objects and implements the corresponding routing rules.
• Ingress Resource: A collection of rules that define how external traffic should be routed to services within the cluster.

An example of an ingress resource might look like this:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

Network Policies

Network policies in Kubernetes control the traffic flow to and from pods, acting as a firewall within the cluster. They define how pods are allowed to communicate with each other and other network endpoints.

Example Network Policies:

1. Allow Ingress Traffic: A policy that allows incoming traffic to a set of pods.
2. Deny Egress Traffic: A policy that blocks all outgoing traffic from a set of pods.

Example:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

2. Defining Ingress Rules

Ingress rules define how traffic should be routed to different services within your cluster.

• Example Ingress YAML:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

DNS (Domain Name System)

Kubernetes uses DNS to allow services and pods to discover each other by name, rather than IP address. The DNS system is managed by CoreDNS, which provides internal name resolution for the services within the cluster.

1. Check DNS Resolution:

To verify that DNS is functioning correctly, you can use the following command within a pod:

kubectl exec -it <pod-name> -- nslookup my-service

This checks whether the DNS name my-service resolves to the correct service IP.

2. Verify CoreDNS Pods:

Ensure that the CoreDNS pods are running properly by checking their status:

kubectl get pods -n kube-system -l k8s-app=kube-dns

3. View CoreDNS Logs:

If you suspect issues with DNS, viewing the CoreDNS logs can help diagnose problems:

kubectl logs -n kube-system -l k8s-app=kube-dns

CNI (Container Network Interface)

The Container Network Interface (CNI) is a standard for configuring network interfaces in Linux containers. Kubernetes relies on CNI plugins to manage the networking aspects of containers, such as assigning IP addresses to pods and setting up routes.

Popular CNI plugins include:

• Calico: Provides networking and network policy.
• Flannel: A simple overlay network.
• Weave: Offers a resilient and fast networking solution.

To deploy a CNI plugin, you typically apply a YAML manifest that configures the network for your cluster. For example, to deploy Calico:

kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

Conclusion

Conclusion

Kubernetes networking, services, ingress, DNS, and CNI are essential components that enable your applications to communicate efficiently and securely. Whether you’re routing traffic with an ingress controller or managing internal DNS resolution, understanding these elements is critical for building robust Kubernetes applications.

Keep following the KubeWeek Challenge as we continue to explore more advanced topics in the coming days!

#KubeWeek #TrainwithShubham #GauravBharane #K8s #Kubernetes