Feature request : add a support to auto create an additional clusterIP service with respect to deploymentLabel

[msshitole]

Currently, the skipper creates a clusterIP service and assigns a unique service-name for every deployment. Ex. (my-service-v1, myservice-v2, my-service-v3 etc.).

My requirement is to have a clusterIP service that should always have the same name. So that I can access them in the cluster. I have a wrapper API that is exposed to the outside world and this API internally uses this clusterIP services. Currently, it's not possible since skipper is renaming these services per deployment.

Temporarily we have solved this issue in following way. Here is the snippet from Gitter chat where me and @sabbyanandan discussed it:

We solved the uniquely identifying a service via passing the additional deploymentLabel app:serviceName during deployment. And to support this, we created a prior clusterIP services with the respective deploymentLabel. And the wrapper API which is secured one who accesses these clusterIP services internally. Used this config during deployment,
deployer.my-service.kubernetes.deploymentLabels=app:my-service.
Similarly can't skipper should create always a clusterIP service with respect to the passed deploymentLabel? And anyway skipper can keep using the existing label, ex. my-service-v1 my-service-v2. This is just an additional clusterIP service and only be created if user pass any deploymentLabel.

For more context, here is the chat history:
Me:

@sabbyanandan We are deploying stream pipeline in Kubernetes and would like to access apps via its service-name. But the problem is, the service is of type clusterIP and every deployment the name is getting reset. For ex: demo-stream-my-app-v1 ,demo-stream-my-app-v2, demo-stream-my-app-v3 etc. How to make these names static or how we can pass this via SCDF panel? Could you please guide us to achieve this. Thank you in advance!
@sabbyanandan For security reasons, we dont want to expose as a LoadBalancer or NodePort. The plan is to have separate warper API, which in turn access these clusterIP services internally in kube cluster. And will add security authentication to only wrapper API. Kindly request your opinion/recommendation on the same. Thank you.

@sabby:

Hi, @msshitole! I may have shared this before, but here's the same idea of deriving a predictable name/URI for the apps deployed by SCDF — https://dataflow.spring.io/docs/resources/faq/#predictableIP. I have seen this as a pattern at a few customers, as well. Background:
To do CD for streams, the versioning is a critical piece, and today Skipper relies on updating the route/name with the version suffix (eg: demo-stream-my-app-v1, demo-stream-my-app-v2, demo-stream-my-app-v3) — altering this would be a big change to the foundation since the core lifecycle components rely on it. I understand that you don't want to rely on LBs in production. I cannot think of any other solution off the top of my head, though. I'm going to talk to @chrisjs to see if we have any other K8s-friendly options here.

Kindly request you to review this request and do the needful. Thank you!

[chrisjs]

closing in favor of: spring-cloud/spring-cloud-skipper#953