You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As pointed out during code review, the CEL cost estimates are not considered
perfectly reliable. Therefore it is better to also do runtime checks.
Some downstream users might decide to allow CEL expressions to run
longer. Therefore the cost limit is now part of an Options struct.
kube-scheduler uses the default cost limit defined in the resource.k8s.io API,
which is the same cost limit that also the apiserver uses during validation.
// The Kubernetes CEL base environment sets the VAP cost limit.
135
-
//
136
-
// In DRA, the cost check is done only at validation time. At
137
-
// runtime, any expression that passed validation gets executed
138
-
// without interrupting it. The advantage is that it becomes
139
-
// easier to change the limit because stored expression do not
140
-
// suddenly fail after an up- or downgrade. The limit could
141
-
// even become a configuration parameter of the apiserver
142
-
// because that is the only place where the limit gets checked
143
-
//
144
-
// We cannot unset the cost limit
145
-
// (https://github.com/kubernetes/kubernetes/blob/9568a2ac145cf9be930e3da835f86c1e61f7f7c1/vendor/github.com/google/cel-go/cel/options.go#L512-L518). But
146
-
// we can set a high value that then never triggers
0 commit comments