github
/
k3s
mirror of https://github.com/k3s-io/k3s
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
k3s/cluster/addons/addon-manager
History
Martin Ostrowski ec7f7a5c5f Add code and yaml for Istio as an addon 
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.
 		2018-02-16 10:48:09 -08:00
..
CHANGELOG.md Update CHANGELOG.md 2017-12-06 09:45:27 +01:00
Dockerfile Bumps up Addon Manager to v6.0 with full support of kubectl apply --prune 2016-11-18 18:13:32 -08:00
Makefile Switch to k8s.gcr.io vanity domain 2018-02-07 21:14:19 -08:00
OWNERS Add a reviewer to addon-manager 2018-02-15 10:40:02 -08:00
README.md Switch to k8s.gcr.io vanity domain 2018-02-07 21:14:19 -08:00
kube-addons.sh Add code and yaml for Istio as an addon 2018-02-16 10:48:09 -08:00
namespace.yaml
…

README.md

Addon-manager

addon-manager manages two classes of addons with given template files in $ADDON_PATH (default /etc/kubernetes/addons/).

  • 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 from the $ADDON_PATH.
  • 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 from the $ADDON_PATH.

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.
  • Resources under $ADDON_PATH need to have either one of these two labels. Meanwhile namespaced resources need to be in kube-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.

  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
# Build for linux/amd64 (default)
$ make push ARCH=amd64
# ---> staging-k8s.gcr.io/kube-addon-manager-amd64:VERSION
# ---> staging-k8s.gcr.io/kube-addon-manager:VERSION (image with backwards-compatible naming)

$ make push ARCH=arm
# ---> staging-k8s.gcr.io/kube-addon-manager-arm:VERSION

$ make push ARCH=arm64
# ---> staging-k8s.gcr.io/kube-addon-manager-arm64:VERSION

$ make push ARCH=ppc64le
# ---> staging-k8s.gcr.io/kube-addon-manager-ppc64le:VERSION

$ make push ARCH=s390x
# ---> staging-k8s.gcr.io/kube-addon-manager-s390x:VERSION

If you don't want to push the images, run make or make build instead

Analytics