Skip to content
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

Closed
wilsonianb opened this issue Aug 27, 2019 · 10 comments · Fixed by #12897
Closed

Allow runtimeClassName and dnsPolicy in service template spec #5306

wilsonianb opened this issue Aug 27, 2019 · 10 comments · Fixed by #12897
Labels
area/API API objects and controllers kind/feature Well-understood/specified features, ready for coding. kind/spec Discussion of how a feature should be exposed to customers.
Milestone

Comments

@wilsonianb
Copy link

wilsonianb commented Aug 27, 2019

In what area(s)?

/area API
/kind spec

Describe the feature

Allow runtimeClassName and dnsPolicy fields in the service template spec (currently disallowed here) in order to be able to run untrusted pods with knative.

Example:

spec:
  runtimeClassName: 'kata-qemu' # or 'runsc' (gvisor)
  dnsPolicy: 'Default'
  ...

RuntimeClass

Different runtimes can be specified for knative services using:

annotations:
   io.kubernetes.cri.untrusted-workload: "true"

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:

“Default” is not the default DNS policy. If dnsPolicy is not explicitly specified, then “ClusterFirst” is used.

In cases such as untrusted pods, it is undesirable to give access to the cluster dns.

@wilsonianb wilsonianb added the kind/feature Well-understood/specified features, ready for coding. label Aug 27, 2019
@knative-prow-robot knative-prow-robot added area/API API objects and controllers kind/spec Discussion of how a feature should be exposed to customers. labels Aug 27, 2019
@eallred-google eallred-google added this to the Needs Triage milestone Oct 23, 2019
wilsonianb added a commit to wilsonianb/serving that referenced this issue Dec 3, 2019
wilsonianb added a commit to wilsonianb/serving that referenced this issue Dec 3, 2019
@knative-housekeeping-robot

Issues go stale after 90 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle stale.
Stale issues rot after an additional 30 days of inactivity and eventually close.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle stale

@knative-prow-robot knative-prow-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 24, 2020
@knative-housekeeping-robot

Stale issues rot after 30 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle rotten.
Rotten issues close after an additional 30 days of inactivity.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle rotten

@knative-prow-robot knative-prow-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Feb 23, 2020
@fvoznika
Copy link

Is there any reason runtimeClass is in the list of disabled fields? The choice of runtime should for the most part be transparent to the pod/container.

@evankanderson
Copy link
Member

/remove-lifecycle rotten

This probably belongs with several other similar items around what can be in/out of Pods.

@knative-prow-robot knative-prow-robot removed the lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. label Mar 18, 2020
@knative-housekeeping-robot

Issues go stale after 90 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle stale.
Stale issues rot after an additional 30 days of inactivity and eventually close.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle stale

@knative-prow-robot knative-prow-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 17, 2020
snir911 added a commit to snir911/serving that referenced this issue Aug 3, 2020
@snir911
Copy link

snir911 commented Aug 3, 2020

I couldn't find any reference for the reason runtimeClassName was disabled in the first place by the knative API.
By passing this field and testing with kata runtime it seems to work, would it make sense to enable it? what else is required in order to have it supported by Knative API?

@wilsonianb
Copy link
Author

@snir911 this document describes the reasoning for not including runtimeClassName and other fields in the service template spec
https://docs.google.com/document/d/1DY5t7LqGPOq5Jw5AixSgJY8S2VuQnTGzRpV6apY_nAI/edit#

@fvoznika
Copy link

fvoznika commented Aug 5, 2020

I don't have access to the document, can you please make it public?

@vagababov
Copy link
Contributor

You have to join knative-users group to get access.

@fvoznika
Copy link

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?

ianlewis added a commit to ianlewis/serving that referenced this issue Aug 15, 2020
Allow users to set runtimeClassName on services via the runtimeclassname
feature flag.

Issue knative#5306
ianlewis added a commit to ianlewis/serving that referenced this issue Aug 19, 2020
Allow users to set runtimeClassName on services via the runtimeclassname
feature flag.

Issue knative#5306
ianlewis added a commit to ianlewis/serving that referenced this issue Aug 24, 2020
Allow users to set runtimeClassName on services via the runtimeclassname
feature flag.

Issue knative#5306
knative-prow-robot pushed a commit that referenced this issue Aug 27, 2020
* Add RuntimeClassName feature flag

Allow users to set runtimeClassName on services via the runtimeclassname
feature flag.

Issue #5306

* Add validation test for RuntimeClassName
@dprotaso dprotaso reopened this Apr 28, 2022
@dprotaso dprotaso modified the milestones: Needs Triage, v1.5.0 Apr 28, 2022
@github-actions github-actions bot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/API API objects and controllers kind/feature Well-understood/specified features, ready for coding. kind/spec Discussion of how a feature should be exposed to customers.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants