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

Don't use a default kube-context #4140

Closed
shadiramadan opened this issue May 10, 2020 · 5 comments
Closed

Don't use a default kube-context #4140

shadiramadan opened this issue May 10, 2020 · 5 comments

Comments

@shadiramadan
Copy link

From the documentation:

By default, Skaffold uses the current kube-context from your kube-config file.

IMO this is very dangerous and is an accident waiting to happen.

All it would take is forgetting you switched to a production context to cause some very annoying problems for someone.

I think it should always be explicitly set by default.

@dgageot
Copy link
Contributor

dgageot commented May 11, 2020

Thank you @shadiramadan. I understand your concern, however, skaffold behaves like kubectl or helm or basically any other tool in that domain. I don't think we want the users to have to always specify a kube-context

@pre
Copy link

pre commented May 13, 2020

There is also a related bug: if you have a namespace defined in your current context of kube-config, skaffold sync will fail for assets deployed not in this exact namespace. See #1668 (comment)

These practically mean that (at least for me) skaffold needs to be wrapped around a script like this: #1668 (comment)

Wrapping skaffold provides also a safety net for not accidentally running it against production.

@stanislav-zaprudskiy
Copy link

Would setting to deploy only in a valid context work? You can achieve this via profiles activation - https://skaffold.dev/docs/environment/profiles/#activation. We just set up all deployments inside the profiles section, which gets activated only when in a proper context (docker-desktop, microk8s, etc) is used by kube-config.

@tstromberg
Copy link
Contributor

Thanks for opening this!

I also agree with @dgageot on this one. Never point your default to production, otherwise you will invariably mutate production accidentally. This goes not only for skaffold, but for any tool that interacts with a cluster.

Someone will invariably shoot themselves in the foot with the defaults some day, but forcing a specific context would make skaffold more confusing for folks who don't know the context name of their local dev environment.

@shadiramadan
Copy link
Author

shadiramadan commented May 18, 2020

No problem @tstromberg, @dgageot. I made this ticket out of me having a quick panic when I was about to run a skaffold command and thought to myself- how does it know which context to use?

I ended up explicitly setting the kubeContext field that @stanislav-zaprudskiy pointed out to minikube.

I'm trialing skaffold as I want to drop docker-compose and have our team develop on k8s directly.
It has taken a bit of time as I have had to create custom kustomize patches for our dev environment to mount NFS volumes instead of EFS drives... But I'm almost there.

I'm probably a ways away from trusting skaffold for deployments but developing on it is the first step :).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants