You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@yunikorn.apache.org by "Chen Yu Teng (Jira)" <ji...@apache.org> on 2022/12/20 07:23:00 UTC
[jira] [Comment Edited] (YUNIKORN-1253) PVCs won't get past WaitForFirstConsumer with Apache Yunikorn
[ https://issues.apache.org/jira/browse/YUNIKORN-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649605#comment-17649605 ]
Chen Yu Teng edited comment on YUNIKORN-1253 at 12/20/22 7:22 AM:
------------------------------------------------------------------
Update.
Hi [~ccondit] , sorry of late update.
I applied the pod adopting ephemeral and the yunikorn would correctly schedule the pod after yunikorn bind pvc created by template and pv.
The version of yunikorn and kubernetes is following:
1. Kubernetes version is 1.21.1
2. latest Yunikorn-k8shim
3. latest Yunikorn-core
was (Author: yukali):
Update.
Hi [~ccondit] , sorry of late update.
I apply the pod adopting ephemeral and the yunikorn would correctly schedule the pod after yunikorn bind pvc created by template and pv.
The version of yunikorn and kubernetes is following:
1. Kubernetes version is 1.21.1
2. latest Yunikorn-k8shim
3. latest Yunikorn-core
> PVCs won't get past WaitForFirstConsumer with Apache Yunikorn
> -------------------------------------------------------------
>
> Key: YUNIKORN-1253
> URL: https://issues.apache.org/jira/browse/YUNIKORN-1253
> Project: Apache YuniKorn
> Issue Type: Bug
> Components: shim - kubernetes
> Reporter: Alex Kalenyuk
> Assignee: Chen Yu Teng
> Priority: Major
> Attachments: case01_schedulingWhenPVisNotCreated.log, case01_yunikorn_scheduling_decision.log, pv.yaml, storageclass.yaml
>
>
> It seems that with Apache Yunikorn, WaitForFirstConsumer volume binding storage classes are not supported (not sure if this is intended or not).
> This makes it problematic to use storage that is not globally accessible from all nodes:
> [https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode]
> To reproduce a simple failure to use a WaitForFirstConsumer binding-backed PVC:
> ```
> kind: Pod
> apiVersion: v1
> metadata:
> name: test
> namespace: default
> labels:
> app: sleep
> applicationId: "sleep0001-node-selector-test"
> queue: "root.sandbox"
> spec:
> schedulerName: yunikorn
> nodeSelector:
> storage/ssd: 'true'
> containers:
> - name: test
> resources:
> limits:
> cpu: 1
> memory: 1G
> requests:
> cpu: 1
> memory: 1G
> image: busybox
> command:
> - sleep
> - '1000000'
> volumeMounts:
> - name: scratch-volume
> mountPath: /data
> volumes:
> - name: scratch-volume
> ephemeral:
> volumeClaimTemplate:
> spec:
> accessModes:
> - ReadWriteOnce
> resources:
> requests:
> storage: 1Gi
> storageClassName: hostpath-provisioner
> volumeMode: Filesystem
> ```
> Storage used:
> https://github.com/kubevirt/hostpath-provisioner-operator
> A similar issue was spotted in:
> [https://github.com/kubernetes/kubernetes/issues/86262]
> And this PR seems to introduce the VolumeBinding filter but comments it out:
> [https://github.com/apache/yunikorn-k8shim/pull/313]
>
> I might be off with the "Bug" type here so feel free to correct me;
> My thinking was that if introducing support for WFFC is trivial, this may make sense to exist in older versions too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@yunikorn.apache.org
For additional commands, e-mail: issues-help@yunikorn.apache.org