kubectl create alternatives

[pwittrock]

@eddiezane
@soltysh
@seans3

There have been numerous requests to expand the support for imperative resource creation commands by adding flags to existing creation commands or adding creation commands for additional resources.

The motivation for imperative create commands tend to fall into the following categories:

1. As a learning tool

• Used in courses to teach about the APIs
• Used in documentation to teach about the APIs
• Used by end users to discover new resource types and experiment with them
• As a debugging tool
  • Used to quickly create a Pod in a cluster with an attached tty
  • Used to quickly cretea a resource to test an image
• As an authoring tool
  • Used to bootstrap configuration for a new resource or package

Sig-cli and the kubectl maintainers have pushed back on expanding the functionality of the existing commands in favor of implementing new commands which better meet these needs.

Why the create commands as written today are a suboptimal solution

Why they are suboptimal as a learning tool

• Don't show the end user the resource configuration by default -- require -o yaml --dry-run
• Don't show the user the apply command
• Serialization populates the resource with a bunch of defaults that should not be present
• Doesn't support adding comments to the configuration to teach the user about the options

Why they are suboptimal as a debugging tool

• Don't support debug options such as mounting in debug tools
• Don't attach by default
• Not well integrated with other debug commands such as logs

Why they are suboptimal as an authoring tool

• Don't support extension types
• Work off the client version rather than the server version
• Populate the configuration with garbage fields
• Write to the server by default, requires -o yaml --dry-run

What we want in next-gen generation commands

Learning and creation commands

• Support for extension types and version skew. Examples:
  • Publish a template as part of the openapi-schema
  • Link to a file which is used as a template
  • Link to a field which is uses kustomize setters to populate fields
  • Use URL convention for build-in types to seed the command and support backward compatibility -- e.g. https://sigs.k8s.io/sig-cli/kubectl/gen
• Operate on yaml first
  • Support for commenting the configuration
  • Don't populate fields which are populated on serialization
• Write to stdout by default
  • Write to file with flag
  • Update a file in place by merging the generated contents
• Consider using the OpenAPI examples field and kustomize setters

Want needs to happen

• Convert this into a KEP
• Create a new directory and go module under cli-experimental or cli-utils
• Define a schema for publishing the creation metadata
  • Input fields (e.g. flags)
  • Template
• Implent client tooling to read the API definitions and dynamically register kubectl gen cobra commands
• Update the KEP with design decision changes
• Tweet about it to get feedback
• Send PR for review
• Write generation definitions for built-in types
• Update the docs
• Update release notes
• Tweet about it again

[fabiand]

This is also something we are interested in from the KubeVirt side cc @ashleyschuett

[eddiezane]

/priority backlog

[eddiezane]

@pwittrock we need to condense this to fit in the FAQ kubernetes/kubernetes#94989

[fejta-bot]

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]

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

[soltysh]

/remove-lifecycle rotten
/lifecycle frozen

[sftim]

How about a kubectl something subcommand that creates a sample manifest, perhaps with most fields commented out, and opens it in a text editor before doing anything further.

The user then edits the manifest locally in their text editor or IDE. On saving it, kubectl submits that to the control plane.

This approach could work for making new:

• Deployments
• StatefulSets
• Jobs
• VerticalPodAutoscalers
• MachinePools
• Gateways
• IngressClasses

and out-of-project things like:

• ImageRepositories
• ClusterIssuers
• (Argo) Rollouts
• Prometheuses

An alternative form of this command could write the manifest out but not edit it. Importantly, non-mandatory fields would be commented out, so this is different from doing a server-side dry run request and saving the result.

Generated fields such as .metadata.resourceVersion could be omitted entirely, as this command is there for making new resources (I'd expect kubectl to report a conflict rather than trying to autoresolve it).

[sftim]

Extra credit: also make this work for subresources.

[armujahid]

@sftim, I think kubectl generate will satisfy that use case. It's currently a work in progress (https://github.com/eddiezane/kubectl-generate).
We can generate a manifest, edit it in our favorite editor, then pipe it to kubectl apply to satisfy the use case you mentioned.

[ardaguclu]

This was enabled by kubernetes/enhancements#3638 already and I'm closing;
/close

[k8s-ci-robot]

@ardaguclu: Closing this issue.

In response to this:

This was enabled by kubernetes/enhancements#3638 already and I'm closing;
/close

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.