2017-02-25 00:42:41 +00:00
|
|
|
### Addon-manager
|
|
|
|
|
|
2017-10-27 19:50:09 +00:00
|
|
|
addon-manager manages two classes of addons with given template files in
|
|
|
|
|
`$ADDON_PATH` (default `/etc/kubernetes/addons/`).
|
2017-02-25 00:42:41 +00:00
|
|
|
- Addons with label `addonmanager.kubernetes.io/mode=Reconcile` will be periodically
|
|
|
|
|
reconciled. Direct manipulation to these addons through apiserver is discouraged because
|
|
|
|
|
addon-manager will bring them back to the original state. In particular:
|
|
|
|
|
- Addon will be re-created if it is deleted.
|
|
|
|
|
- Addon will be reconfigured to the state given by the supplied fields in the template
|
|
|
|
|
file periodically.
|
2017-10-27 19:50:09 +00:00
|
|
|
- Addon will be deleted when its manifest file is deleted from the `$ADDON_PATH`.
|
2017-02-25 00:42:41 +00:00
|
|
|
- Addons with label `addonmanager.kubernetes.io/mode=EnsureExists` will be checked for
|
|
|
|
|
existence only. Users can edit these addons as they want. In particular:
|
|
|
|
|
- Addon will only be created/re-created with the given template file when there is no
|
|
|
|
|
instance of the resource with that name.
|
2017-10-27 19:50:09 +00:00
|
|
|
- Addon will not be deleted when the manifest file is deleted from the `$ADDON_PATH`.
|
2017-02-25 00:42:41 +00:00
|
|
|
|
|
|
|
|
Notes:
|
|
|
|
|
- Label `kubernetes.io/cluster-service=true` is deprecated (only for Addon Manager).
|
|
|
|
|
In future release (after one year), Addon Manager may not respect it anymore. Addons
|
|
|
|
|
have this label but without `addonmanager.kubernetes.io/mode=EnsureExists` will be
|
|
|
|
|
treated as "reconcile class addons" for now.
|
2017-10-27 19:50:09 +00:00
|
|
|
- Resources under `$ADDON_PATH` need to have either one of these two labels.
|
2017-02-25 00:42:41 +00:00
|
|
|
Otherwise it will be omitted.
|
|
|
|
|
- The above label and namespace rule does not stand for `/opt/namespace.yaml` and
|
|
|
|
|
resources under `/etc/kubernetes/admission-controls/`. addon-manager will attempt to
|
|
|
|
|
create them regardless during startup.
|
2016-05-20 16:27:42 +00:00
|
|
|
|
2017-02-25 00:42:41 +00:00
|
|
|
#### How to release
|
2016-05-20 16:27:42 +00:00
|
|
|
|
|
|
|
|
The `addon-manager` is built for multiple architectures.
|
|
|
|
|
|
|
|
|
|
1. Change something in the source
|
|
|
|
|
2. Bump `VERSION` in the `Makefile`
|
|
|
|
|
3. Bump `KUBECTL_VERSION` in the `Makefile` if required
|
|
|
|
|
4. Build the `amd64` image and test it on a cluster
|
|
|
|
|
5. Push all images
|
|
|
|
|
|
|
|
|
|
```console
|
|
|
|
|
# Build for linux/amd64 (default)
|
|
|
|
|
$ make push ARCH=amd64
|
Switch to k8s.gcr.io vanity domain
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.
2018-01-17 19:36:53 +00:00
|
|
|
# ---> staging-k8s.gcr.io/kube-addon-manager-amd64:VERSION
|
|
|
|
|
# ---> staging-k8s.gcr.io/kube-addon-manager:VERSION (image with backwards-compatible naming)
|
2016-05-20 16:27:42 +00:00
|
|
|
|
|
|
|
|
$ make push ARCH=arm
|
Switch to k8s.gcr.io vanity domain
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.
2018-01-17 19:36:53 +00:00
|
|
|
# ---> staging-k8s.gcr.io/kube-addon-manager-arm:VERSION
|
2016-05-20 16:27:42 +00:00
|
|
|
|
|
|
|
|
$ make push ARCH=arm64
|
Switch to k8s.gcr.io vanity domain
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.
2018-01-17 19:36:53 +00:00
|
|
|
# ---> staging-k8s.gcr.io/kube-addon-manager-arm64:VERSION
|
2016-05-20 16:27:42 +00:00
|
|
|
|
|
|
|
|
$ make push ARCH=ppc64le
|
Switch to k8s.gcr.io vanity domain
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.
2018-01-17 19:36:53 +00:00
|
|
|
# ---> staging-k8s.gcr.io/kube-addon-manager-ppc64le:VERSION
|
2016-11-18 13:52:21 +00:00
|
|
|
|
|
|
|
|
$ make push ARCH=s390x
|
Switch to k8s.gcr.io vanity domain
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.
2018-01-17 19:36:53 +00:00
|
|
|
# ---> staging-k8s.gcr.io/kube-addon-manager-s390x:VERSION
|
2016-05-20 16:27:42 +00:00
|
|
|
```
|
|
|
|
|
|
|
|
|
|
If you don't want to push the images, run `make` or `make build` instead
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[]()
|
