Automatic merge from submit-queue (batch tested with PRs 50300, 50328, 50368, 50370, 50372)
Bugfix: set resources only for fluentd-gcp container.
There is more than one container in fluentd-gcp deployment. Previous
implementation was setting resources for all containers, not just
the fluent-gcp one.
**What this PR does / why we need it**:
Bugfix; https://github.com/kubernetes/kubernetes/pull/49009 without this is eating more resources.
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes#50366
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue
GKE deployment: Kill cluster/gke
kubernetes/test-infra#3983 migrated the remaining GKE jobs using the bash deployment (cluster/gke). All jobs are now on the gke `deployer` in `kubetest`.
Fixeskubernetes/test-infra#3307
```release-note
`cluster/gke` has been removed. GKE end-to-end testing should be done using `kubetest --deployment=gke`
```
There is more than one container in fluentd-gcp deployment. Previous
implementation was setting resources for multiple containers, not just
the fluent-gcp one.
Automatic merge from submit-queue
Ensure that pricing expander is used by default in Cluster Autoscaler
Pricing expander was set as the default one for GCP, however on some occasion it was possible that AUTOSCALER_EXPANDER_CONFIG variable was not set resulting in using the the random expander.
Automatic merge from submit-queue (batch tested with PRs 48532, 50054, 50082)
Refactored the fluentd-es addon
Refactor fluentd-elasticsearch addon:
- Decrease the number of files by moving RBAC-related objects in the same files where they're used
- Move the fluentd configuration out of the image
- Don't use PVC to avoid leaking resources in e2e tests
- Fluentd now ingest docker and kubelet logs that are written to journald
- Disable X-Pack, because it's not free
Fixes https://github.com/kubernetes/kubernetes/issues/41462
Fixes https://github.com/kubernetes/kubernetes/issues/49816
Fixes https://github.com/kubernetes/kubernetes/issues/48973
Fixes https://github.com/kubernetes/kubernetes/issues/49450
@aknuds1 @coffeepac Could you please take a look?
```release-note
Fluentd DaemonSet in the fluentd-elasticsearch addon is configured via ConfigMap and includes journald plugin
Elasticsearch StatefulSet in the fluentd-elasticsearch addon uses local storage instead of PVC by default
```
Automatic merge from submit-queue (batch tested with PRs 48487, 49009, 49862, 49843, 49700)
Enable overriding fluentd resources in GCP
**What this PR does / why we need it**: This enables overriding fluentd resources in GCP, when there is a need for custom ones.
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 50119, 48366, 47181, 41611, 49547)
Add basic install and mount flexvolumes e2e tests
fixes https://github.com/kubernetes/kubernetes/issues/47010
These two tests install a skeleton "dummy" flex driver, attachable and non-attachable respectively, then test that a pod can successfully use the flex driver. They are labeled disruptive because kubelet and controller-manager get restarted as part of the flex install. IMO it's important to keep this install procedure as part of the test to isolate any bugs with the startup plugin probe code.
There is a bit of an ugly dependency on cluster/gce/config-test.sh because --flex-volume-plugin-dir must be set to a dir that's readable from controller-manager container and writable by the flex e2e test. The default path is not writable on GCE masters with read-only root so I picked a location that looks okay.
In the "dummy" drivers I trick kubelet into thinking there is a mount point by doing "mount -t tmpfs none ${MNTPATH} >/dev/null 2>&1", hope that is okay.
I have only tested on GCE and theoretically they may work on AWS but I don't think there is a need to test on multiple cloudproviders.
-->
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 46685, 49863, 50098, 50070, 50096)
GCE: Bump GLBC version to 0.9.6
Closes#50095
**Release note**:
```release-note
GCE: Bump GLBC version to 0.9.6
```
Automatic merge from submit-queue (batch tested with PRs 50103, 49677, 49449, 43586, 48969)
Run kazel on the entire tree
**What this PR does / why we need it**: part of #47558: auto-generate `BUILD` files on the entire tree, since this is what `gazelle` does, and it'll make subsequent reviews easier if less is changing.
**Release note**:
```release-note
NONE
```
/assign
/release-note-none
Automatic merge from submit-queue (batch tested with PRs 48365, 49902, 49808, 48722, 47045)
Upgrade fluentd-elasticsearch addon to Elasticsearch/Kibana 5.5
This is a patch to upgrade the fluentd-elasticsearch addon to Elasticsearch/Kibana 5.5. Please provide feedback!
```release-notes
* Upgrade Elasticsearch/Kibana to 5.5.1 in fluentd-elasticsearch addon
* Switch to basing our image of Elasticsearch in fluentd-elasticsearch addon off the official one
* Switch to the official image of Kibana in fluentd-elasticsearch addon
* Use StatefulSet for Elasticsearch instead of ReplicationController, with persistent volume claims
* Require authenticating towards Elasticsearch, as Elasticsearch 5.5 by default requires basic authentication
```
Automatic merge from submit-queue (batch tested with PRs 48365, 49902, 49808, 48722, 47045)
Rebase hyperkube image on debian-hyperkube-base, based on debian-base.
**What this PR does / why we need it**: saves all of the hyperkube image dependencies in a cacheable base image, rather than downloading them for every build (which is slow and flaky).
This way, at build time, we only need to pull down the hyperkube base image and add the hyperkube binary.
I've additionally based the base image on `debian-base` instead of `debian`, though we amusing end up reinstalling a bunch of the things we removed in `debian-base`.
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes#35058, at least partially
**Special notes for your reviewer**: I'm increasingly convinced that the hyperkube image is a bad pattern, as this image carries the superset of dependencies anyone might need, rather than the limited set of dependencies one needs. hyperkube really needs a proper owner.
**Release note**:
```release-note
```
/assign @timstclair @luxas @philips @nikhiljindal
cc @kubernetes/sig-release-pr-reviews
Automatic merge from submit-queue (batch tested with PRs 49989, 49806, 49649, 49412, 49512)
Use existing k8s binaries and images on disk when they are preloaded to gce cos image.
**What this PR does / why we need it**:
This change is to accelerate K8S startup time on gce when k8s tarballs and images are already preloaded in VM image, by skipping the downloading, extracting and file transfer steps.
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 50029, 48517, 49739, 49866, 49782)
fix spelling
**What this PR does / why we need it**:
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
**Special notes for your reviewer**:
**Release note**:
```release-note
```
Automatic merge from submit-queue
Add parallelism to GCE cluster upgrade
Fixes https://github.com/kubernetes/kubernetes/issues/48373
Should allow upgrading 500-node cluster (1.6->1.7) in < 1 hr. It currently takes ~1.5 day.
Though it is the duty of the upgrader to choose the right parallelism in order to avoid disrupting too many pods.
/cc @kubernetes/sig-cluster-lifecycle-pr-reviews @kubernetes/sig-scalability-misc @mikedanese @gmarek
Automatic merge from submit-queue
[addon-manager] Remove unneeded annotation codes
**What this PR does / why we need it**:
Clean up addon-manager codes to make it less confusing. The annotation logics is only needed for 1.4->1.5 upgrade.
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 49898, 49897, 49919, 48860, 49491)
gce: make append_or_replace.. atomic
Before this change,
* the final echo is not atomically written to the target file
* two concurrent callers will use the same tempfile
Helps with https://github.com/kubernetes/kubernetes/issues/49895
cc @miekg
Automatic merge from submit-queue (batch tested with PRs 49898, 49897, 49919, 48860, 49491)
gce: extend CLOBBER_CONFIG to support known_tokens.csv
Helps with #49895
Automatic merge from submit-queue
Reduce kubectl calls from O(#nodes) to O(1) in cluster logdump
Ref https://github.com/kubernetes/kubernetes/issues/48513
Each node's logexporter is made to write a file to a GCS directory on success (https://github.com/kubernetes/test-infra/pull/3782).
We now use that directory as a registry of successful nodes and get it through a single "gsutil ls" call. This:
- reduces the current waiting time for logexporter in 5k-node cluster from >1hr to <10s.
- eliminates dependency on `kubectl logs` calls which seem to be unreliable sometimes (e.g when kubelet (or apiserver) is down)
/cc @kubernetes/sig-scalability-misc @wojtek-t @gmarek @fejta
Automatic merge from submit-queue (batch tested with PRs 49538, 49708, 47665, 49750, 49528)
Add a support for GKE regional clusters in e2e tests.
**What this PR does / why we need it**:
Add a support for GKE regional clusters in e2e tests.
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 49712, 49694, 49714, 49670, 49717)
set juju master charm state to blocked if the services appear to be failing
**What this PR does / why we need it**: set the juju master charm state to blocked if the services appear to be failing
**Release note**:
```release-note
set the juju master charm state to blocked if the services appear to be failing
```
Kubernetes Submit Queue