koordinator-sh/koordinator

What happened test/e2e/slocontroller/ 里准备 slo-controller-config 的样板代码有一条会 panic 的分支，并且这段样板已经被复制了两份。 Where 第一处（既有）：test/e2e/slocontroller/batchresource.go，约 103-116 行 第二处（#3100 一字不差复制）：test/e2e/slocontroller/nodeprediction.go 两处形状相同： if isConfigCreated { needUpdate := false rollbackData := map[string]string{} if configMap.Data == nil { needUpdate = true // ← rollbackData 保持为空 } else if configMap.Data[configuration.ColocationConfigKey] != colocationEnabledConfigData { rollbackData[configuration.ColocationConfigKey] = configMap.Data[configuration.ColocationConfigKey] needUpdate = true } if _, ok := rollbackData[configuration.ColocationConfigKey]; ok && needUpdate { defer rollbackSLOConfigData(...) // ← Data == nil 时不会注册 } if needUpdate { newConfigMap :

Ref #2852. #2852's checklist scopes the Reservation plugin's QueueingHint work to the two event sources the plugin already registers: Pod/Delete and reservations.v1alpha1.scheduling.koordinator.sh Add/Update/Delete. PR #2927 implements QueueingHintFn for exactly those two. While auditing that PR, three further state changes turned up that can resolve a Reservation rejection but reach the plugin through no registered event source at all. They are not regressions introduced by #2927 — the plugin did not register these events before it either — but the scheduling framework requires a plugin to register every event that can resolve its own rejections, and Kubernetes 1.35 enables SchedulerQueueingHints by default. Left unregistered, an affected pod is only retried when some unrelated event happens to fire or its backoff is flushed. ReservationArgs.EnableQueueHint defaults to false, so nothing is broken today. These should land before that default changes. 1. The unschedulable pod's own

What happened: Reservation is a mechanism that Koordinator schedules as a pod not handled by the container runtime. Currently, the koord-scheduler supports using a reservation to preempt a low-priority pod. However, the NNN (nominatedNodeName) attribute is not defined in the Reservation API, so the scheduler may lose the nomination of the preemption result once the object is updated. In addition, the upcoming feature like KEP-5278 is missing for reservations without the NNN field. What you expected to happen: Add the field NominatedNodeName into the Reservation API. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: App version: Kubernetes version (use kubectl version): Install details (e.g. helm install args): Node environment (for koordlet/runtime-proxy issue): Containerd/Docker version: OS version: Kernal version: Cgroup driver: cgroupfs/systemd Others:

What happened applyCPUBurst and applyCFSQuotaBurst in pkg/koordlet/qosmanager/plugins/cpuburst/cpu_burst.go iterate only over pod.Status.ContainerStatuses, completely skipping pod.Status.InitContainerStatuses. During pod startup the currently-running init container has its own cgroup directory (the same layout as regular containers). Because neither function visits InitContainerStatuses, the init container's cgroup files are never touched: cpu.cfs_burst_us is left at its default (0 or whatever the container runtime wrote), so the init container cannot burst above its CPU limit even when CPUBurst is enabled. cpu.cfs_quota_us is never scaled by the CFSQuotaBurst strategy, so the init container is always throttled at its base quota regardless of node state. This can cause measurable pod startup slowdowns when init containers perform CPU-intensive work (e.g. copying files, running DB migrations). How to reproduce Visible in source at: pkg/koordlet/qosmanager/plugins/cpuburst/cpu_burst.g

What happened: nodeDevice.calcFreeWithPreemptible() assumes every device minor present in preemptible also exists in deviceTotal. Current logic: used := quotav1.SubtractWithNonNegativeResult(deviceUsed[minor], v) remaining := quotav1.SubtractWithNonNegativeResult(deviceTotal[minor], used) If a minor exists in preemptible but is absent from deviceTotal, deviceTotal[minor] returns a nil ResourceList. This can happen when: a device disappears from inventory, device cache state becomes temporarily inconsistent, or a preemptible snapshot becomes stale during rapid device churn. The current code still evaluates the phantom minor instead of skipping it. What you expected to happen: Minors absent from deviceTotal should be ignored entirely since they are no longer part of the tracked device inventory. How to reproduce it (as minimally and precisely as possible): Create a preemptible map containing a device minor that does not exist in deviceTotal. Run: go test ./pkg/scheduler/plugins/