mirror of https://github.com/linkerd/linkerd2.git
3222778191
Closes #7980 A pod is considered `Burstable` instead of `Guaranteed` if there exists at least one container in the pod that specifies CPU/memory limits/requests that do not match. The `linkerd-init` container falls into this category meaning that even if all other containers in a Pod have matching CPU/memory limits/requests, the Pod will not be considered `Guaranteed` because of `linkerd-init`'s hardcoded values. This changes the values to match, meaning that `linkerd-init` will not be the culprit container if a Pod is not considered `Guaranteed`. Raising the requests—instead of lowering the limits—felt like the safer option here. This means that the container will now always be guaranteed these amounts _and_ will never use more. [Docs](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#create-a-pod-that-gets-assigned-a-qos-class-of-guaranteed) explain this in more detail. Signed-off-by: Kevin Leimkuhler <kleimkuhler@icloud.com> |
||
|---|---|---|
| .. | ||
| fake | ||
| metrics.go | ||
| webhook.go | ||
| webhook_test.go | ||