The previous base image, debian-base:v1.0.0, is affected by
CVE-2017-14062. This change upgrades to the most recent Debian stretch
image from the following command:
```
$ gcloud container images list-tags k8s.gcr.io/debian-base-amd64
DIGEST TAGS TIMESTAMP
7e9f2f88b813 v1.0.1 2020-02-18T13:18:50
d7be39e143d4 v2.0.0 2019-11-01T13:14:18
5f25d97ece90 v1.0.0 2019-03-25T10:59:09
dddca919baec 1.0.0 2019-03-25T09:43:09
```
This marks kube-addon-manager version 9.1.5.
Change-Id: I02321a781fb19dd33c0a19671b56c0b12d9b52fd
The addon manager readme states
> - Addons with label `addonmanager.kubernetes.io/mode=EnsureExists` will be checked for
> existence only. Users can edit these addons as they want.
However, the start_addon function was using `kubectl apply` to create
resources regardless of mode. This change switches between `kubectl
create` and `kubectl apply` depending on mode.
Additionally implemented tests for create_resource fn
- Refactor functions and main executable
- Quick tests in bash
- Tests for Reconcile, EnsureExists behavior
- Check for completeness with multi resource configs
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 (batch tested with PRs 42379, 42668, 42876, 41473, 43260)
Silence error messages from the docker rmi call we expect to fail
**What this PR does / why we need it**: when we removed `docker tag -f` in #34361 we added a bunch of `docker rmi` calls to preserve behavior for older docker versions. That step is usually a no-op, however, and results in confusing messages like
```
Tagging docker image gcr.io/google_containers/kube-proxy:c8d0b2e7a06b451117a8ac58fc3bb3d3 as gcr.io/kubernetes-release-test/kube-proxy-amd64:v1.5.4
Error response from daemon: No such image: gcr.io/kubernetes-release-test/kube-proxy-amd64:v1.5.4
```
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes#42665
**Special notes for your reviewer**: I could probably remove the `docker rmi` calls entirely, though I don't know if folks are still using docker < 1.10. (I think Jenkins still has 1.9.1.)
**Release note**:
```release-note
NONE
```
cc @jessfraz
Automatic merge from submit-queue
fix sed command run failed on mac os
bash command ```sed -i ... ``` run failed on mac os, it should be ```sed -i.back ..```
