When there are two or more values in KUBECTL_EXTRA_PRUNE_WHITELIST
kube-addons.sh wrongly generates "--prune-whitelist value1 value2"
Which kubectl parses as additional unknown flag[s]
Change-Id: I7661bda41ab7435e0e65eb0a662d1b16d2c14991
The bug seems to be currently dormant but I managed to trigger it in
some manual tests.
When the bug is triggered it appends empty --prune-whitelist without any
value which in turn can capture the next flag and can cause addon
manager to fail.
E.g. when bug is not triggered the kubectl command looks like this
```
kubectl ... --prune-whitelist extensions/v1beta1/Ingress --recursive ...
```
When it's triggered it will be
```
kubectl ... --prune-whitelist --recursive ...
```
which will capture the --recursive flag and will make addon-manager to
fail as there are no yamls in the top directory.
This commit adds the following:
- YAML for istio components to the addons directory (versions with
and without auth)
- logic to copy the appropriate YAML file into the addons manager
dir, depending on ENABLE_ISTIO and ISTIO_AUTH_TYPE env vars
- changes to addon manager script which allow plugins to exist in
namespace other than kube-system. This is needed for Istio
functionality
- additional initialization for Istio in addon manager.
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.
