Service with both selector and explicit endpoints? - kubernetes

Question

As part of a migration from a legacy service discovery framework to kube/CoreDNS I would like to create a Service that knows how auto-publish Endpoints, but also have manually created endpoints.
Essentially I think I would like the following:
---
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
---
kind: Endpoints
apiVersion: v1
metadata:
name: my-service
annotations:
transition: legacy
subsets:
- addresses:
- ip: 1.2.3.4
ports:
- port: 9376
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: service-discovery-backend
labels:
app: MyApp
spec:
replicas: 1
selector:
matchLabels:
app: MyApp
template:
metadata:
labels:
app: MyApp
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
As the docs imply, though, explicitly setting things up like this results in there only being one Endpoints object associated with the service -- whether it's the service's auto-created one or my manually specified one seems to vary.
Is the most reasonable way to use CoreDNS as service discovery for both services that know how to self-publish and external services to manually control endpoints until we are 100% migrated, and then just switch over to a selector-based approach?

Answer 1

It can't be done using just Kubernetes Service, but I see one workaround here.
I believe, you can use additional Service backed by Nginx Pod (or deployment), manually configured (by config-map) as a reverse proxy for two backends: Kubernetes Service name (with selector, for new backend) and a manual endpoint (fqdn or IP, for legacy backend).
ingress -> Service1 -> Nginx--> Service2 -> Deployments/Pods
|
---> Endpoint -> Legacy Servers
It's up to you how to balance traffic to between them.