CoreDNS in Kubernetes : Day 30/31 of 40daysofkubernetes

Introduction

In a Kubernetes cluster, services and pods often need to communicate with each other. This requires reliable and efficient name resolution to convert service names into IP addresses. Without an effective DNS service, managing network traffic between various components in a dynamic environment like Kubernetes would be very complex and prone to errors.

This is where DNS comes in, acting as the backbone of service discovery within the cluster. It allows services to find and communicate with each other using easy-to-remember names instead of IP addresses that may change frequently. To handle these DNS needs, Kubernetes uses a dedicated DNS service, ensuring that services can interact seamlessly within the cluster.

Let's dive into CoreDNS, the DNS service that powers name resolution in Kubernetes clusters.

What is DNS?

The Domain Name System (DNS) is the backbone of the internet, responsible for translating human-readable domain names like amazon.com into machine-readable IP addresses like 142.250.72.14. This translation is crucial because, while humans prefer to remember names, computers need IP addresses to locate and communicate with each other.

How DNS Works: The amazon.com Example

When you type amazon.com into your browser and hit enter, a series of steps happen behind the scenes to translate that domain name into an IP address:

1. Browser Cache Check: Your browser first checks its cache to see if it already knows the IP address for amazon.com. If it finds it, the request is sent directly to that IP address.

2. Operating System Cache Check: If the browser cache doesn't have the IP address, the operating system checks its own cache.

3. DNS Resolver Query: If the IP address isn't cached locally, the request is sent to a DNS resolver, typically provided by your ISP (Internet Service Provider).

4. Recursive Query: The DNS resolver performs a recursive query, where it asks multiple DNS servers to resolve the domain name:

   • Root Name Server Query: The resolver first contacts one of the 13 root name servers. These servers don't know the IP address of amazon.com, but they can direct the resolver to the correct Top-Level Domain (TLD) server, in this case, the .com TLD server.

   • TLD Name Server Query: The resolver then queries the .com TLD server, which doesn't have the IP address either but knows the authoritative DNS server for amazon.com.

   • Authoritative DNS Server Query: Finally, the resolver queries the authoritative DNS server for amazon.com, which provides the IP address.

5. Return IP Address: The resolver sends the IP address back to your browser.

6. Browser Requests Webpage: Now that the browser has the IP address, it sends a request to that server to fetch the webpage.

7. Page Loads: The server sends the webpage data back to your browser, and the page loads.

How DNS Servers Handle Billions of IP Addresses

The DNS system is designed to be hierarchical and distributed, allowing it to efficiently manage and resolve billions of IP addresses. Here’s how it works:

• Hierarchical Structure: DNS is organized in a hierarchy with different levels, starting from the root name servers at the top, followed by TLD servers (like .com, .net, .org), and finally, the authoritative DNS servers for specific domains.

• Caching: DNS resolvers and servers cache responses for a certain period (Time to Live - TTL). This reduces the load on DNS servers by reusing recent responses for repeated queries, preventing the need to perform the full resolution process every time.

• Distribution of Load: The DNS system distributes the query load across multiple servers. For instance, the root name servers work together to handle the initial query routing but do not need to know every single IP address.

13 Root Name Servers: The Foundation of DNS

There are 13 root name servers globally, labeled A through M. These servers don’t actually consist of just 13 machines; each one is a network of multiple servers located in different parts of the world.

• Load Balancing: The 13 root name servers act as load balancers, distributing DNS queries across their network of servers. This ensures high availability and fault tolerance, making the DNS system robust and capable of handling the immense traffic of the global internet.

• Anycast Routing: These servers use a technique called anycast, where multiple servers share the same IP address. When a DNS resolver sends a query to a root name server, it is routed to the nearest server in the anycast network, reducing latency and improving speed.

Types of DNS Records

DNS records are used to define the rules for translating domain names into IP addresses. The most common types of DNS records are:

1. A Record (Address Record):

   • Purpose: Maps a domain name to an IPv4 address.

   • Example: example.com -> 192.0.2.1

   • Use Case: Directs users to a specific server using an IPv4 address when they type the domain name.

2. AAAA Record (IPv6 Address Record):

   • Purpose: Maps a domain name to an IPv6 address.

   • Example: example.com -> 2001:0db8:85a3:0000:0000:8a2e:0370:7334

   • Use Case: Same as an A record, but used for IPv6 addresses instead of IPv4.

