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

Support deploying to multiple kubernetes contexts #915

Closed
balopat opened this issue Aug 21, 2018 · 8 comments · Fixed by #8459
Closed

Support deploying to multiple kubernetes contexts #915

balopat opened this issue Aug 21, 2018 · 8 comments · Fixed by #8459
Assignees
Labels
area/deploy kind/feature-request priority/awaiting-more-evidence Lowest Priority. May be useful, but there is not yet enough supporting evidence.
Milestone

Comments

@balopat
Copy link
Contributor

balopat commented Aug 21, 2018

This came up as an idea in #104.

In a multi-artifact project, skaffold would be able to deploy each artifact to a different namespace/context.

If you think your use case would need this functionality, please get in touch and describe it for us here!

@balopat balopat added kind/feature-request area/deploy priority/awaiting-more-evidence Lowest Priority. May be useful, but there is not yet enough supporting evidence. labels Aug 21, 2018
@derekperkins
Copy link

We run in a multi-cloud environment, so it's pretty annoying to have to remember which kubectl context you're in before deploying. It's a pretty easy way to accidentally deploy to the wrong region. I'd love to make skaffold cluster aware somehow.

@haf
Copy link

haf commented Dec 7, 2018

I'd like to deploy all the monitoring locally in ns:monitoring and the app in app, but now:

image

@tejal29
Copy link
Contributor

tejal29 commented Aug 21, 2019

related to #2325.

@haf
Copy link

haf commented Aug 21, 2019

I can also chime in that deploying everything with kustomize rather than kubectl does it right when multiple namespaces are involved, so IMO that could be documented and this issue closed.

@nkubala
Copy link
Contributor

nkubala commented Apr 30, 2020

I think kustomize opens up enough flexibility to support use cases described here, and I don't think we're going to have time to implement something deeper in skaffold, so I'll close this issue. if you still feel that skaffold needs to support this more fully, please give us some details on your use case and feel free to reopen!

@nkubala nkubala closed this as completed Apr 30, 2020
@revero-doug
Copy link

revero-doug commented Nov 21, 2022

skaffold/v3 now uses kustomize only for resource generation and applies using kubectl, so there is seemingly no longer a workaround here . this feels especially broken when requiring another skaffold config with a different defaultNamespace

edit: you can still work around this using kustomize (specifically by setting /namespace in kustomization.yaml), but /deploy/kubectl/defaultNamespace must never be set in any referenced config if any manifest across all configs explicitly sets a conflicting namespace. IMO with these new semantics of /deploy/kubectl/defaultNamespace, it should be renamed /deploy/kubectl/namespace because it doesn't behave like setting a default, but rather like setting the -n argument on a kubectl invocation

It's also worth noting that kustomize itself doesn't implement "defaultNamespace" behavior by default, but the NamespaceTransformer may be customized to switch from always-write to write-if-unset semantics.

@aaron-prindle aaron-prindle reopened this Nov 21, 2022
@aaron-prindle aaron-prindle added this to the v2.2.0 milestone Dec 7, 2022
@msonnleitner
Copy link

We use GCP's Multi-Cluster Ingress to load-balance traffic to multiple GKE clusters. It would be nice if Skaffold could deploy the same application to multiple clusters

@aaron-prindle
Copy link
Contributor

@gsquared94 to split this out into multiple issues - multiple contexts vs multiple namespaces

@gsquared94 gsquared94 changed the title Support deploying to multiple contexts/namespaces Support deploying to multiple kubernetes contexts Jan 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/deploy kind/feature-request priority/awaiting-more-evidence Lowest Priority. May be useful, but there is not yet enough supporting evidence.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants