Add ability to use another runtime besides docker for krm function image plugins

[snuggie12]

Is your feature request related to a problem? Please describe.

Describe the solution you'd like
We're considering adding krm functions as image plugins to our setup, but we use argocd to deploy without any CI systems.

This leaves us with a few options I can think of:

• Everything must be run client-side and checked into git requiring our devs to have docker setup and remember to run kustomize ahead of time.
• Use CI and some sort of DRY/WET setup and have argocd read the WET resources.
• Put docker into the argocd-repo-server pod.

For the docker option we actually have a few options:

• Docker out of docker. I think this will no longer be supported in some later version of k8s like 1.23 when the runtime is removed from the node?
• Docker in docker. I read a blog article saying the runtime deprecation also affects this, but not entirely sure why that is. The solution I'm referring to would be have the daemon as a sidecar and a static-linked binary for the docker client in the same container as the argocd binary.
• Support other runtimes that are more lightweight. I already got this working using a static-linked version of podman, but in the deprecation article it mentions img and kaniko as well.

Describe alternatives you've considered

See above. Though the podman one works I don't know if I want to put all my eggs into a custom-built version of something and would prefer a more official solution.

The other alternative is to use the non-docker version of the plugin like exec or golang, but then we have to go back to configuring all of our devs with the plugins locally, right?

Additional context

If there are any other possibilities of solving this issue (i.e. running a custom generator/transformer that references a docker container KRM function inside of a pod on a live cluster,) please let me know.

[Shell32-Natsu]

Use CI and some sort of DRY/WET setup and have argocd read the WET resources.

That sounds like a reasonable solution.

The other alternative is to use the non-docker version of the plugin like exec or golang, but then we have to go back to configuring all of our devs with the plugins locally, right?

If your CD tool can run the executable exec plugin then I guess you don't need to configure every dev env?

Currently we have no plan to add support for other KRM function runtime.

[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-contributor-experience at kubernetes/community.
/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-contributor-experience at kubernetes/community.
/lifecycle rotten

[irvifa]

/remove-lifecycle rotten

[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 active 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 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 rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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:

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

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

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active 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:

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

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

/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.