Separate kubectl user preferences from cluster configs

[eddiezane]

Enhancement Description

• One-line enhancement description (can be used as a release note): Implement a .kuberc file to separate user preferences from cluster configs.
• Kubernetes Enhancement Proposal: https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/3104-introduce-kuberc/README.md
• Discussion Link: https://groups.google.com/g/kubernetes-dev/c/y4Q20V3dyOk/m/ozSUR3dJDQAJ
• Primary contact (assignee): @ardaguclu
• Responsible SIGs: cli
• Enhancement target (which target equals to which milestone):
  • Alpha release target (x.y): 1.33
  • Beta release target (x.y): 1.34
  • Stable release target (x.y):
• Alpha
  • KEP (k/enhancements) update PR(s):
    • KEP-3104: Introduce kuberc #3392
    • KEP-3104: Introduce kuberc - update for 1.31 #4705
    • KEP-3104: Update latest milestone to 1.32 #4860
    • Update kuberc example with finalized version #4925
  • Code (k/k) update PR(s): Introduce kuberc as new flag to customize defaulting and define aliases in kubectl kubernetes#125230
  • Docs (k/website) update PR(s):
    • Add KUBECTL_KUBERC environment variable description website#49722
• Beta
  • KEP (k/enhancements) update PR(s): KEP-3104: promote kuberc to beta #5300
  • Code (k/k) update PR(s):
    • Continue alias creation when __completion is used to enable completion kubernetes#131586
    • Manually read verbosity before kubectl command construction kubernetes#131668
    • Promote kuberc to beta kubernetes#131619 replaced with Promote kuberc to beta kubernetes#131818
    • Deprecate kubeconfig's preference field in favor of kuberc kubernetes#131741
    • Add e2e tests for kuberc kubernetes#131757
  • Docs (k/website) update(s):
    • Add documents for kuberc website#50913

Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[soltysh]

/milestone v1.25
/stage alpha

[jasonbraganza]

Hello @eddiezane 👋, 1.25 Enhancements team here.

Just checking in as we approach enhancements freeze on 18:00 PST on Thursday June 23, 2022.

For note, This enhancement is targeting for stage alpha for 1.25 (correct me, if otherwise)

Here's where this enhancement currently stands:

• KEP file using the latest template has been merged into the k/enhancements repo.
• KEP status is marked as implementable
• KEP has a updated detailed test plan section filled out
• KEP has up to date graduation criteria
• KEP has a production readiness review that has been completed and merged into k/enhancements.

Looks like for this one, we would need to update the following in the open PR #3392:

• Please update the status from provisional to implementable in the kep.yaml file
• Add a PRR approval file for stage alpha
• Please update the Test Plan and the Graduation Criteria sections in the README.md with details as appropriate.

For note, the status of this enhancement is marked as at risk. Please keep the issue description up-to-date with appropriate stages as well. Thank you!

[jasonbraganza]

Hello @eddiezane 👋🏿 Just checking in, as we are four days away from the enhancements freeze on Thursday, June 23, 2022 at 18:00 PM PT.

Please get the open PR #3392 merged with the suggestions in the previous comment

Please note: the current status of the enhancement is at-risk.
Thank you.

[parul5sahoo]

Hi @eddiezane 👋

Checking in once more as we approach 1.25 code freeze at 01:00 UTC on Wednesday, 3rd August 2022.

Please ensure the following items are completed:

• All PRs to the Kubernetes repo that are related to your enhancement are linked in the above issue description (for tracking purposes).

• All PRs are fully merged by the code freeze deadline.

There seems to no open or close PR in k/k. However, correct me if I am wrong and enlist the open or merged PRs in the comments. So, that we can mark the enhancement as tracked.

As always, we are here to help should questions come up.

Thanks!!

[cathchu]

Hey @eddiezane 👋

1.25 Release Docs Shadow here. Does this enhancement work planned for 1.25 require any new docs or modification to existing docs?
If so, please follows the steps here to open a PR against dev-1.25 branch in the k/website repo. This PR can be just a placeholder at this time and must be created before August 4.
Also, take a look at Documenting for a release to get yourself familiarize with the docs requirement for the release.
Thank you!

[parul5sahoo]

Hi @eddiezane 👋

Checking in once more as we approach 1.25 code freeze at 01:00 UTC on Wednesday, 3rd August 2022. Which is in two days

Please ensure the following items are completed:

• All PRs to the Kubernetes repo that are related to your enhancement are linked in the above issue description (for tracking purposes).

• All PRs are fully merged by the code freeze deadline.

[Priyankasaggu11929]

Hello 👋, 1.25 Enhancements Lead here.

Unfortunately, this enhancement did not meet the code freeze criteria because there are still unmerged k/k code PRs.

If you still wish to progress this enhancement in v1.25, please file an exception request. Thank you so much!

/milestone clear

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[lzung]

Hello @ardaguclu 👋, v1.33 Enhancements team here.

Just checking in as we approach enhancements freeze on 02:00 UTC Friday 14th February 2025 / 19:00 PDT Thursday 13th February 2025.

This enhancement is targeting stage alpha for v1.33 (correct me, if otherwise)
/stage alpha

Here's where this enhancement currently stands:

• KEP readme using the latest template has been merged into the k/enhancements repo.
• KEP status is marked as implementable for latest-milestone: v.133. KEPs targeting stable will need to be marked as implemented after code PRs are merged and the feature gates are removed.
• KEP readme has up-to-date graduation criteria.
• KEP has submitted a production readiness review request for approval and has a reviewer assigned.
• KEP has a production readiness review that has been completed and merged into k/enhancements. (For more information on the PRR process, check here).

