github/kubernetes
4
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
c6b098068d
kubernetes/cluster/addons/addon-manager
History
Kubernetes Submit Queue 4e20339916 Merge pull request #34513 from MrHohn/addon-manager-upgrade 
Automatic merge from submit-queue

Upgrade addon-manager with kubectl apply

The first step of #33698.

Use `kubectl apply` to replace addon-manager's previous logic.

The most important issue this PR is targeting is the upgrade from 1.4 to 1.5. Procedure as below:

1. Precondition: After the master is upgraded, new addon-manager starts and all the old resources on nodes are running normally.
2. Annotate the old ReplicationController resources with kubectl.kubernetes.io/last-applied-configuration=""
3. Call `kubectl apply --prune=false` on addons folder to create new addons, including the new Deployments.
4. Wait for one minute for new addons to be spinned up.
5. Enter the periodical loop of `kubectl apply --prune=true`. The old RCs will be pruned at the first call.

Procedure of a normal startup:

1. Addon-manager starts and no addon resources are running.
2. Annotate nothing.
3. Call `kubectl apply --prune=false` to create all new addons.
4. No need to explain the remain.

Remained Issues:
- Need to add `--type` flag to `kubectl apply --prune`, mentioned [here](https://github.com/kubernetes/kubernetes/pull/33075#discussion_r80814070).
- This addon manager is not working properly with the current Deployment heapster, which runs [addon-resizer](https://github.com/kubernetes/contrib/tree/master/addon-resizer) in the same pod and changes resource limit configuration through the apiserver. `kubectl apply` fights with the addon-resizers. May be we should remove the initial resource limit field in the configuration file for this specific Deployment as we removed the replica count.

@mikedanese @thockin @bprashanth 

---

Below are some logical things that may need to be clarified, feel free to **OMIT** them as they are too verbose:
- For upgrade, the old RCs will not fight with the new Deployments during the overlap period even if they use the same label in template:
 - Deployment will not recognize the old pods because it need to match an additional "pod-template-hash" label.
 - ReplicationController will not manage the new pods (created by deployment) because the [`controllerRef`](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/controller-ref.md) feature.
- As we are moving all addons to Deployment, all old RCs would be removed. Attach empty annotation to RCs is only for letting `kubectl apply --prune` to recognize them, the content does not matter.
- We might need to also annotate other resource types if we plan to upgrade them in 1.5 release:
 - They don't need to be attached this fake annotation if they remain in the same name. `kubectl apply` can recognize them by name/type/namespace.
 - In the other case, attaching empty annotations to them will still work. As the plan is to use label selector for annotate, some innocence old resources may also be attached empty annotations, they work as below two cases:
    - Resources that need to be bumped up to a newer version (mainly due to some significant update --- change disallowed fields --- that could not be managed by the update feature of `kubectl apply`) are good to go with this fake annotation, as old resources will be deleted and new sources will be created. The content in annotation does not matter.
    - Resources that need to stay inside the management of `kubectl apply` is also good to go. As `kubectl apply` will [generate a 3-way merge patch](https://github.com/kubernetes/kubernetes/blob/master/pkg/util/strategicpatch/patch.go#L1202-L1226).  This empty annotation is harmless enough.
2016-10-15 08:49:52 -07:00
..
Dockerfile Remove "All rights reserved" from all the headers. 2016-06-29 17:47:36 -07:00
kube-addons.sh Upgrade addon-manager with kubectl apply 2016-10-11 16:22:02 -07:00
Makefile Merge pull request #33484 from Yancey1989/bug_addons_sed 2016-10-14 23:30:07 -07:00
namespace.yaml run kube-addon-manager in a pod 2016-05-06 11:01:06 -07:00
README.md ConfigMap added to kube addon manager. 2016-07-11 13:54:18 +01:00

README.md

addon-manager

The addon-manager periodically checks for Kubernetes manifest changes in the /etc/kubernetes/addons directory, and when there's a new or changed addon, the addon-manager automatically kubectl creates it.

It supports ReplicationControllers, Deployments, DaemonSets, ConfigMaps, Services, PersistentVolumes and PersistentVolumeClaims.

The addon-manager is built for multiple architectures.

How to release

  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
# ---> 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

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

Analytics