The moment we shop online and click the order button, countless data points safely arrive at the server, following a complex path. Just like a delivery driver accurately finds our home address! π¦
In this process, the two most important concepts are Route and Endpoint. Many people consider them separate, but in fact, they are very closely related. Today, we’re going to thoroughly explore their relationship!

π£οΈ Route: The Highway to Your Destination
Route is literally a set of rules or policies that dictate which ‘path’ data traffic should follow.
- “If a user requests the /login page, send it to the ‘login processing server’!”
- “Requests coming from mobile apps, send them to the ‘v2 API server’!”
- “Send 90% of payment-related requests to the new server, and 10% to the stable old version server for testing!”
Like a traffic cop, a Route examines the characteristics of incoming traffic (such as address, header information) and directs it to where it needs to go.
However, a Route only goes so far. It tells you the destination ‘group’ like ‘login processing server’, but it doesn’t tell you exactly which server and which door (port) among the many servers in that group to enter.
It’s like only being told a large area, such as “Gangnam-gu, Seoul.”
π‘ Key Point: A Route is an abstract ‘direction’ and ‘rule’ for where to send traffic.
πͺ Endpoint: The Front Door of the Final Destination
An Endpoint is the actual destination where data traffic ultimately arrives. It’s the end of the road where there’s nowhere further to go, the point where communication terminates.
It is typically expressed as a combination of an IP address and a Port number.
- 10.1.2.3:8080
- 172.16.0.10:3000
Let’s revisit the delivery analogy. If a Route told you the path to “Gangnam-gu, Seoul,” an Endpoint is a very specific final address like “Teheran-ro 123, 45th floor, Unit 6”. Only with this address can the delivery driver accurately deliver to your doorstep, right?
π‘ Key Point: An Endpoint is a concrete, physical ‘final address’ where traffic arrives.
πΊοΈ The Big Picture: Every Route Must End with an Endpoint
Now we’ve reached the most important question: What is their relationship?
In short, an Endpoint is part of a Route and the final destination of a Route. No matter how sophisticated a Route rule is, it’s meaningless if there’s no Endpoint at its end to receive the traffic.
Let’s follow the entire process:
- Request Occurs π¨: A user sends a request to an address like http://my-service.com/api.
- Arrives at Router/Gateway π¦: The request first enters a traffic gateway like Kubernetes Ingress or Istio Gateway.
- Route Rule Check π: The gateway checks the configured Route rules (e.g., Istio’s VirtualService).
- “Hmm, a request for /api. This request is set to be sent to api-service!”
- Endpoint Lookup π : Now the system starts looking for where api-service actually is. Kubernetes has a list of Pods connected to this service, i.e., an Endpoint list.
- api-service Endpoints: 10.1.2.3:8080, 10.1.2.4:8080, 10.1.2.5:8080
- Final Traffic Delivery π: The gateway selects one of the looked-up Endpoint list (e.g., 10.1.2.3:8080) and finally delivers the traffic.
- Route: Policies and rules for where to send traffic (Highway)
- Endpoint: The actual address where traffic ultimately arrives (House front door)
As you can see, a Route acts as an abstract guide specifying the ‘service’ to send traffic to, and at the end of that path, a concrete address, the Endpoint, always awaits.
π€ Common Misconception: “Aren’t Route and Endpoint just separate?”
Many people easily think of Route rules (like Kubernetes Service or Ingress) and Endpoints (list of destinations) as completely separate concepts because they are managed as distinct objects in Kubernetes.
But this is not true. π ββοΈ
Functionally, these two are strongly coupled. The act of defining a Route rule is ultimately the process of deciding “to which Endpoint should traffic be sent?” A Route defines ‘how’ to send, and an Endpoint is the final answer to ‘where’ to send.
It’s like having a road (Route) but no destination (Endpoint), or having a destination but no road β nothing can be done.
π» See it in Code: Kubernetes & Istio Example
Seeing is believing! Let’s see how it works with actual code.
1. Create Service and Endpoint (Basic)
First, when you deploy a service named my-api in Kubernetes, Kubernetes automatically collects the IPs and ports of the Pods connected to this service and creates an Endpoints object.
# Check the list of endpoints connected to the my-api service
kubectl get endpoints my-api
[Raw Data Result]
NAME ENDPOINTS AGE
my-api 10.1.2.3:8080,10.1.2.4:8080,10.1.2.5:8080 2d
π This is the list of ‘actual addresses’ where traffic can ultimately arrive.
2. Define Route Rules with Istio VirtualService
Now, let’s create complex routing rules using Istio’s VirtualService. The rule is to “send 90% of incoming requests to version v1, and 10% to version v2.”
# my-api-route.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-api-virtualservice
spec:
hosts:
- "my-api.example.com"
http:
- route: # π This is the 'Route' rule.
- destination:
host: my-api-service # π Which service to send to?
subset: v1 # π To the 'v1' version group of that service!
weight: 90
- destination:
host: my-api-service # π Which service to send to?
subset: v2 # π To the 'v2' version group of that service!
weight: 10
In the YAML above, the http.route section is the Route. This route instructs to “send requests to my-api-service, but divide them into v1 and v2 groups.”
And Istio refers to the actual IP addresses of the Pods belonging to these v1 and v2 groups, i.e., the Endpoints list (10.1.2.3:8080, etc.) we checked above, to finally send the traffic.
Ultimately, the elaborate Route rules defined in VirtualService are merely sophisticated signposts for sending traffic to a specific Endpoint.
Conclusion
An Endpoint is a critical final component of the path where traffic is transmitted.
Next time you design a network architecture or troubleshoot, remember the relationship between these two. Only by looking at abstract route rules (Route) and concrete destinations (Endpoint) together can you fully understand the entire traffic flow! π
Leave a Reply