In this lesson, you will learn how to manually control exactly where your Kubernetes Service sends traffic by manipulating Endpoints objects directly.
The Decoupling of Services and Pods
Usually, when you create a Service, Kubernetes automatically creates an Endpoints object that tracks the Pods matching your selector. This is how traffic reaches your application pods. However, sometimes you need a Service to point to something outside your cluster—like a legacy database, an external API, or a specific IP address—that isn't managed by a Deployment.
Because a Service relies on an Endpoints object to know the destination IP addresses, you can define an Endpoints object manually, bypassing the automatic selector logic.
Manually Mapping Traffic
To route traffic manually, you create two separate objects: a Service with no selector and an Endpoints object that shares the exact same name as your Service.
- The Service: You create a Service definition without a
selectorfield. Because Kubernetes doesn't know which Pods to pick, it remains "headless" regarding backend discovery. - The Endpoints: You create an
Endpointsresource that explicitly lists the IP addresses and ports you want to target.
# A Service without a selector
apiVersion: v1
kind: Service
metadata:
name: my-external-service
spec:
ports:
- port: 80
---
# The manual Endpoints map
apiVersion: v1
kind: Endpoints
metadata:
name: my-external-service # Must match the Service name
subsets:
- addresses:
- ip: 192.168.1.50 # Your custom destination IP
ports:
- port: 80
Why Do This?
This technique is powerful for "wrapping" external dependencies. By pointing your Service to a hardcoded IP, your internal code can continue to talk to my-external-service using the standard Kubernetes DNS, unaware that the actual traffic is leaving the cluster or hitting a specific static target. It provides a consistent network interface regardless of where the backend actually resides.
Key Takeaway: By creating an Endpoints object with the same name as a selector-less Service, you take manual control over traffic routing, allowing your cluster to reach external IPs as if they were internal services.