What Is an ExternalName Service in Kubernetes?

What Is an ExternalName Service?

An ExternalName Service is a special Kubernetes Service type that does not route traffic through kube-proxy at all. Instead, it creates a DNS CNAME record that maps the Service name to an external DNS hostname. When a Pod looks up the Service name, CoreDNS returns a CNAME pointing to the specified external name.

This is purely a DNS-level redirection with no proxying, no ClusterIP, and no endpoints.

Creating an ExternalName Service

apiVersion: v1
kind: Service
metadata:
  name: external-database
  namespace: production
spec:
  type: ExternalName
  externalName: prod-db.us-east-1.rds.amazonaws.com

There is no selector, no ports, and no clusterIP.

kubectl get svc external-database -n production

NAME                TYPE           CLUSTER-IP   EXTERNAL-IP                              PORT(S)   AGE
external-database   ExternalName   <none>       prod-db.us-east-1.rds.amazonaws.com      <none>    5s

How DNS Resolution Works

When a Pod queries external-database.production.svc.cluster.local, CoreDNS returns:

external-database.production.svc.cluster.local.  CNAME  prod-db.us-east-1.rds.amazonaws.com.

The Pod's DNS resolver then follows the CNAME to resolve the actual IP address of the RDS instance. The key difference from other Service types:

| Service Type | DNS Record Type | Returns | |---|---|---| | ClusterIP | A record | Virtual IP (e.g., 10.96.x.x) | | Headless | A record(s) | Pod IPs directly | | ExternalName | CNAME | External hostname |

Use Cases

1. Aliasing Cloud-Managed Services

Your application connects to an AWS RDS database, an Elasticache cluster, or a third-party API. Instead of embedding the external hostname in application config or environment variables, you create an ExternalName Service:

apiVersion: v1
kind: Service
metadata:
  name: cache
spec:
  type: ExternalName
  externalName: my-cache.abc123.ng.0001.use1.cache.amazonaws.com

Application code connects to cache:6379 using a standard Kubernetes Service name.

2. Migration from External to Internal

ExternalName is particularly powerful during migrations. Consider moving a database from RDS into the cluster:

Phase 1: External database

apiVersion: v1
kind: Service
metadata:
  name: user-db
spec:
  type: ExternalName
  externalName: users.cxyz123.us-east-1.rds.amazonaws.com

Phase 2: In-cluster database (after migration)

apiVersion: v1
kind: Service
metadata:
  name: user-db
spec:
  type: ClusterIP
  selector:
    app: postgres
    role: users
  ports:
    - port: 5432
      targetPort: 5432

The application code never changes. It always connects to user-db:5432. Only the Service definition is updated.

3. Cross-Namespace Service Aliasing

You can use ExternalName to create a local alias for a Service in another namespace:

apiVersion: v1
kind: Service
metadata:
  name: shared-auth
  namespace: team-b
spec:
  type: ExternalName
  externalName: auth-service.team-a.svc.cluster.local

Pods in team-b can reach the auth service as shared-auth instead of using the full cross-namespace DNS name.

Limitations and Caveats

No Port Mapping

ExternalName Services do not support port mapping. The ports field is ignored. The client must connect on whatever port the external service listens on.

HTTPS and SNI Issues

When using ExternalName with HTTPS, the TLS Server Name Indication (SNI) and the certificate validation hostname may not match:

Client connects to: external-database.production.svc.cluster.local
CNAME resolves to:  prod-db.us-east-1.rds.amazonaws.com
TLS certificate:    *.us-east-1.rds.amazonaws.com

The TLS handshake expects the hostname the client connected to. If the client uses the Kubernetes Service name, the certificate will not match. Solutions:

• Configure the client to use the external hostname directly for TLS verification.
• Use a Service without a selector and manual Endpoints instead of ExternalName.

No Health Checks

Kubernetes does not perform health checks on ExternalName targets. If the external service is down, the CNAME still resolves and the client discovers the failure at connection time.

No Network Policies

Because no traffic passes through kube-proxy, Kubernetes NetworkPolicies cannot control access to ExternalName Services. The traffic goes directly from the Pod to the external endpoint after DNS resolution.

ExternalName vs. Service Without Selector

For external IP addresses (not hostnames), ExternalName does not work. Use a Service without a selector instead:

# For an external service at a fixed IP
apiVersion: v1
kind: Service
metadata:
  name: legacy-api
spec:
  type: ClusterIP
  ports:
    - port: 443
      targetPort: 443
---
apiVersion: v1
kind: Endpoints
metadata:
  name: legacy-api
subsets:
  - addresses:
      - ip: 203.0.113.50
    ports:
      - port: 443

This gives you a ClusterIP with kube-proxy routing, unlike ExternalName which is DNS-only.

Verifying an ExternalName Service

# Check the service
kubectl describe svc external-database

# Test DNS resolution from within the cluster
kubectl run dns-test --rm -it --image=busybox:1.36 -- \
  nslookup external-database.production.svc.cluster.local

Expected output:

Name:      external-database.production.svc.cluster.local
Address 1: external-database.production.svc.cluster.local is an alias for prod-db.us-east-1.rds.amazonaws.com

Summary

ExternalName is a lightweight, DNS-only Service type that creates a CNAME alias for an external hostname. It is ideal for integrating external services into the Kubernetes DNS namespace and for enabling seamless migration strategies. However, it comes with limitations around port mapping, TLS, and network policies that make it unsuitable for all external service scenarios. For external IPs or when you need proxying and health checks, a selector-less Service with manual Endpoints is a better choice.