-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow runtimeClassName and dnsPolicy in service template spec #5306
Comments
Issues go stale after 90 days of inactivity. Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra. /lifecycle stale |
Stale issues rot after 30 days of inactivity. Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra. /lifecycle rotten |
Is there any reason |
/remove-lifecycle rotten This probably belongs with several other similar items around what can be in/out of Pods. |
Issues go stale after 90 days of inactivity. Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra. /lifecycle stale |
I couldn't find any reference for the reason runtimeClassName was disabled in the first place by the knative API. |
@snir911 this document describes the reasoning for not including |
I don't have access to the document, can you please make it public? |
You have to join knative-users group to get access. |
The recommendation from @JRBANCEL is to use Feature Flags to support RuntimeClass. Here is an example that adds support for node selector and affinity: #8645 Can this issue be reopened? |
Allow users to set runtimeClassName on services via the runtimeclassname feature flag. Issue knative#5306
Allow users to set runtimeClassName on services via the runtimeclassname feature flag. Issue knative#5306
Allow users to set runtimeClassName on services via the runtimeclassname feature flag. Issue knative#5306
* Add RuntimeClassName feature flag Allow users to set runtimeClassName on services via the runtimeclassname feature flag. Issue #5306 * Add validation test for RuntimeClassName
In what area(s)?
/area API
/kind spec
Describe the feature
Allow
runtimeClassName
anddnsPolicy
fields in the service template spec (currently disallowed here) in order to be able to run untrusted pods with knative.Example:
RuntimeClass
Different runtimes can be specified for knative services using:
However, this method is deprecated in favor of
runtimeClassName
https://kubernetes.io/docs/concepts/containers/runtime-class/
https://github.com/kata-containers/documentation/blob/master/how-to/containerd-kata.md
https://gvisor.dev/docs/user_guide/kubernetes/#using-containerd
dnsPolicy
According to the k8s docs:
In cases such as untrusted pods, it is undesirable to give access to the cluster dns.
The text was updated successfully, but these errors were encountered: