mirror of https://github.com/k3s-io/k3s
![]() 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 |
||
---|---|---|
.. | ||
CHANGELOG.md | ||
Dockerfile | ||
Makefile | ||
README.md | ||
kube-addons.sh | ||
namespace.yaml |
README.md
Addon-manager
addon-manager manages two classes of addons with given template files.
- 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.
- Addon will be deleted when its manifest file is deleted.
- 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.
- Addon will not be deleted when the manifest file is deleted.
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 withoutaddonmanager.kubernetes.io/mode=EnsureExists
will be treated as "reconcile class addons" for now. - Resources under $ADDON_PATH (default
/etc/kubernetes/addons/
) needs to have either one of these two labels. Meanwhile namespaced resources need to be inkube-system
namespace. 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.
How to release
The addon-manager
is built for multiple architectures.
- Change something in the source
- Bump
VERSION
in theMakefile
- Bump
KUBECTL_VERSION
in theMakefile
if required - Build the
amd64
image and test it on a cluster - Push all images
# Build for linux/amd64 (default)
$ make push ARCH=amd64
# ---> gcr.io/google-containers/kube-addon-manager-amd64:VERSION
# ---> gcr.io/google-containers/kube-addon-manager:VERSION (image with backwards-compatible naming)
$ make push ARCH=arm
# ---> gcr.io/google-containers/kube-addon-manager-arm:VERSION
$ make push ARCH=arm64
# ---> gcr.io/google-containers/kube-addon-manager-arm64:VERSION
$ make push ARCH=ppc64le
# ---> gcr.io/google-containers/kube-addon-manager-ppc64le:VERSION
$ make push ARCH=s390x
# ---> gcr.io/google-containers/kube-addon-manager-s390x:VERSION
If you don't want to push the images, run make
or make build
instead