CoreDNS, Service Discovery, and Ingress Controller Architecture

An e-commerce mobile application sends an encrypted HTTPS POST request:

POST https://shop.example.com/api/v2/checkout

The request arrives at a cloud infrastructure edge firewall.

Within 8 milliseconds:

The request undergoes TLS decryption (HTTPS $\to$ HTTP).
The HTTP host header (shop.example.com) and path (/api/v2/checkout) are evaluated.
The request is routed across an internal virtual network directly to an active Pod instance running checkout-service on port 8080.

None of the internal microservice Pods have public IP addresses or open public firewall ports.

How does Kubernetes manage internal Service Discovery via CoreDNS and external Layer 7 Traffic Routing using Ingress Controllers?

1. In-Cluster Service Discovery: CoreDNS

Inside a Kubernetes cluster, CoreDNS runs as a high-availability Deployment watching kube-apiserver for Service updates.

When a new Service named payment-service is created in namespace finance:

apiVersion: v1
kind: Service
metadata:
  name: payment-service
  namespace: finance
spec:
  ports:
  - port: 8080

CoreDNS automatically constructs a canonical Domain Name System (DNS) record:

$\text{Fully Qualified Domain Name (FQDN)} = \text{service-name}.\text{namespace}.\text{svc}.\text{cluster.local}$

payment-service.finance.svc.cluster.local -> Resolves to ClusterIP 10.96.12.44

DNS Resolution Shortcuts:

Same Namespace: A Pod running inside namespace finance can connect directly to http://payment-service:8080. CoreDNS completes the domain automatically.
Cross-Namespace: A Pod in namespace analytics connects using http://payment-service.finance:8080.

2. Service Types: Exposing Workloads

Kubernetes provides three core Service abstraction types for exposing workloads:

[ External Internet ]
         |
         v
+---------------------------------------------------------------+
| 1. LoadBalancer Service                                       |
|    Provisions Cloud Load Balancer (AWS ELB / GCP LB)          |
+---------------------------------------------------------------+
         |
         v
+---------------------------------------------------------------+
| 2. NodePort Service                                           |
|    Opens High-Range Port (30000-32767) on EVERY Node IP       |
+---------------------------------------------------------------+
         |
         v
+---------------------------------------------------------------+
| 3. ClusterIP Service (Default)                                |
|    Internal-Only Virtual IP (Accessible INSIDE Cluster Only)  |
+---------------------------------------------------------------+

A. `ClusterIP` (Internal Default)

Assigned a private virtual IP accessible only within the cluster network. Used for internal microservices, databases, and message queues.

B. `NodePort` (Host Port Allocation)

Exposes the Service on a static high-range port (30000–32767) across every worker node’s physical IP address.

Example: Connecting to 192.168.1.10:31452 routes traffic to the target Service.

C. `LoadBalancer` (Cloud Provider Integration)

Asks the cloud provider controller (AWS, GCP, Azure) to provision an external cloud load balancer pointing to the node NodePort targets.

3. Layer 7 Ingress Controllers

Using a LoadBalancer Service for every microservice gets expensive ($20/month per cloud load balancer) and lacks HTTP routing capabilities (like path-based routing or TLS termination).

An Ingress Controller solves this by running a single reverse proxy (such as Nginx, Traefik, or Contour) exposed through one single cloud LoadBalancer.

[ Incoming HTTPS Traffic: shop.example.com ]
                     |
                     v
+---------------------------------------------------------------+
| INGRESS CONTROLLER (Nginx / Traefik Reverse Proxy)            |
| - Terminates TLS Certificates                                 |
| - Inspects Host & Path HTTP Headers                           |
+---------------------------------------------------------------+
         |                                             |
         | Host: shop.example.com                      | Host: shop.example.com
         | Path: /api/v2/checkout                      | Path: /static
         v                                             v
[ Service: checkout-service ]               [ Service: static-web-service ]
(ClusterIP 10.96.12.44:8080)                 (ClusterIP 10.96.18.99:80)

Declarative Ingress Resource Specification

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: main-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
  - hosts:
    - shop.example.com
    secretName: shop-tls-cert
  rules:
  - host: shop.example.com
    http:
      paths:
      - path: /api/v2/checkout
        pathType: Prefix
        backend:
          service:
            name: checkout-service
            port:
              number: 8080

4. The Next Generation: Gateway API

While Ingress works for simple HTTP routing, it suffers from bloated custom annotations and lacks role separation between infrastructure operators and application developers.

Kubernetes introduced the Gateway API to replace Ingress with role-decoupled custom resources:

+---------------------------------------------------------------+
| 1. GatewayClass (Infrastructure Provider: AWS / Cilium / Nginx) |
+---------------------------------------------------------------+
                                  |
                                  v
+---------------------------------------------------------------+
| 2. Gateway (Cluster Admin: Provisions IP & TLS Certs)          |
+---------------------------------------------------------------+
                                  |
                                  v
+---------------------------------------------------------------+
| 3. HTTPRoute / GRPCRoute (App Developer: Defines Path Rules)   |
+---------------------------------------------------------------+

GatewayClass: Managed by cloud providers or CNI vendors.
Gateway: Managed by Cluster Administrators to configure public IPs and TLS certificates.
HTTPRoute: Managed by Application Developers to attach routing paths (/api/v2) to specific Services independently.

Ingress vs Gateway API Comparison

Dimension / Feature	Ingress API (Legacy Standard)	Gateway API (Modern Standard)
Specification Maturity	GA (V1)	GA (V1)
Role Separation	Monolithic (Single Ingress resource)	Decoupled (`Gateway` vs `HTTPRoute`)
Protocol Support	HTTP / HTTPS only	HTTP, HTTPS, gRPC, TCP, UDP, TLS
Cross-Namespace Routing	Limited	Supported natively via `ReferenceGrant`
Feature Extensibility	Heavy reliance on custom vendor annotations	Clean spec fields (Header matching, traffic splitting)

Summary & Next Steps

CoreDNS and Ingress Controllers manage external and internal traffic routing:

CoreDNS automates internal service discovery by mapping service.namespace.svc.cluster.local names to ClusterIPs.
ClusterIP handles internal routing; NodePort opens static host ports; LoadBalancer provisions cloud provider infrastructure.
Ingress Controllers perform Layer 7 reverse proxying, path-based HTTP routing, and TLS termination.
The Gateway API provides next-generation role-decoupled traffic routing for modern Kubernetes clusters.

In the next article, we transition to Module 5 and explore Dynamic Storage Provisioning: PersistentVolumes, PVCs, StorageClasses, and CSI gRPC.

References & Further Reading

Cloud Native Computing Foundation. Using RBAC Authorization & Security Contexts in Kubernetes. CNCF Docs.
Center for Internet Security. CIS Kubernetes Benchmark v1.8.0 Access Control and RBAC Guidelines. CIS Security.
Rice, J. (2020). Kubernetes Security. O’Reilly Media.