Proposal for deleting contexts: kubectx -d NAME

[ahmetb]

I'm really sad about all the context entries that accrued in my global KUBECONFIG file after using GKE for a while.

I think we can have a shorthand kubectx -d foo that removes that context, and the associated cluster and user entries in the KUBECONFIG file.

Currently kubectl config delete-context doesn't offer a cascading deletion of the associated user and cluster entries, but I think this command should assume people don't edit kubeconfig file manually, or if they do, they wouldn't use kubectx -d. This also assumes there’s 1:1:1 mapping between "contexts", "users", "clusters" entries.

[ahmetb]

@pswenson @thomaswo @nealf @laszlocph @cyakimov @gtseres

Sorry to ping y'all, you upvoted this feature request so I have a question for you.

Would you like to have kubectx -d NAME to delete:

1. only the "context" entry, or
2. "context" entry, as well as its "user"/"cluster" entries (assumes there's a 1:1:1 mapping between these)

Let me know which one is more preferable to you, and please explain why.

There's an option to provide both kubectx -d and kubectx -D (like git branch -d & git branch -D) but I don't want to add new the flags unless absolutely necessary.

[jfchevrette]

I would love to see this. I to have many (> 20) entries in my kubeconfig and I wish I could delete some of them without editing my .kube/config.

• Deleting only the context entry would mean I'm left with multiple user/cluster entries which will accumulate over time may never be deleted. Would that mean kubectx should have the ability to manage/delete users and clusters?
• Deleting the user and cluster entries along with the context entry would be the behavior I would personally expect by default as I don't have a need to keep the clusters or users around.
• Not deleting users may mean there are leftover credentials/tokens in my kubeconfig without me knowing about them and I may not want that.
• Would deleting corresponding users/clusters entries mean we have to start depending on an external tool such as yq to parse and update the yaml? I belive some functionality we would require to do this is missing from kubectl at this time such as listing/deleting users.

How about the following workflow:

• -d delete only the context
• -D delete the context and all associated user(s) and cluster(s)
• Both would output a message and would require a confirmation before proceeding with the deletion

[jfchevrette@host ~]$ kubectx -h
USAGE:
  kubectx                   : list the contexts
  kubectx <NAME>            : switch to context <NAME>
  kubectx -                 : switch to the previous context
  kubectx -d <NAME> : delete the NAME context (. for current)
  kubectx -D <NAME> : delete the NAME context (. for current) along with all associated clusters and users
  ...

[jfchevrette@host ~]$ kubectx -d .
About to delete context: gke_something-xyz_us-central1-a_cluster-2
Are you sure you want to delete this context? [y/N]

[jfchevrette@host ~]$ kubectx -D .
About to delete context: gke_something-xyz_us-central1-a_cluster-2
This will also remove the following clusters and users:
- cluster: clusterXYZ
- user: myuserB
- user: myuserA
Are you sure you want to delete this context and linked clusters and users? [y/N]

[ahmetb]

@jfchevrette I think we're both on the same page because we're both using GKE. GKE has a 1:1:1 mapping. So we almost always will want to use -D. However I think there are people out there who manually craft kubeconfig files. I think they should not be using kubectx to delete context entries.

I don't intend this tool to "manage" contexts, it's meant to do some convenience tasks, primarily "switching" contexts (renaming and deleting happens to be the other frequent tasks in my GKE usage).

Therefore, I think there should be only one delete command, say, -D, that just deletes everything attached to the context.

(I probably won't add the confirmation prompt, I assume users know what they're doing and if their kubeconfig entries are valuable, they shouldn't be using kubectx. Treat this like the rm file.txt command which won't prompt you to delete a file.)

[ahmetb]

How about this: we can have only one delete mode, that deletes the corresponding "user"/"cluster" entry only if it appears once in the kubectl config view output (i.e. in the context to be deleted).

So if a "user"/"cluster" is used on multiple clusters, it can remain, and can be deleted when the last context entry uses them is deleted.

This would still accommodate GKE, while not messing with user's stuff if user is reusing the "user"/"cluster". But more I think about it, if people don't have 1:1:1 mapping in their kubeconfig, they shouldn't use this feature.

[jfchevrette]

@ahmetb +1 I like your proposal a lot. I actually manage OpenShift clusters rather than GKE clusters. It shouldn't matter much though.

I also cannot think of a reason a kubeconfig wouldn't have a 1:1:1 mapping unless it was modified through other means.

I'm still unsure if there is a clean way to verify the 1:1:1 mapping with pure bash or if kubectx would have to depend on an external tool.

[ahmetb]

We can easily can do a grep -c search like user: $1 or cluster: $1 in the kubeconfig to view how many times a user/cluster is used.

Furthermore kubectl lets us to delete "cluster" entries, but I currently don't see a way to delete "user" entries. So I filed kubernetes/kubectl#396.

In the meanwhile, I'll try kubectl config set but that seems pretty hard to use (kubernetes/kubectl#398). Any help on how to delete a "user" is appreciated.

[ahmetb]

So I prototyped some stuff at #38, feel free to give it a try.

It only does a kubectl config delete-context $NAME (supports . as current-context, thanks for the idea @jfchevrette!). Here's why:

• I think kubectx -d is only useful for GKE(-like) users where there's 1:1:1 mapping
  • so I'm going to optimize this feature for these people
  • I realized as a GKE user I almost NEVER look inside what's in the kubeconfig file
• there's no point of figuring out "if user/cluster isn't used by other context entries"
  • this may lead to accidental/hard-to-predict deletion of manual entries
• there's no way of deleting "users" entries in kubeconfig via kubectl kubectl config: no commands to manage users kubernetes/kubectl#396

While I hate unused/leaked stuff in kubeconfig files, since I use GKE, I know that I can delete the entire ~/.kube/config and start from scratch anytime.

I think this will work fine, and I intend to merge the kubectx -d prototype at #38 in a week or so. (Try it out and give feedback!) This will be the last feature for v0.5.0 to ship. (We may break users by changing the -d behavior, but I don't care simply because kubectx is never meant to be used in scripting, and we discourage it actively).

[jfchevrette]

LGTM!

After reviewing the changes in #38 I updated my local copy and I deleted up a bunch of contexts that I wasn't using any more. Some with odd naming/characters and everything went as expected, no errors.

The only sort of issue comes from the fact kubectl config delete-context won't select a new context automatically if you delete the active context and so kubectx / kubectx - will behave in a weird way and will return errors like error: no context exists with the name: NAME until you select new contexts and the old one is gone from the .kube/kubectx file. I don't think this is a big deal though.

[ahmetb]

@jfchevrette I think we can improve that later, and at least delete-context output indicates you just deleted your current context. I think this is sufficient for v0.5.0.

For v0.6.0 we can consider:

• [NON-breaking] Deleting the .kube/kubectx file when that context is the one that's deleted.
• [NON-breaking] While cleaning up some stuff I realized whether we should be supporting multiple context names (e.g. kubectx -d NAME1[,NAME2,[...]]).
• [POSSIBLY breaking] Better cleanup of kubeconfig entries if it becomes possible through kubectl.