k8s.io/kubernetes@v1.31.0-alpha.0.0.20240520171757-56147500dadc/cluster/addons/addon-manager/README.md (about)

     1  ### Addon-manager
     2  
     3  addon-manager manages two classes of addons with given template files in
     4  `$ADDON_PATH` (default `/etc/kubernetes/addons/`).
     5  - Addons with label `addonmanager.kubernetes.io/mode=Reconcile` will be periodically
     6  reconciled. Direct manipulation to these addons through apiserver is discouraged because
     7  addon-manager will bring them back to the original state. In particular:
     8  	- Addon will be re-created if it is deleted.
     9  	- Addon will be reconfigured to the state given by the supplied fields in the template
    10  	file periodically.
    11  	- Addon will be deleted when its manifest file is deleted from the `$ADDON_PATH`.
    12  - Addons with label `addonmanager.kubernetes.io/mode=EnsureExists` will be checked for
    13  existence only. Users can edit these addons as they want. In particular:
    14  	- Addon will only be created/re-created with the given template file when there is no
    15  	instance of the resource with that name.
    16  	- Addon will not be deleted when the manifest file is deleted from the `$ADDON_PATH`.
    17  
    18  Notes:
    19  - Label `kubernetes.io/cluster-service=true` is deprecated (only for Addon Manager).
    20  In future release (after one year), Addon Manager may not respect it anymore. Addons
    21  have this label but without `addonmanager.kubernetes.io/mode=EnsureExists` will be
    22  treated as "reconcile class addons" for now.
    23  - Resources under `$ADDON_PATH` need to have either one of these two labels.
    24  Otherwise it will be omitted.
    25  
    26  #### Images
    27  
    28  addon-manager images are pushed to `registry.k8s.io`. As addon-manager is built for multiple architectures, there is an image per architecture in the format - `registry.k8s.io/addon-manager/kube-addon-manager-$(ARCH):$(VERSION)`.
    29  
    30  #### How to release
    31  
    32  The `addon-manager` is built for multiple architectures.
    33  
    34  1. Change something in the source
    35  2. Bump `VERSION` in the `Makefile`
    36  3. Bump `KUBECTL_VERSION` in the `Makefile` if required
    37  4. Build the `amd64` image and test it on a cluster
    38  5. Push all images
    39  
    40  ```console
    41  # Build for linux/amd64 (default)
    42  $ make push ARCH=amd64
    43  # ---> staging-k8s.gcr.io/addon-manager/kube-addon-manager-amd64:VERSION
    44  # ---> staging-k8s.gcr.io/addon-manager/kube-addon-manager:VERSION (image with backwards-compatible naming)
    45  
    46  $ make push ARCH=arm
    47  # ---> staging-k8s.gcr.io/addon-manager/kube-addon-manager-arm:VERSION
    48  
    49  $ make push ARCH=arm64
    50  # ---> staging-k8s.gcr.io/addon-manager/kube-addon-manager-arm64:VERSION
    51  
    52  $ make push ARCH=ppc64le
    53  # ---> staging-k8s.gcr.io/addon-manager/kube-addon-manager-ppc64le:VERSION
    54  
    55  $ make push ARCH=s390x
    56  # ---> staging-k8s.gcr.io/addon-manager/kube-addon-manager-s390x:VERSION
    57  ```
    58  
    59  If you don't want to push the images, run `make` or `make build` instead