v0.3.0 is the latest version of metrics-server, and brings a number of
internal stability improvements as well as some bugfixes and features.
NB: this currently disables Kubelet auth entirely, since this setup
needs to work on GKE for the tests, and GKE doesn't support delegated
Kubelet auth yet. When that's rectified, we can switch this over to
use secure options.
Automatic merge from submit-queue (batch tested with PRs 59767, 56454, 59237, 59730, 55479). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Change critical pods’ template to use priority
**What this PR does / why we need it**:
Change critical pods’ template to use priority
Thanks.
**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
ref #57471
**Special notes for your reviewer**:
**Release note**:
```release-note
```
This is the 2nd attempt. The previous was reverted while we figured out
the regional mirrors (oops).
New plan: k8s.gcr.io is a read-only facade that auto-detects your source
region (us, eu, or asia for now) and pulls from the closest. To publish
an image, push k8s-staging.gcr.io and it will be synced to the regionals
automatically (similar to today). For now the staging is an alias to
gcr.io/google_containers (the legacy URL).
When we move off of google-owned projects (working on it), then we just
do a one-time sync, and change the google-internal config, and nobody
outside should notice.
We can, in parallel, change the auto-sync into a manual sync - send a PR
to "promote" something from staging, and a bot activates it. Nice and
visible, easy to keep track of.
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Reduce Metrics Server memory requirement
**What this PR does / why we need it**:
Reduces memory requirements of Metrics Server.
This was tested on GCE. On 16 - node cluster with 30 user pods per node, Metrics Server consumes ~60MB of memory. For larger clusters, the base value matters even less, and the memory utilization will be lower, therefore this change is safe.
**Release note**:
```release-note
Reduce Metrics Server memory requirement
```
Automatic merge from submit-queue (batch tested with PRs 57252, 57168). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Reduce CPU and memory requests for Metrics Server Nanny
**What this PR does / why we need it**:
Metrics Server Nanny is a sidecar container that performs small computations every 5 minutes to scale Metrics Server resource requirements when cluster size changes. This change reduces the CPU and memory requests to free up unused resource.
**Release note**:
```release-note
Free up CPU and memory requested but unused by Metrics Server Pod Nanny.
```
Jordan Liggitt