Bring back kubectl exec [POD] [COMMAND]

[howardjohn]

What happened?

kubernetes/kubernetes#125437 removed kubectl exec [POD] [COMMAND] in favor of only exec [POD] -- [COMMAND].

This adds unnecessary extra steps to the command and disparity with familiar tools like docker.

What did you expect to happen?

Command stays with a warning to indicate -- is preferred, but not made required

How can we reproduce it (as minimally and precisely as possible)?

kubectl exec POD ls will fail

Anything else we need to know?

I don't feel that removing this adds any value to users. Its not less code to maintain or anything -- all it seems to do is impose individual preferences on everyone in a backwards incompatible way. The fact it was "deprecated" for years doesn't really change much

Kubernetes version

$ kubectl version
Client Version: v1.31.3

Cloud provider

na

OS version

# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

Install tools

Container runtime (CRI) and version (if applicable)

Related plugins (CNI, CSI, ...) and versions (if applicable)

[k8s-ci-robot]

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[howardjohn]

Some additional context on why this is painful: ahmetb/kubectl-aliases#44 (comment)

/sig cli

[ardaguclu]

all it seems to do is impose individual preferences on everyone in a backwards incompatible way

I'm sorry if this feels that I'm imposing something and I'm open to discuss this further (although it is definitely not a backwards incompatible change because there is no mention about we'll keep this code block forever and deprecation of 5 years ago means that there is a very long time to take necessary actions). @soltysh I'd like to ask opinions as well, as he deprecated this in kubernetes/kubernetes#88460 due to a solid reason.

This adds unnecessary extra steps to the command and disparity with familiar tools like docker.

The reason of this removal is for better usability and standartization. Because as a maintainer even I have a hard time to find the correct usage of exec command and now, I believe, we have a standard way.

I assume that this change simply requires adding -- just before the command. Do you mean adding -- before command is the unnecessary extra step or there is another hidden implications of this change I'm not seeing?. Because according to in here, you just mention to use kex -some-flag ls instead of kex -some-flag -- ls.

Could you please elaborate in what way this removal causes issues?.

[ardaguclu]

/transfer kubectl
for better visibility

[ardaguclu]

Simply breaking scripts, tools, etc. for the sake of standartization is not something we would want. But it seems that in that case all need to do is to add --.

With respect to aliasing, kuberc will support aliasing kubernetes/kubernetes#125230 (comment) and it works with the current exec structure well;

apiVersion: kubectl.config.k8s.io/v1alpha1
kind: Preference
aliases:
- name: runx
  command: run
  flags:
  - name: image
    default: nginx
  - name: labels
    default: app=test,env=test
  - name: env
    default: DNS_DOMAIN=test
  - name: namespace
    default: test-kuberc-ns
  appendArgs:
  - test-pod-2
  - --
  - custom-arg1
  - custom-arg2

[soltysh]

@soltysh I'd like to ask opinions as well, as he deprecated this in kubernetes/kubernetes#88460 due to a solid reason.

Not sure if there's anything more for me to add here. Arguments like the one @ardaguclu quoted above wrt maintainability, and ease of understanding how each flag is applied, which are also mentioned in the linked issue (there specifically the problem was --namespace positioning were sufficient to allow us move forward. We've put a lot of effort into ensuring the deprecation period was extended more than official guidelines. I understand that this is indeed causing some issues to users, and I apologize for that, but I don't think we're inclined to introduce the removed notion.