Kubectl: Determine what happens to the "kubectl convert" functionality

Created on 25 Sep 2019 · 23Comments · Source: kubernetes/kubectl

kubectl convert is deprecated

The initial kubectl convert deprecation was announced prior to release 1.13. Following the Kubernetes deprecation policy, this kubectl subcommand is now eligible to be removed in release 1.17. The following are options for next steps as this convert functionality is removed from kubectl. If you have an opinion, please add comments to this issue so that we can quickly drive consensus and make a decision on which option we will pursue.

Convert as a Plugin
Convert as a Binary
Convert into the API Server
Drop convert functionality

Convert as a Plugin

We could move the kubectl convert code into a plugin named kubectl-convert. The invocation of the plugin would mimic the current command: kubectl convert.

Pro: Users depending on this functionality will still be able to convert resource versions.
Pro: The command will appear similar. Naming the plugin kubectl-convert will ensure kubectl users can type the same command: kubectl convert.
Con: The users will have to find and download this separate binary.
Con: The plugin would have to vendor in most of the Kubernetes.

Convert as a Binary

Pro: Users depending on this functionality will still be able to convert resource versions.
Con: The users will have to find and download this separate binary.
Con: The plugin would have to vendor in most of the Kubernetes.

Convert into the API Server

Pro: Users depending on this functionality will still be able to convert resource versions.
Pro: Convert code already lives in the API machinery.
Con: It may take a long time to get this into the API Server.

Drop convert functionality

Pro: This will be the simplest to implement; just remove kubectl convert subcommand code.
Con: Users depending on this functionality will NOT be able to convert resource versions.

arekubectl kincleanup lifecyclfrozen prioritimportant-soon siapi-machinery sicli

Source

seans3

Most helpful comment

Yeah, apologies for that we missed that bit in the last release, there will be binaries available in the upcoming 1.21 version and I'm planning to include them in the krew for ease of use.

soltysh on 24 Mar 2021

👍3 😕2

All 23 comments

/sig cli
/sig api-machinery
/area kubectl
/kind cleanup

seans3 on 25 Sep 2019

@seans3: The label(s) sig/apimachinery cannot be applied. These labels are supported: api-review, community/discussion, community/maintenance, community/question, cuj/build-train-deploy, cuj/multi-user, platform/aws, platform/azure, platform/gcp, platform/minikube, platform/other

In response to this:

/sig cli
/sig apimachinery
/area kubectl
/kind cleanup

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/test-infra repository.

k8s-ci-robot on 25 Sep 2019

/assign @liggitt
/assign @deads2k

seans3 on 25 Sep 2019

/assign @soltysh
/assign @pwittrock

seans3 on 25 Sep 2019

I think some of this going to come down on jordan, myself, and Daniel agreeing on the role of staging. I see it as a way to organize our components and some aspects of it are valid to depend upon (client-go and api for instance) and others makes less sense (a kube-controller-manager or kube-apiserver). I think building a separate command that lives near our internal APIs make sense and I'd rather do that that coerce it into a kube-apiserver subcommand. Doing that would give a cleaner example to others trying to build a similar thing (think of the position cert-manager is in today).

deads2k on 26 Sep 2019

Discussed this in the code organization call yesterday.

The Convert as a Binary option seemed like the best immediate step to unblock this. Placing the command within the k8s.io/kubernetes/cmd package to begin with would give it access to the internal types/conversions without needing to vendor anything. When the discussion about moving those types/conversions to staging is settled, the command could be moved to staging along with them, if desired.

(note that this differs from the Convert as a Plugin option only by the name of the command chosen... if we named the command kubectl-convert, and kept the invocation consistent with the current invocation, we would effectively have created a command that could be used as a plugin, if desired, or standalone)

liggitt on 4 Oct 2019

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

fejta-bot on 2 Jan 2020

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

fejta-bot on 1 Feb 2020

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

fejta-bot on 2 Mar 2020

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

k8s-ci-robot on 2 Mar 2020

/reopen
/remove-lifecycle rottem
/lifecycle frozen

soltysh on 4 Mar 2020

@soltysh: Reopened this issue.

In response to this:

/reopen
/remove-lifecycle rottem
/lifecycle frozen

k8s-ci-robot on 4 Mar 2020

Even if we'll have to install something extra, glad to see this command will remain available and without making a request to the API service (right?)

tavin on 13 Jul 2020

/priority important-soon

eddiezane on 22 Jul 2020

just curious, why is convert deprecated?

ghostsquad on 5 Aug 2020

convert contains inappropriate dependencies. convert necessarily depends on internal types (in order to convert), but kubectl should not depend on these. In fact, no software outside api server should depend on internal types.

seans3 on 5 Aug 2020

👍1

The deprecation plan is to create convert as a plugin or separate binary. So the functionality would still exist; just not in kubectl.

seans3 on 5 Aug 2020

👍3

Hey guys, where can I find the convert plugin ?
when i use Krew and do the kubectl krew search i dont see it in the list. Was this plugin released ?

angadrandhawa on 16 Dec 2020

👍1

@angadrandhawa I don't know where the binary is, but you can build from the source code:

go get -u k8s.io/kubernetes/cmd/kubectl-convert

superbrothers on 22 Dec 2020

👍3

I'm missing the kubectl convert feature, cannot find a plugin or binary. I need it to upgrade from 1.15. The command above does not work anymore. Please advise.

lagivan on 24 Mar 2021

Yeah, apologies for that we missed that bit in the last release, there will be binaries available in the upcoming 1.21 version and I'm planning to include them in the krew for ease of use.

soltysh on 24 Mar 2021

👍3 😕2

I'm missing the kubectl convert feature, cannot find a plugin or binary. I need it to upgrade from 1.15. The command above does not work anymore. Please advise.

In Konveyor Move2Kube we had added the conversion capability for kubernetes yamls. After installing move2kube BLEEDING_EDGE='true' bash <(curl https://raw.githubusercontent.com/konveyor/move2kube/main/scripts/install.sh), You will have to do move2kube translate -s <folder containing your k8s yamls>. If you are interested in specific kubernetes api resource verisons, you can create a cluster.yaml file, and edit the intended versions, and then add it to the same folder as your source, and move2kube will migrate your yamls to those specific versions.

If you would want to get the versions in a specific cluster, set it in context for your kubectl and then run move2kube collect, and a cluster yaml file will be created for your cluster in m2k_collect folder, which you can then add to the source folder.

This could be a stop gap solution till kubectl convert is released in 1.21 as @soltysh has mentioned.

Hope it helps.

ashokponkumar on 6 Apr 2021

I'm running

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.1", GitCommit:"5e58841cce77d4bc13713ad2b91fa0d961e69192", GitTreeState:"clean", BuildDate:"2021-05-12T14:18:45Z", GoVersion:"go1.16.4", Compiler:"gc", Platform:"linux/amd64"}

...and I can't use this command.

I'm confused, how do I use this? I have no clue yet how I migrate my deployments from extensions/v1beta1 to apps/v1. Amazon EKS update guide suggested to use this tool.

I also tried installing it from source, but got this error:

$ go get -u k8s.io/kubernetes/cmd/kubectl-convert
go get: k8s.io/[email protected] updating to
    k8s.io/[email protected] requires
    k8s.io/[email protected]: reading k8s.io/apiextensions-apiserver/go.mod at revision v0.0.0: unknown revision v0.0.0