Kubernetes Services on EKS: ClusterIP, NodePort & LoadBalancer

Simple explanation

In Kubernetes terms:

• The reception number is the Service’s stable virtual IP address (the ClusterIP).
• The receptionist is kube-proxy, which maintains routing rules on every node.
• The staff are your pods. They come and go as Kubernetes Deployments scale up, roll out new versions, or recover from crashes.
• The directory is the Endpoints object: a live list of pod IPs that currently match the Service selector.

If you have ever wondered why your Kubernetes pods can call each other by name instead of IP address, Services and CoreDNS are how that works.

Why Kubernetes Services exist

When Kubernetes schedules a pod, it assigns an IP address from the node’s CIDR block. On EKS with the VPC CNI plugin (covered in the EKS networking model), that IP comes directly from your VPC subnet. The problem: that IP is ephemeral.

Every time a pod is:

• Restarted after a crash
• Rescheduled onto a different node after a node failure
• Replaced by a rolling update from a Deployment

…it gets a brand new IP address. Any caller that hard-coded the old IP now gets connection refused.

A Service abstracts over this by giving you a stable virtual IP (called the ClusterIP) that never changes for the life of the Service. You point your code at the Service, and Kubernetes handles routing to whatever pods are currently alive.

How Kubernetes Services work

Selectors and endpoints#

When you create a Service with a selector, the Kubernetes control plane continuously watches for pods whose labels match that selector. It records their IPs in an Endpoints object (or the newer EndpointSlices for large clusters) with the same name as the Service.

kubectl get endpoints web-service
# NAME          ENDPOINTS                              AGE
# web-service   10.0.1.5:80,10.0.1.6:80,10.0.1.7:80   5m

When a pod is added, removed, or becomes unready, the endpoints list updates within seconds. The Service IP itself never changes.

Virtual IPs and kube-proxy#

The Service’s virtual IP is not assigned to any real network interface. It exists only in the iptables (or IPVS) rules that kube-proxy maintains on every node. When a packet arrives at the Service IP, kube-proxy’s rules rewrite the destination IP to one of the healthy pod IPs and forward it. This is why ClusterIP Services work without any AWS infrastructure at all.

Service discovery with DNS#

Every Service automatically gets a DNS record created by CoreDNS, which runs in the kube-system namespace. The full DNS name format is:

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

From within the same namespace, the short name works:

curl http://cache-service:6379

From a different namespace, use the full name:

curl http://cache-service.production.svc.cluster.local:6379

You never need to hard-code IP addresses. A Service can be created before or after the pods it selects. DNS starts resolving as soon as the Service and at least one matching pod both exist.

Service types at a glance

ClusterIP

ClusterIP is the default Service type. It assigns a virtual IP that is reachable only from within the cluster. No AWS infrastructure is provisioned and there is no cost beyond the cluster itself.

When to use it: Any time one service needs to call another inside the same cluster. A backend API calling Redis, a frontend calling an auth service, a worker reading from a queue. The vast majority of Services in a production EKS cluster are ClusterIP.

When not to use it: When anything outside the cluster (external users, other VPCs, on-premises systems) needs to reach the Service. ClusterIP is invisible from outside the cluster by design.

apiVersion: v1
kind: Service
metadata:
  name: cache-service
  namespace: production
spec:
  selector:
    app: redis-cache
  ports:
  - port: 6379
    targetPort: 6379
  type: ClusterIP

Other pods reach this at cache-service.production.svc.cluster.local:6379. No further configuration needed.

NodePort

NodePort builds on ClusterIP by also opening a port in the range 30000-32767 on every node in the cluster. External traffic reaching <any-node-IP>:<nodePort> gets forwarded to the Service.

Why it exists: NodePort was the original way to expose a Service externally before cloud load balancer integration existed. It works on any Kubernetes cluster without cloud infrastructure.

When NodePort is still useful:

• Local development with minikube or kind.
• Integration tests in CI that need to call a Service from outside the cluster.
• As the target type for a legacy AWS Classic Load Balancer (rare in modern EKS setups).

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
  - port: 80
    targetPort: 8080
    nodePort: 31080  # optional; omit to let Kubernetes pick a port
  type: NodePort

LoadBalancer on EKS

When you create a type: LoadBalancer Service on EKS, the AWS cloud controller manager provisions an AWS Network Load Balancer (NLB) and registers the worker node IPs (or pod IPs in IP mode) as targets. The NLB gets a stable DNS name you can CNAME your domain to.

NLBs operate at Layer 4 (TCP/UDP). They preserve client source IPs and handle high-throughput workloads well. They are the right choice when you need to expose raw TCP or UDP traffic, not HTTP.

apiVersion: v1
kind: Service
metadata:
  name: web-service
  namespace: production
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "external"
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"
    service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
spec:
  selector:
    app: web
  ports:
  - port: 80
    targetPort: 8080
  - port: 443
    targetPort: 8443
  type: LoadBalancer

Use scheme: "internet-facing" to make the NLB publicly accessible. Use scheme: "internal" for a load balancer accessible only within your VPC, which is useful for internal microservices reachable from other AWS services or accounts.

ExternalName

ExternalName creates a CNAME DNS record in CoreDNS pointing to an external hostname. It does not proxy traffic; it only redirects DNS lookups.

