CoreDNS Architecture in OpenShift Explained

techhadoop OCP

DNS in OpenShift Container Platform (OCP) is a critical, multi-layered service that handles internal service discovery, external traffic routing, and cluster node resolution.

OpenShift uses a CoreDNS-based operator architecture that runs as a managed service across all nodes.

1. High-Level Architecture

The OpenShift DNS stack consists of three distinct layers:

 ┌─────────────────────────────────────────────────────────────┐
 │                         Pod Level                           │
 │             /etc/resolv.conf -> Node IP / CoreDNS           │
 └──────────────────────────────┬──────────────────────────────┘
                                │
                                ▼
 ┌─────────────────────────────────────────────────────────────┐
 │                 Cluster DNS Layer (CoreDNS)                 │
 │            DaemonSet in openshift-dns Namespace             │
 └──────────────┬───────────────────────────────┬──────────────┘
                │ Internal Queries              │ External Queries
                ▼                               ▼
 ┌─────────────────────────────┐  ┌─────────────────────────────┐
 │   Kubernetes API / Services │  │  Upstream / Host Node DNS   │
 │   (.cluster.local domains)  │  │  (e.g., 8.8.8.8 / Corporate)│
 └─────────────────────────────┘  └─────────────────────────────┘
  1. DNS Operator (dns.operator.openshift.io): Manages the lifecycle, configuration, and scaling of CoreDNS across the cluster.
  2. CoreDNS DaemonSet: Runs a CoreDNS pod on every worker and control-plane node in the openshift-dns namespace, listening on port 53 of the host’s loopback or node interface.
  3. Upstream Resolution: For non-Kubernetes domains (like google.com or corporate database endpoints), CoreDNS forwards the request to the node’s underlying host DNS resolution settings (/etc/resolv.conf).

2. Internal Service Discovery Naming Scheme

When pods communicate within OpenShift, DNS automatically maps service names to their corresponding cluster virtual IPs (ClusterIP).

A. Standard Service DNS Names

Format: <service-name>.<namespace-name>.svc.cluster.local

  • Same Namespace: A pod in prod can reach the service frontend by simply referencing http://frontend.
  • Cross Namespace: A pod in dev can reach the service frontend in prod using [http://frontend.prod.svc.cluster.local](http://frontend.prod.svc.cluster.local).
B. Headless Services (StatefulSets)

For stateful workloads (like databases or Kafka brokers) where pods need individual network identities, a Headless Service returns the individual pod IPs directly instead of a single Virtual IP.

Format: <pod-name>.<service-name>.<namespace-name>.svc.cluster.local

Example:kafka-0.kafka-service.messaging.svc.cluster.local

3. How Pods Resolve DNS Queries

When a container inside an OpenShift pod makes a network request:

  1. Pod resolv.conf Check: The pod inspects its local /etc/resolv.conf file, which is injected automatically by kubelet:
    nameserver 172.30.0.10 # Cluster DNS Virtual IP search <namespace>.svc.cluster.local svc.cluster.local cluster.local options ndots:5
  2. Search Domain Appending (ndots:5): If a query contains fewer than 5 dots (e.g., api-service), CoreDNS sequentially appends the search domains (e.g., trying api-service.my-namespace.svc.cluster.local first).
  3. CoreDNS Lookup: The request hits the local node’s CoreDNS instance.
    • If the domain ends in .cluster.local, CoreDNS resolves it using internal Kubernetes service records.
    • If the domain is external, CoreDNS forwards it to the upstream DNS servers defined on the underlying RHCOS host.

4. Customizing Cluster DNS

You do not edit Corefile configurations directly. Instead, you modify the dns.operator/default Custom Resource (CR) to inject custom upstream servers, forward zones, or internal DNS overrides.

Example: Forwarding Specific Corporate Domains

To route queries for internal corporate domains (e.g., *.corp.internal) to a custom on-premises DNS server:

apiVersion: operator.openshift.io/v1
kind: DNS
metadata:
  name: default
spec:
  servers:
    - name: corp-dns-forwarder
      zones:
        - corp.internal
        - mycompany.local
      forwardPlugin:
        upstreams:
          - 10.0.0.53:53
          - 10.0.0.54:53

Apply using:

oc edit dns.operator/default

5. Useful Commands for Debugging OpenShift DNS

  • Check DNS Operator Status:
    oc get clusteroperator dns
  • View CoreDNS Pods & Nodes:
    oc get pods -n openshift-dns -o wide
  • Tail Logs of CoreDNS Pods:
    oc logs -n openshift-dns -l dns.operator.openshift.io/daemonset-dns=default -c dns --tail=50
  • Test DNS Resolution from inside a Pod:oc run dns-test --image=registry.redhat.io/rhel8/support-tools --rm -it -- dig my-service.my-namespace.svc.cluster.local

Leave a Reply