-
|
I've banged my head against this a little, but I think this might not be a solveable problem. if you have a headless service, k8s provides the possibility to address specific pods defined in the selector. if pod-1 and pod-2 are a statefulset, they can be reached individually as pod-1.service-headless and pod-2.service-headless. Some clustered services rely on this (for example, many of bitnami's charts work like this). When you expose the service with skupper, it replaces the selector with its proxy, and the pod selector is thus no longer available (because there's no pods any more connected to the headless service). As this involves k8s DNS, which is not in scope for skupper, I assume this problem is not solveable in this environment - am I correct or did I miss something? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 4 replies
-
|
You can currently get similar behaviour by exposing a statefulset with the --headless option. |
Beta Was this translation helpful? Give feedback.
-
|
that implies that there is a functional difference between using skupper expose and annotating an existing service. I'll try that, because I'm curious how that would work at all - skupper (afaik) does not touch DNS and the affected use-case (addressing podselectors via prefix) depends on the selectors being exposed via DNS... |
Beta Was this translation helpful? Give feedback.
-
|
You can add annotations to the statefulset instead of to the service. skupper.io/proxy=tcp and skupper.io/headless=true The way it works at present is that it creates a 'proxy' statefulset with the same name and the same service in the other linked sites, which results in the same DNS being set up there. We have thoughts on changing this in the future though, still giving each pod a unique and stable name but probably not the exact form that kubernetes gives. |
Beta Was this translation helpful? Give feedback.
-
|
thank you so much for helping me understand this. it also looks like the skupper.io/headless annotation is missing from the docs - at least I couldn't find it. I'm still curious if I could achieve a similar result by just annotating the service, but I'm okay if that's not possible. |
Beta Was this translation helpful? Give feedback.
-
|
No, annotating the service won't work. Annotating the service was the first mechanism offered by skupper. We realised though that it had numerous problems (changing the selector and target ports isn't ideal for example), so we generally recommend annotating the target workload instead. Our plan for a future version is to introduce CRDs to more directly and intuitively configure the way skupper services are exposed and consumed. |
Beta Was this translation helpful? Give feedback.
You can add annotations to the statefulset instead of to the service. skupper.io/proxy=tcp and skupper.io/headless=true
The way it works at present is that it creates a 'proxy' statefulset with the same name and the same service in the other linked sites, which results in the same DNS being set up there.
We have thoughts on changing this in the future though, still giving each pod a unique and stable name but probably not the exact form that kubernetes gives.