3. CNAME Record (Canonical Name Record):

   • Purpose: Maps one domain name to another domain name.

   • Example: www.example.com -> example.com

   • Use Case: Used for domain name aliases, where multiple domain names should resolve to the same IP address.

You can learn more about the DNS form here.

CoreDNS in Kubernetes

CoreDNS is a flexible, extensible DNS server that can serve as the DNS server for Kubernetes clusters. It is the default DNS service for Kubernetes since version 1.13, replacing kube-dns. CoreDNS is responsible for translating domain names (like my-service.my-namespace.svc.cluster.local) into IP addresses, enabling service discovery within the Kubernetes cluster.

How CoreDNS Works in Kubernetes

• Service Discovery: CoreDNS uses the Kubernetes API to automatically discover services and create DNS records for them. For example, when you create a service in Kubernetes, CoreDNS automatically updates its DNS records to reflect the new service, allowing other services and pods to discover it using its DNS name.

• DNS Resolution: When a pod inside the cluster needs to communicate with a service, it queries CoreDNS, which resolves the service name to the corresponding IP address, allowing communication between pods.

• Plugins: CoreDNS is highly modular, and its functionality can be extended through plugins. Some common plugins include kubernetes (which enables service discovery in Kubernetes), forward (which forwards DNS queries to an external DNS server), and cache (which caches DNS responses to improve performance).

Example

Here’s an example to demonstrate how CoreDNS enables service discovery in Kubernetes:

1. Create Pods and Services: Deploy two nginx pods and two services using the following manifest.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: frontend
  labels:
    role: frontend
spec:
  containers:
    - name: nginx
      image: nginx
      ports:
        - name: http
          containerPort: 80
          protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: frontend
  labels:
    role: frontend
spec:
  selector:
    role: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
---
apiVersion: v1
kind: Pod
metadata:
  name: backend
  labels:
    role: backend
spec:
  containers:
    - name: nginx
      image: nginx
      ports:
        - name: http
          containerPort: 80
          protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: backend
  labels:
    role: backend
spec:
  selector:
    role: backend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

2. Test Service Communication:

3. Once the services are up and running, execute a shell into the frontend pod and try to curl the backend service using its ip-address:

4. Now try to curl the backend service using its name:

The output confirms that CoreDNS successfully resolves the service name to its corresponding IP address, allowing seamless communication between the frontend and backend services.

Use Cases of CoreDNS in Kubernetes

1. Service Discovery: CoreDNS enables services within the Kubernetes cluster to discover and communicate with each other using service names. For example, a frontend service can easily connect to a backend service using its DNS name, backend-service.default.svc.cluster.local.

2. Custom DNS Resolution: You can configure CoreDNS to resolve custom domain names within your cluster, enabling you to create internal DNS records for non-Kubernetes services or external services.

3. Forwarding and Conditional Forwarding: CoreDNS can be configured to forward queries for specific domains to an external DNS server. This is useful if you need to resolve DNS names that are not managed by Kubernetes, such as company-internal domains.

4. Metrics Collection: CoreDNS exposes metrics in Prometheus format, allowing you to monitor DNS query performance, errors, and other statistics. This is crucial for maintaining the health and performance of your cluster’s DNS infrastructure.

5. DNS Caching: CoreDNS can cache DNS responses, reducing latency and load on upstream DNS servers. This is particularly beneficial in large clusters with frequent DNS queries.

6. Load Balancing: CoreDNS can distribute DNS queries across multiple backend servers, which helps in improving DNS query performance and providing redundancy

Example Use Case: Service Communication

Suppose you have a microservices-based application running in Kubernetes with multiple services (e.g., frontend, backend, and database). Each of these services is deployed as a Kubernetes Service. CoreDNS automatically manages DNS records for these services.

• The frontend service can communicate with the backend service by simply using the DNS name backend.default.svc.cluster.local.

• CoreDNS resolves this name to the IP address of the backend service, facilitating seamless communication between the two services.

Conclusion

CoreDNS plays a critical role in Kubernetes clusters, enabling service discovery and DNS resolution, which are essential for the communication between services. Its modular and extensible nature allows for a wide range of use cases, from simple DNS resolution to complex custom DNS setups within the cluster.

Resources I used