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

nodeSelector support during deployment for mixed node clusters #278

Open
mikenorgate opened this issue Sep 23, 2022 · 12 comments
Open

nodeSelector support during deployment for mixed node clusters #278

mikenorgate opened this issue Sep 23, 2022 · 12 comments
Assignees
Labels

Comments

@mikenorgate
Copy link

What would you like to be added:
Add ability to specify nodeSelector during deployment

Why is this needed:
When deploying into a cluster container a mixture of Windows and Linux nodes I would like to be able to specify a nodeSelector with a value of kubernetes.io/os: linux to make sure the submariner pods are scheduled to the correct nodes

@mikenorgate mikenorgate added the enhancement New feature or request label Sep 23, 2022
@dfarrell07
Copy link
Member

This might solve the use case: submariner-io/enhancements#149

@mkolesnik
Copy link
Contributor

mkolesnik commented Jan 1, 2023

to make sure the submariner pods are scheduled to the correct nodes

Which pods do you mean exactly?

Or are you simply trying to limit all submariner pods to Linux nodes only?

@vthapar
Copy link
Contributor

vthapar commented May 3, 2023

Idea is to implement this through a generic option to take a yaml file as input, probably take Submariner CR as input yaml with all fields missing from yaml filled up as per current default.

@skitt
Copy link
Member

skitt commented Sep 5, 2023

Isn’t this done @vthapar?

@vthapar
Copy link
Contributor

vthapar commented Oct 26, 2023

submariner-io/enhancements#149 is done and it adds support for node selector for submariner pods. But it doesn't add any means in subctl to set this and only provides option to modify in SubmarinerCR.

As mentioned in comment this would be better implemented by providing a generic way to pass submariner CR yaml as input to subctl join.

@sridhargaddam
Copy link
Member

to make sure the submariner pods are scheduled to the correct nodes

Which pods do you mean exactly?

Or are you simply trying to limit all submariner pods to Linux nodes only?

@mikenorgate can you clarify the query from @mkolesnik.

@mikenorgate
Copy link
Author

The need is to limit all submariner pods to Linux nodes

@sridhargaddam
Copy link
Member

The need is to limit all submariner pods to Linux nodes

Okay. Please be aware that in order to achieve connectivity from a worker node to remote clusters, especially when using the kubeproxy based handlers, Submariner RouteAgent Pods should be running on every worker node. We can probably add necessary support in Submariner to limit scheduling of the RA pods (along with other DaemonSets) only to Linux nodes, but it might limit inter-connectivity only to those nodes. Is this something okay for you?

@skitt
Copy link
Member

skitt commented Oct 26, 2023

Given that the constraint stems from Submariner’s implementation, it might be best to always add a pod selector specifying kubernetes.io/os = Linux — end users shouldn’t have to deal with deployment failures caused by the unavailability of Windows route agents... (However they should be aware that non-Linux nodes won’t be able to use or provide multi-cluster services.)

Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further
activity occurs. Thank you for your contributions.

Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further
activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label Jun 27, 2024
@maayanf24 maayanf24 added this to Backlog Jul 2, 2024
@maayanf24 maayanf24 moved this to Backlog in Backlog Jul 2, 2024
@dfarrell07 dfarrell07 removed the stale label Jul 2, 2024
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further
activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label Oct 31, 2024
@maayanf24 maayanf24 removed the stale label Nov 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Backlog
Development

No branches or pull requests

8 participants