deployment: add minimal kustomize overlays for deploying plugins

[marquiz]

No description provided.

[samuelkarp]

Can we move these into a contrib folder rather than having kustomize at the root of the repo?

[marquiz]

Can we move these into a contrib folder rather than having kustomize at the root of the repo?

Moved to contrib/kustomize

[klihub]

Thank you ! This now LGTM.

[marquiz]

Updated: added (container) securityContext

[marquiz]

Update: added pod priorityClassName: system-node-critical to device-injector, hook-injector, network-device-injector, ulimit-adjuster and v010-adapter plugins

[mythi]

LGTM

[chrishenzie]

Generally LGTM. I have a few nits about the indentation of list items in the yamls but that's no big deal.

Would it be possible to drop a README in there that gives a TL;DR on how to use kustomize to install these (for folks like myself who are unfamiliar)?

[marquiz]

Updated: indentation of daemonset.yaml's fixed

[mikebrow]

couple comments

[mikebrow]

Suggested change

	imagePullPolicy: Always
	imagePullPolicy: IfNotPresent

[klihub]

IIUC, the default [ck]ustomization updates the daemonset to use the unstable image tag, and I thought that was the reason behind using an Always imagePullPolicy, which would make sense to me (to avoid countless late night WTF?-staring sessions at the terminal when testing).

@marquiz @mikebrow If we change the policy here in the daemonset declaration, can we then also kustomize it to Always in the same file where we change the tag to unstable ?

[marquiz]

Yeah, the idea was exactly that. The unstable is a rolling tag, always following the tip of the main branch. We don't have any "stable" (tagged by version tag) images yet and pull policy Always ensures that you get the latest devel build, not some weeks or months old.

I now dropped the imagePullPolicy field from the daemonset.yaml's alltogether and added a common kustomize component (included in all plugin overlays) that patches the pull policy to Always.

[mikebrow]

always image pull policy is good for forcing verification of access to private authentication required registries for pods in a multi-tenant situation...

if not present image pull policy is good for allowing pods to share container images that have already been cached

:latest tag is good for asking to check if there is a newer image on the registry every time

:version tags and SHAs are good for requesting a specific version of an image

[mikebrow]

we can discuss on the community call

[mikebrow]

kk discussed with klihub just need to mention somewhere in these that this is not for production use .. rather dev testing purposes..

[mikebrow]

Suggested change

	image: plugin:latest
	image: plugin:latest # image and tag "plugin:latest" are placeholders substituted via config

[mikebrow]

Suggested change

	- name: plugin
	- name: plugin # plugin name "plugin" is a placeholder substituted via config

[marquiz]

Major update: separate overlays for stable and unstable images

Define separate overlays for stable (released) and unstable images. Utilizes reusable kustomize components to minimize repetition. The stable image would always point to the latest tagged release and unstable use the latest development build from main. The image-stable will need to be updated just before tagging a release (so that the released version points to the correct image).

Usage would be like:

1. Install the latest release

   kubectl create -k "https://github.com/containerd/nri/contrib/kustomize/hook-injector"
   

2. Install a specific release

   kubectl create -k "https://github.com/containerd/nri/contrib/kustomize/hook-injector?ref=v0.10.0"
   

3. Install the latest development build:

   kubectl create -k "https://github.com/containerd/nri/contrib/kustomize/hook-injector/unstable"
   

[klihub]

@marquiz Thank you ! LGTM.

[klihub]

Major update: separate overlays for stable and unstable images
...
2. Install a specific release

kubectl create -k "https://github.com/containerd/nri/contrib/kustomize/hook-injector?ref=v0.10.0"

@marquiz I think this would be worth including in the documentation additions in PR (#196), because I suspect it will not be obvious for the average user.