#380 Add support for setting priorityClassName for coordinator and workers #381
Conversation
|
Thank you for your pull request and welcome to the Trino community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. Continue to work with us on the review and improvements in this PR, and submit the signed CLA to [email protected]. Photos, scans, or digitally-signed PDF files are all suitable. Processing may take a few days. The CLA needs to be on file before we merge your changes. For more information, see https://github.com/trinodb/cla |
|
Just emailed signed CLA. |
|
Thank you for your pull request and welcome to the Trino community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. Continue to work with us on the review and improvements in this PR, and submit the signed CLA to [email protected]. Photos, scans, or digitally-signed PDF files are all suitable. Processing may take a few days. The CLA needs to be on file before we merge your changes. For more information, see https://github.com/trinodb/cla |
|
Thank you for your pull request and welcome to the Trino community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. Continue to work with us on the review and improvements in this PR, and submit the signed CLA to [email protected]. Photos, scans, or digitally-signed PDF files are all suitable. Processing may take a few days. The CLA needs to be on file before we merge your changes. For more information, see https://github.com/trinodb/cla |
Issue #380
In Kubernetes,
priorityClassNameis an important scheduling control that determines the relative importance of pods. By assigning aPriorityClass, cluster operators can ensure that critical workloads are scheduled before lower-priority ones and are less likely to be evicted under resource pressure.In multi-tenant or shared Kubernetes clusters, resource contention is common. Without a
priorityClassName, the pods may be scheduled with default priority, meaning they compete equally with less critical workloads. Allowing operators to assign a high priority ensures the pods are less likely to be preempted or evicted during node pressure events.Supporting
priorityClassNamein the Helm chart improves reliability, aligns with Kubernetes best practices, and gives operators control over pod scheduling and eviction policies, all with minimal implementation overhead.