Deprecate the PodTemplate API

[hh]

The PodTemplate API is unused and increases the API surface needlessly.
It should be removed so it's not a default DoS vector.

From #81689 (comment)

Does anyone use the PodTemplate API?

It was created for #170, which was never implemented.

I'd bet a lot of clusters disable this API or set ResourceQuota to 0 so that it's not a DoS vector.

This should NOT be added to conformance.

@bgrant0607

I have never seen it used anywhere.

@liggitt

Can it be deprecated?

@johnbelamaric

/area conformance

[hh]

/sig architecture

[hh]

/assign @johnbelamaric

[hh]

/assign @liggitt

[bgrant0607]

I am supportive of deprecation. It will still be a year before we could remove it. In the meantime, we could document that we recommend disabling the API endpoint.

[liggitt]

I am supportive of deprecation. It will still be a year before we could remove it.

Agreed.

In the meantime, we could document that we recommend disabling the API endpoint.

We don't have the ability to switch on/off individual resources today, just API group/versions.

It should be removed so it's not a default DoS vector.

I'm not concerned about it as a DOS vector in the meantime since only cluster administrators have permission to read/write the API by default. I'm in favor of removal to avoid confusion.

[alejandrox1]

What would be a good first step to move this issue forward?

[hh]

Next steps: find Deprecation steps from the developer perspective.
@ii will turn that into Documentation if necessary

[hh]

From https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api :

Rule #1: API elements may only be removed by incrementing the version of the API group.

PodSpec is core/v1. Does that mean it can only be dropped in core/v2?

Note: For historical reasons, there are 2 “monolithic” API groups - “core” (no group name) and “extensions”. Resources will incrementally be moved from these legacy API groups into more domain-specific API groups.

Does this mean we can drop it from core/v1 without having a core/v2?

[hh]

To be clear these are the API Operations we are choosing to drop:

PodTemplate v1 core

• List
• ListAllNamespaces
• Watch
• WatchList
• Create
• Read
• Patch
• Replace
• Delete
• DeleteCollection

[hh]

/area api-machinery

[k8s-ci-robot]

@hh: The label(s) area/api-machinery 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:

/area api-machinery

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.

[hh]

/sig api-machinery
/area api-review

[k8s-ci-robot]

@hh: The label(s) area/api-review 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 api-machinery
/area api-review

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.

[KnVerey]

Does anyone use the PodTemplate API?

For what it's worth, we use it at Shopify. In fact, it is used by our open-source tool https://github.com/Shopify/kubernetes-deploy#kubernetes-run. Specifically, it supports a workflow that allows our developers to run specific, code-reviewed commands in production:

1. The developer's deploy includes a PodTemplate resource representing the configuration required to run the current stable version of their app container (which changes on every deploy and may require many custom env vars, volume mounts, etc.)
2. The developer configures an internal tool with one or more "Run task" buttons, each of which generally references an entry in the procfile committed to their repo. When invoked, these retrieve the PodTemplate from the namespace and use it to instantiate an ephemeral Pod that will run the configured command. That pod's logs are streamed to the internal tool.

Are there other ways we could build this? Certainly. But this was an easy and elegant solution that currently works on any cluster as-is. Given how long it has been around, I wouldn't be surprised if others have similarly found their own uses for the PodTemplate API.

[johnbelamaric]

Given this is actually in use and not a threat, I am closing this issue.

/close

[k8s-ci-robot]

@johnbelamaric: Closing this issue.

In response to this:

Given this is actually in use and not a threat, I am closing this issue.

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

[tavin]

We are planning to use it for launching batch jobs from a previously deployed spec, where in particular the docker image reference in the spec corresponds to a build number that is "released" to the environment where the kubernetes cluster sits.

[johnbelamaric]

https://www.hyrumslaw.com/