With all the KEP requirements in place and merged into k/enhancements, this enhancement is all good for the upcoming enhancements freeze. 🚀

The status of this enhancement is marked as Tracked for enhancements freeze. Please keep the issue description up-to-date with appropriate stages as well. Thank you!

[rayandas]

Hello @eddiezane 👋, v1.33 Docs Lead here.

Does this enhancement work planned for v1.33 require any new docs or modification to existing docs?

If so, please follow the steps here to open a PR against dev-1.33 branch in the k/website repo. This PR can be just a placeholder at this time and must be created before Thursday 27th February 2025 18:00 PDT.

Also, take a look at Documenting for a release to get yourself familiarize with the docs requirement for the release.

Thank you!

[rytswd]

Hi @ardaguclu 👋 -- this is Ryota (@rytswd) from the 1.33 Communications Team!

For the 1.33 release, we are currently in the process of collecting and curating a list of potential feature blogs, and we'd love for you to consider writing one for your enhancement!

As you may be aware, feature blogs are a great way to communicate to users about features which fall into (but not limited to) the following categories:

• This introduces some breaking change(s)
• This has significant impacts and/or implications to users
• ...Or this is a long-awaited feature, which would go a long way to cover the journey more in detail 🎉

To opt in to write a feature blog, could you please let us know and open a "Feature Blog placeholder PR" (which can be only a skeleton at first) against the website repository by Wednesday, 5th March, 2025? For more information about writing a blog, please find the blog contribution guidelines 📚

Tip

Some timeline to keep in mind:

• 02:00 UTC Wednesday, 5th March, 2025: Feature blog PR freeze
• Monday, 7th April, 2025: Feature blogs ready for review
• You can find more in the release document

Note

In your placeholder PR, use XX characters for the blog date in the front matter and file name. We will work with you on updating the PR with the publication date once we have a final number of feature blogs for this release.

[lzung]

Hey again @ardaguclu 👋, 1.33 Enhancements team here,

Just checking in as we approach code freeze at 02:00 UTC Friday 21st March 2025 / 19:00 PDT Thursday 20th March 2025.

Here's where this enhancement currently stands:

• All PRs to the Kubernetes repo that are related to your enhancement are linked in the above issue description (for tracking purposes).
• All PR/s are ready to be merged (they have approved and lgtm labels applied) by the code freeze deadline. This includes tests.

With all the implementation (code related) PRs merged as per the issue description:

• Introduce kuberc as new flag to customize defaulting and define aliases in kubectl kubernetes#125230

Additionally, please let me know if there are any other PRs in k/k not listed in the description that we should track for this KEP, so that we can maintain accurate status.

This enhancement is now marked as tracked for code freeze for the 1.33 Code Freeze!

[rytswd]

Hi @ardaguclu 👋, 1.33 Communications Team here again!

This is a gentle reminder for the feature blog deadline mentioned above, which is 02:00 UTC Wednesday, 5th March, 2025. To opt in, please let us know and open a Feature Blog placeholder PR against k/website by the deadline. If you have any questions, please feel free to reach out to us!

Tip

Some timeline to keep in mind:

• 02:00 UTC Wednesday, 5th March, 2025: Feature blog PR freeze
• Monday, 7th April, 2025: Feature blogs ready for review
• You can find more in the release document

Note

In your placeholder PR, use XX characters for the blog date in the front matter and file name. We will work with you on updating the PR with the publication date once we have a final number of feature blogs for this release.

[mpuckett159-ias]

Proposed new user story:

As a user I'd like to be warned if my kuberc file is no longer being used after first use.

The idea for this is it is very easy to get in the habit of having the protections your kuberc file offers, but if something should happen to it (for example in alpha loading a new shell with the alpha env var no longer set) users may be surprised that kuberc is no longer in use. I suggest that we write an empty lock file (e.g. .kuberc-lck) to the .kube dir to track that the feature was used, and send warnings if the lock file is present but the kuberc file is not, or is not able to be successfully loaded. This will prevent users from mistakenly assuming that they are being protected by kuberc defaults, and can be easily silenced if they no longer wish to use the file, but won't break existing configs unless they have opted in to kuberc by exporting the env var for alpha, or running a command with a kuberc file that they have created.

[eddiezane]

Big +1. The first thing I did while demoing at KubeCon EU was open a new shell that didn't have the env exported and accidentally deleted my "prod" namespace.

[ardaguclu]

Wouldn't this be an issue specific to alpha and can not happen in beta, stable?.
In beta and stable, as long as kuberc is not turned off by this env var https://github.com/kubernetes/kubernetes/blob/195803cde570ad1025a78e36cdbef76bddbc4c33/staging/src/k8s.io/kubectl/pkg/kuberc/kuberc.go#L301, it will always use the kuberc file.

[mpuckett159-ias]

In beta it will always try to use the file but if something were to happen to the file it will fall back to default behavior, which uncovers all the same old foot guns from before except this time with more surprise since the user is expecting the safety net of the kuberc set defaults.

The proposed solution is not perfect because if something were to unexpectedly happen to the kuberc file itself, it is likely that any lock file would also be affected, but I wanted to provide at least some sort of suggestion. Env vars are too ephemeral, trying to add something to the cluster side is too cumbersome, so I settled on a lock file to at least try and help.

[soltysh]

/label lead-opted-in
/milestone v1.34
/stage beta