runtime uses /dev/termination-log to write container termination
messages. If this file doesn't exist on the host the runtime tries
to create it. As /dev is read-only for intel-fpga-plugin container
attempt to create /dev/termination-log fails with this error:
Warning Failed kubelet, device-plugins-kubernetes-clearlinux-14-4.novalocal Error:
container create failed: container_linux.go:345: starting container process caused
"process_linux.go:430: container init caused \"rootfs_linux.go:58:
mounting \\\"/var/lib/kubelet/pods/d7262db5-e3fc-4b7b-bc2e-da245f600c4b/containers/intel-fpga-plugin/cddd0f76\\\"
to rootfs \\\"/var/lib/containers/storage/overlay/edd75bb94b1b4cf93ae1ea5c064945169fb329d0abdb56b7621cddfc721f6eda/merged\\\"
at \\\"/var/lib/containers/storage/overlay/edd75bb94b1b4cf93ae1ea5c064945169fb329d0abdb56b7621cddfc721f6eda/merged/dev/termination-log\\\"
caused \\\"open /var/lib/containers/storage/overlay/edd75bb94b1b4cf93ae1ea5c064945169fb329d0abdb56b7621cddfc721f6eda/merged/dev/termination-log: read-only file system\\\"\""
Setting terminationMessagePath to rw-mounted file system
/tmp/termination-log for the plugin container should fix this.
Fixes: #259
The default deployment gives rather wide host mounts.
Limited sysfs mount only to the subdirectory the plugin
needs.
Mounted sysfs and dev mounts read-only.
Added notes that FPGA plugin can be run as non-root user.
In preparations to get some of the images to hub.docker.com/intel,
start using intel/ prefix.
Moreover, set the Makefile variables so that the images built
by make [images|demos] can easily be pushed to any registry/org
by 'docker push' (e.g., by Jenkins).
Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
- used ENTRYPOINT instead of CMD in plugin and admission webhook
Dockerfiles to avoid duplicating commands in the pod yamls
- fixed path to deploy.sh script in fpga initcontainer Dockerfile
Added alternative builder for project images: buildah
https://github.com/containers/buildah
Considering that some of our plugins use CRI-O runtime it could be
a good idea to get rid of docker as a builder. It should allow us
not to run docker daemon at all, even for build purposes.
Kubernetes also goes this way encouraging users to switch to CRI
runtimes (CRI-O and containerd), so having non-docker builds supported
looks good from this perspective too.
