Service autodiscovery/autosync/autoexpose?

[Ondřej Hlaváček]

Sorry for doubleposting, I have posted this in GH issues as well before I realized this group may be better suited for this. 

Is there a way I can set up skupper to expose pods/deployments automatically? We have a dedicated namespace with skupper and we have an external service that deploys workloads in to this namespace. It would be great if the external service did not need to know about skupper and just deploed a pod/deployment as usual.

Thanks, Ondra

[Paul Wright]

Hi Ondra,

When you deploy workloads, could you annotate your service as per https://github.com/skupperproject/skupper-example-declarative#step-8-expose-the-backend-service ?

Paul

--
You received this message because you are subscribed to the Google Groups "Skupper" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skupper+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skupper/ec1a17ee-53bb-4040-9a9f-1c56c3506b2cn%40googlegroups.com.

--

Paul Wright

Technical Writer

Red Hat, Waterford, Ireland

GitHub: pwright

[Ondřej Hlaváček]

That works like magic! Thanks a lot! Just to confirm - if two deployments on two different remote clusters have the same deployment name and both are exposed, what happens? Traffic is load balanced between the two? 

[Ted Ross]

Ah... I see the question over here too :)

Yes, if two or more deployments in different sites are exposed using the same address/service-name, they will share the work load.

-Ted

To view this discussion on the web visit https://groups.google.com/d/msgid/skupper/0e8a5b82-1d0a-4f8b-88e2-88509f9aa8a9n%40googlegroups.com.

[Ondřej Hlaváček]

Awesome, thanks. One more question though as I try to match Skupper to our use case. 

Is there a way to stop service propagation further downstream over the network? We have a control plane / data plane application architecture and I would like to expose services only in one direction, one hop (from data plane to control plane) and stop propagating it over the whole network (among multiple data planes). If not I spotted something in the docs about issues with multiple Skupper instances on the same cluster? If there are multiple Skupper instances in different namespaces I assume it should work independently and I just misread the docs? 

Anyway, thanks a lot again for your help and for an amazing piece of software! 

--

Ondrej Hlavacek

SRE, Keboola 

+420 777 930 888

@keboola

[Paul Wright]

Sounds like you want to deploy skupper without service sync in some downstream namespaces:

skupper init --enable-service-sync=false 

Paul

To view this discussion on the web visit https://groups.google.com/d/msgid/skupper/CAEeAFwhzC66%3Demy462%2BNC25mu4d0KAH5%2BxVY%2B%2BYFzhC-hfLGRQ%40mail.gmail.com.

[Paul Wright]

On Tue, Aug 9, 2022 at 1:12 PM Ondřej Hlaváček <ondrej....@keboola.com> wrote:

Awesome, thanks. One more question though as I try to match Skupper to our use case. 

Is there a way to stop service propagation further downstream over the network? We have a control plane / data plane application architecture and I would like to expose services only in one direction, one hop (from data plane to control plane) and stop propagating it over the whole network (among multiple data planes). If not I spotted something in the docs about issues with multiple Skupper instances on the same cluster? If there are multiple Skupper instances in different namespaces I assume it should work independently and I just misread the docs? 

I'm not sure what you're referring to, but skupper instances are independent (until linked) and are tied to namespaces. 

Same/different cluster behaviour is usually related to ingress (You can only link to namespaces in the same cluster if you set ingress to none) 

If you find the docs reference, let me know and we can edit to make it clearer,

thanks,

P

 

To view this discussion on the web visit https://groups.google.com/d/msgid/skupper/CAEeAFwhzC66%3Demy462%2BNC25mu4d0KAH5%2BxVY%2B%2BYFzhC-hfLGRQ%40mail.gmail.com.

[Ted Ross]

Hi Ondrej,

Here's what I think you're asking:  You have a hub-spoke topology with a central control site and multiple connected data sites.  You want to expose services from data site to control site but not data site to data site.

As Paul has just pointed out, you can turn service-sync off when you initialize Skupper.  Service-sync (on by default) causes everything to be exposed everywhere.  If you turn it off, you can then manually choose what is exposed where.  This would permit you to meet the above requirement.

I would need to do a little research before I can explain how to do this with annotations.

-Ted

[Ondřej Hlaváček]

> Service-sync (on by default) causes everything to be exposed everywhere.  If you turn it off, you can then manually choose what is exposed where.  This would permit you to meet the above requirement.

This sounds like what I had in mind. I have tried going through the source code (https://github.com/skupperproject/skupper/blob/master/api/types/types.go) but nothing caught my eye. But I really don't want to take any more of your time, it's just me exploring all possible scenarios where in fact this may not be required from our clients at all. It's great to know it is possible and I'll deal with it when the requirements arise.