When it helps: Your code inside the cluster calls rds-primary.production.svc.cluster.local. In development, that resolves to a local test database. In production, you configure ExternalName to point at your actual RDS endpoint. The application code never changes; only the Service definition does.

apiVersion: v1
kind: Service
metadata:
  name: rds-primary
  namespace: production
spec:
  type: ExternalName
  externalName: mydb.abc123.us-east-1.rds.amazonaws.com

Pods calling rds-primary in the same namespace get the CNAME response and connect directly to the RDS endpoint.

For managing secrets and credentials needed to connect to those external services, use Kubernetes Secrets instead of baking credentials into the Service definition.

Kubernetes Service vs Ingress

This distinction trips up a lot of people.

• A Service gives stable network access to a set of pods. It operates at Layer 4 (TCP/UDP). It knows nothing about HTTP paths, hostnames, or TLS certificates.
• An Ingress handles HTTP and HTTPS routing at Layer 7. It reads the Host header and URL path and forwards requests to different Services based on rules.

On AWS, an Ingress resource backed by the AWS Load Balancer Controller provisions an Application Load Balancer (ALB). The ALB handles external traffic, applies TLS termination, evaluates routing rules, and sends traffic to the correct ClusterIP Service inside the cluster.

When to use each option

Use ClusterIP when:

• The service only needs to be reached by other services inside the cluster.
• Examples: Redis, internal APIs, auth services, message queue consumers.

Use NodePort when:

• You are running locally or in CI and cannot provision a load balancer.
• You need quick external access for a demo or test and do not care about stability.

Use LoadBalancer when:

• You need to expose a TCP or UDP service directly to the internet or to another VPC.
• You have a single externally-facing service and want the simplest setup.
• You are using horizontal pod autoscaling and want traffic distributed to all pods automatically without HTTP-specific routing.

Use Ingress + ClusterIP Services when:

• You have multiple HTTP or HTTPS services to expose.
• You need path-based routing (/api/* to service A, /static/* to service B).
• You need host-based routing (api.example.com to service A, app.example.com to service B).
• You want TLS termination handled once at the load balancer layer.
• Cost matters: one ALB is significantly cheaper than multiple NLBs.

Use ExternalName when:

• You want to give an external DNS hostname a stable in-cluster alias.
• You are migrating a workload and need to swap out an endpoint without touching application code.

Complete examples

ClusterIP — internal service#

apiVersion: v1
kind: Service
metadata:
  name: auth-service
  namespace: production
spec:
  selector:
    app: auth
  ports:
  - port: 8080
    targetPort: 8080
  type: ClusterIP

Reachable at auth-service.production.svc.cluster.local:8080 from anywhere in the cluster.

LoadBalancer — external NLB#

apiVersion: v1
kind: Service
metadata:
  name: api-gateway
  namespace: production
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "external"
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"
    service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
spec:
  selector:
    app: api-gateway
  ports:
  - port: 443
    targetPort: 8443
  type: LoadBalancer

The NLB DNS name appears in kubectl get svc api-gateway under EXTERNAL-IP once provisioned.

ExternalName — abstract an RDS endpoint#

apiVersion: v1
kind: Service
metadata:
  name: primary-db
  namespace: production
spec:
  type: ExternalName
  externalName: mydb.cluster-abc123.us-east-1.rds.amazonaws.com

Pods call primary-db:5432 and DNS resolves it to the RDS hostname. The EKS networking model ensures those pods can reach the RDS endpoint directly over the VPC network.

Service and Deployment together#

Services find pods via label selectors. The selector in the Service must match the labels on the pod template in the Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web       # Service selector must match this
    spec:
      containers:
      - name: web-app
        image: nginx:1.27
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web           # Matches pods with label app: web
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

If labels do not match, the Service has zero endpoints and routes no traffic.

Troubleshooting checklist

When a Service is not routing traffic, work through these commands in order:

# 1. Check the Service exists and has an IP
kubectl get svc web-service
# Look for: CLUSTER-IP is not <none>, TYPE matches what you expect,
# EXTERNAL-IP is set (for LoadBalancer) or shows <pending> if still provisioning

# 2. Check the endpoints — this is the most important command
kubectl get endpoints web-service
# If ENDPOINTS shows <none>, the selector is not matching any pods.
# Compare the selector in the Service spec against the pod labels.

# 3. Check EndpointSlices (used in newer clusters)
kubectl get endpointslices -l kubernetes.io/service-name=web-service

# 4. Check pod labels — are they what the Service selector expects?
kubectl get pods --show-labels -n production
# Compare the labels column against the selector in your Service spec

# 5. Describe the Service for events and configuration details
kubectl describe svc web-service
# Look at: Selector, Endpoints, and any Events at the bottom of the output

# 6. Check DNS resolution from inside a pod
kubectl exec -it <pod-name> -- nslookup web-service
kubectl exec -it <pod-name> -- nslookup web-service.production.svc.cluster.local
# If nslookup fails, CoreDNS may have an issue; check pods in kube-system

# 7. Check pod readiness — unready pods are removed from endpoints
kubectl get pods -n production
# Pods with STATUS Running but READY 0/1 are excluded from Service endpoints

For LoadBalancer Services stuck in <pending>, check that the IAM roles for your node group or service account have the permissions needed for the cloud controller manager to provision NLBs. Also check securing EKS clusters to ensure security group rules allow traffic on the expected ports.