Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide possibility to install as statefulset #1247

Open
2 tasks done
MarcusElevait opened this issue Nov 1, 2024 · 7 comments
Open
2 tasks done

Provide possibility to install as statefulset #1247

MarcusElevait opened this issue Nov 1, 2024 · 7 comments
Labels
kind/proposal a proposal that needs to be discussed.

Comments

@MarcusElevait
Copy link

Welcome!

  • Yes, I've searched similar issues on GitHub and didn't find any.
  • Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you expect to see?

In our use-case we deploy traefik in a pod alongside with a zerotier client, so that we can access services in the cluster via our company zerotier network. Those zerotier client gets a unique identity in the zerotier network. For this it would be good to install it as a statefulset instead of a deployment, because we need the pod name to be static.
Would be cool if there would be an option to install it as statefulset. (Similar to the current option to deploy it as a daemonset instead of a deployment)

@mloiseleur
Copy link
Contributor

Usually, it's recommended to use labels.

Would you please detail why you can not use labels in this use case ?

@MarcusElevait
Copy link
Author

We have zerotier client and traefik running in the same pod. For zerotier configuration we need the exact name of the zerotier container. It has something to do with our zerotier redundancy setup, i will not bother you with details there :-)
But labels are not working in this case, because within the zerotier container we don't know the labels.

If you like, we can raise a PR for the statefulset?

@mloiseleur
Copy link
Contributor

It's possible to request API Server from a pod, with RBAC and service account token.
Service can also be used.
CoreDNS also.

Would you please detail why you can not use recommended and widely used k8s mechanism ?

@MarcusElevait
Copy link
Author

Okay so i try to explain our use case:

In the same pod with the traefik container we have two zerotier container running. We have two for redundancy reasons.
Both zerotier-clients need to join a zerotier-network. To join, we need to provide to each of them a key-pair. Each key-pair is saved in a file. So we need to provide one of these files to each of the two clients. Until here it's pretty straight forward.

But, when one container gets killed (for whatever reason) and needs to be spin up again, it's needs to know which of the two files it can take, i.e. which file is not used by the other container. With a statefulset we could just name the file like the container name, because it would be static.
With the deployment, we need to integrate a workaround, to figure out which file is already used by the other container.

So i guess our use-case is pretty special, but for us it would make it way easier, if it would be a statefulset.

Does this make sense to you?

@mloiseleur
Copy link
Contributor

mloiseleur commented Nov 6, 2024

I'm sorry but still not 😅. Especially on redundancy : why two container with traefik in the same pod ? It means with 3 proxy, there are 6 zero tier containers and a total of 9 containers ?

On specific network need like when using mesh, known architecture is to use one sidecar per pod, and so two containers per replica. With 3 proxy, there are 3 sidecar containers which provide specific network layer.

An other known architecture is to set network specific layer on node directly, see this blog post or this chart with daemonset or here.

@MarcusElevait
Copy link
Author

MarcusElevait commented Nov 14, 2024

why two container with traefik in the same pod

For redundancy reasons. We can't make use of replicas here to have redundant zerotier-clients, because then we would have again the problem that we need to provide a unique key-pair to every zerotier-client. And how could we provide a unique key-pair to every replica? I don't know if there is a possibility for this

@mloiseleur
Copy link
Contributor

We’re unsure about the use case and the traction it will receive. We are going to leave the status as kind/proposal to give the community time to let us know if they would like this idea.

We will reevaluate as people respond.

@mloiseleur mloiseleur added kind/proposal a proposal that needs to be discussed. and removed kind/enhancement New feature or request labels Dec 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/proposal a proposal that needs to be discussed.
Projects
None yet
Development

No branches or pull requests

2 participants