[
https://issues.apache.org/jira/browse/YUNIKORN-2369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig Condit updated YUNIKORN-2369:
-----------------------------------
Description:
YUNIKORN-1273 added support to create unique application IDs instead of
grouping pods within a given namespace into a single application. However,
using this feature in combination with the YuniKorn admission controller
results in a failure to accept pods, as the pod UID (used in the generated
identifier) has not yet been created when admission controllers run.
For example, given a pod UID of *deadbeefcafe* running in namespace {*}test{*},
the expected application ID is {*}test-deadbeefcafe{*}. However, since the pod
UID is not present when the admission controller runs, this evaluates to
`test-` and results in the pod being rejected by Kubernetes since labels must
contain only alphanumeric characters and "-", and must start end end with
alphanumeric characters.
One way to solve this would be to set the applicationId label in the admission
controller to something like *test-uniqueautogen* and then have the scheduler
interpret the presence of the *-uniqueautogen* suffix as a request to use the
pod UID as part of the name (since it will be available to the scheduler). This
satisfies the original design of YUNIKORN-1273, which was to make the
identifiers predictable (since they contain the pod UID), unique (as they still
are UIDs) and consistent between restarts of the scheduler. A drawback to this
approach is that the applicationId label will not reflect the real
applicationId used.
was:
YUNIKORN-1273 added support to create unique application IDs instead of
grouping pods within a given namespace into a single application. However,
using this feature in combination with the YuniKorn admission controller
results in a failure to accept pods, as the pod UID (used in the generated
identifier) has not yet been created when admission controllers run.
For example, given a pod UID of `deadbeefcafe` running in namespace `test`, the
expected application ID is `test-deadbeefcafe`. However, since the pod UID is
not present when the admission controller runs, this evaluates to `test-` and
results in the pod being rejected by Kubernetes since labels must contain only
alphanumeric characters plus `-`, and must start end end with alphanumeric
characters.
One way to solve this would be to set the applicationId label in the admission
controller to something like `test-uniqueautogen` and then have the scheduler
interpret the presence of the `-uniqueautogen` suffix as a request to use the
pod UID as part of the name (since it will be available to the scheduler). This
satisfies the original design of YUNIKORN-1273, which was to make the
identifiers predictable (since they contain the pod UID), unique (as they still
are UIDs) and consistent between restarts of the scheduler.
> Using unique generated Application IDs breaks scheduling
> --------------------------------------------------------
>
> Key: YUNIKORN-2369
> URL: https://issues.apache.org/jira/browse/YUNIKORN-2369
> Project: Apache YuniKorn
> Issue Type: Bug
> Components: shim - kubernetes
> Reporter: Craig Condit
> Assignee: Craig Condit
> Priority: Critical
>
> YUNIKORN-1273 added support to create unique application IDs instead of
> grouping pods within a given namespace into a single application. However,
> using this feature in combination with the YuniKorn admission controller
> results in a failure to accept pods, as the pod UID (used in the generated
> identifier) has not yet been created when admission controllers run.
> For example, given a pod UID of *deadbeefcafe* running in namespace
> {*}test{*}, the expected application ID is {*}test-deadbeefcafe{*}. However,
> since the pod UID is not present when the admission controller runs, this
> evaluates to `test-` and results in the pod being rejected by Kubernetes
> since labels must contain only alphanumeric characters and "-", and must
> start end end with alphanumeric characters.
> One way to solve this would be to set the applicationId label in the
> admission controller to something like *test-uniqueautogen* and then have the
> scheduler interpret the presence of the *-uniqueautogen* suffix as a request
> to use the pod UID as part of the name (since it will be available to the
> scheduler). This satisfies the original design of YUNIKORN-1273, which was to
> make the identifiers predictable (since they contain the pod UID), unique (as
> they still are UIDs) and consistent between restarts of the scheduler. A
> drawback to this approach is that the applicationId label will not reflect
> the real applicationId used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
