Introduction

In Kubernetes, a Service usually selects pods via labels and Kubernetes automatically manages endpoints. If you need to point a service to specific IP addresses manually, create a selectorless service and define endpoint resources yourself. This pattern is useful for integrating external systems or legacy workloads not running as pods.

When Manual Endpoints Are Useful

Use explicit endpoints when:

• Backends run outside the cluster.
• Backends are managed manually and do not have pod labels.
• You need a stable service DNS name for non pod targets.

For pod based workloads inside cluster, selector based services are usually simpler and safer.

Create A Selectorless Service

Define a service without selector and expose named port.

1apiVersion: v1
2kind: Service
3metadata:
4  name: external-api
5  namespace: default
6spec:
7  ports:
8    - name: http
9      port: 80
10      targetPort: 8080

Because no selector is present, Kubernetes will not auto populate endpoints.

Define Endpoints Manually

Create an Endpoints object with same name and namespace as service.

1apiVersion: v1
2kind: Endpoints
3metadata:
4  name: external-api
5  namespace: default
6subsets:
7  - addresses:
8      - ip: 10.20.30.40
9      - ip: 10.20.30.41
10    ports:
11      - name: http
12        port: 8080
13        protocol: TCP

Service traffic now routes to those explicit IP addresses.

EndpointSlice Note

Modern clusters use EndpointSlice internally. For manual setups, you can still define classic Endpoints, but for large scale integrations, managing EndpointSlice may be preferable. Start simple with Endpoints unless you have scale constraints.

Verify Configuration

After applying manifests:

1kubectl get svc external-api -n default
2kubectl get endpoints external-api -n default -o yaml
3kubectl run tester --rm -it --image=curlimages/curl -- sh
4# inside pod:
5curl http://external-api.default.svc.cluster.local/

This confirms DNS resolution and backend connectivity.

Handling TLS And Health

Manual endpoint definitions do not include health checks by default. Kubernetes does not actively verify external IP health for this object type.

Consider:

• External monitoring for endpoint availability.
• Retry and timeout settings in clients.
• Using ingress or service mesh policies for TLS and resilience.

If one endpoint becomes unhealthy, remove it from Endpoints object quickly via automation or ops runbook.

Common Integration Pattern With ExternalName

If you only need DNS CNAME style mapping, ExternalName service can be simpler. But ExternalName does not support port mapping and behaves differently from IP endpoint services. Choose pattern based on routing requirements.

Operational Considerations

Since Kubernetes does not manage lifecycle of manual endpoint IPs, your team must keep them updated. Stale IPs cause silent traffic failures.

Use automation scripts or controllers if endpoint membership changes frequently. Manual YAML edits are acceptable for static integrations but brittle for dynamic systems.

Automation Suggestions

If backend IPs change periodically, manage endpoint objects through automation rather than manual edits. A small controller or scheduled job can sync addresses from source-of-truth systems, reducing outages caused by stale YAML definitions.

When automating, include change logging and rollback logic so endpoint updates remain observable and recoverable during incidents.

Include periodic connectivity probes from inside the cluster to detect endpoint drift proactively before client-facing failures occur.

Common Pitfalls

• Defining selector and manual endpoints simultaneously expecting both to merge.
• Mismatching service port names with endpoint port names.
• Forgetting endpoints must share service name and namespace.
• Assuming Kubernetes health checks external endpoint IPs automatically.
• Using manual endpoints for dynamic pod workloads where selectors are better.

Summary

• Explicit endpoints require selectorless service plus matching endpoints resource.
• This pattern is useful for external or legacy backends.
• Verify routing with DNS and curl tests from inside cluster.
• Manage endpoint lifecycle yourself because Kubernetes will not auto update it.
• Prefer selector based services for normal pod workloads.