Resource quota enforcement webhook #544
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 15 commits
June 12, 2019 14:40
|
@khogeland can you rebase this PR to the latest master to pick up the merged webhook changes? |
liyinan926
reviewed
Aug 20, 2019
khogeland
commented
Aug 27, 2019
| } | ||
|
|
||
| // TODO: There appears to be a deadlock in cache.WaitForCacheSync. Possibly related? https://github.com/kubernetes/kubernetes/issues/71450 | ||
| // For now, return immediately. There will be a short window after startup where quota calcuation is incorrect. |
There was a problem hiding this comment.
I'll try to hunt this down and file an issue against k8s (or determine if it's been fixed in a later version).
liyinan926
reviewed
Aug 27, 2019
liyinan926
approved these changes
Aug 28, 2019
akhurana001
pushed a commit
to lyft/spark-on-k8s-operator
that referenced
this pull request
May 5, 2020
* Cert configuration and reloading * Add support for strict webhook error handling * Improve webhook error handling * Don't deregister the webhook when failure policy is strict * standard error message capitalization * have the webhook parse its own configuration from flags * clean up cert provider code * Add explanation for skipping deregistration * Resource Quota enforcement webhook * Fix bad merge * Cleanup, fixes * Cleanup * Document the quota enforcer
jbhalodia-slack
pushed a commit
to jbhalodia-slack/spark-operator
that referenced
this pull request
Oct 4, 2024
* Cert configuration and reloading * Add support for strict webhook error handling * Improve webhook error handling * Don't deregister the webhook when failure policy is strict * standard error message capitalization * have the webhook parse its own configuration from flags * clean up cert provider code * Add explanation for skipping deregistration * Resource Quota enforcement webhook * Fix bad merge * Cleanup, fixes * Cleanup * Document the quota enforcer
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Presented for comment 👀 Will update with documentation. I've based this PR on one of my other PR branches that this depends on, so here is the isolated diff: khogeland/spark-on-k8s-operator@webhook-enhancements...khogeland:resource-quota-enforcement
This is a validating webhook for enforcing Resource Quotas at the SparkApplication level. This serves two main purposes: preventing deadlocks (see this JIRA item) and providing early backpressure to users who are hitting their quota limits.
It operates in basically the same way that the k8s pod-level quota controller does, using an informer to keep a running tally of (expected) resource usage in the background, with the validating webhook comparing the requested resources to the most recent usage. It calculates the expected usage for a given SparkApplication using the same logic that Spark uses internally, and also counts non-Spark pods in each namespace to allow for simple mixed workloads.
FWIW, this has been tested in several high-throughput clusters (although is unfortunately disabled due to a bug in the k8s version we're on).