Add support for the v2-shim integration with containerd. This registers
a runtimeClass named 'kata', utilizing the containerd-shim-kata-v2
binary.
This change adds volume mounts (hopefully temporarily) for
/usr/local/bin, as containerd requires the shim binary be within the
existing path.
Fixes: #323
Signed-off-by: Eric Ernst <eric.ernst@intel.com>
kata-deploy inserts 'manage_network_ns_lifecycle' into crio.conf without any
prior checks and if there is a previous entry in the file, this becomes a
duplicate causing crio service restart issues. This patch addresses that
particular scenario.
Signed-off-by: Ganesh Maharaj Mahalingam <ganesh.mahalingam@intel.com>
With the 1.5 release, we made several changes:
-simplification of daemonsets
-introduction of runtimeClass
Update documentation to take this into account.
Signed-off-by: Eric Ernst <eric.ernst@intel.com>
Before the kata-deploy container image was intended to be
used with only Kubernetes. This commit adds a script for configuring
Kata to run with Docker.
This assumes > release 1.5 of Kata, as Firecracker is being configured
as well as QEMU based Kata. Note, in order for this to work, Docker must
be configured to use a block-based storage driver.
To succeed, it the following directories must be mounted:
- /opt/kata - this is the location that the kata artifacts are stored
- /run/systemd - for reloading the docker service
- /var/run/dbus - for reloading the docker service
- /etc/docker - for updating the docker configuration (daemon.json)
usage: kata-deploy-kata [install | remove]
Signed-off-by: Eric Ernst <eric.ernst@intel.com>
Simplify the yaml and combine the prior scripts. The resulting script,
kata-deploy.sh, is used for install and configuration and
removal for CRI-O and containerd. While this could be used standalone
outside of daemonsets, today it will sleep infinity after processing the
request, since it is assumed to be called by a daemon.
By checking the CRI runtime within the script itself, we no longer need
to support many daemonsets for deploy - just a single. Still requires a
seperate cleanup daemonset (for restarting the CRI runtime), and an
RBAC.
Verified with CRI-O -- containerd testing WIP
Throwing this up now for feedback since I do not bash good.
Signed-off-by: Eric Ernst <eric.ernst@intel.com>
Signed-off-by: Saikrishna Edupuganti <saikrishna.edupuganti@intel.com>
1.2.0 release changed the tarball file layout for the
Kata artifacts. Adjust scripts accordingly.
Fixes: #142
Signed-off-by: Eric Ernst <eric.ernst@intel.com>
kata-deploy container image changed format slightly as we've changed
the release tarball. Update to 1.2.0 and make adjustments accordingly.
Fixes: #135
Signed-off-by: Eric Ernst <eric.ernst@intel.com>
For 1.2.0 we are changing the format of the kata-deploy container image.
To avoid issues, pull an explicit version in our daemonset.
In a follow on PR we'll update the yaml/scripts to 1.2.0 format
Fixes: #135
Signed-off-by: Eric Ernst <eric.ernst@intel.com>
Now that initial files for kata-deploy have merged, we
have an initial image on dockerhub. s/egernst/katadocker
Fixes: #100
Signed-off-by: Eric Ernst <eric.ernst@intel.com>
A Dockerfile is created and reference daemonsets are also
provided for deploying Kata Containers onto a running Kubernetes
cluster. A few daemonsets are introduced:
1) runtime-labeler: This daemonset will create a label on each node in
the cluster identifying the CRI shim in use. For example,
container-runtime=crio or container-runtime=containerd.
2) crio and containerd kata installer: Assuming either CRIO or
containerd is the CRI runtime on the node (determined based on label
from (1),, either the crio or containerd variant will execute. These daemonsets
will install the VM artifacts and host binaries required for using
Kata Containers. Once installed, it will add a node label kata-runtime=true
and reconfigure either crio or containerd to make use of Kata for untrusted workloads.
As a final step it will restart the CRI shim and kubelet. Upon deletion,
the daemonset will remove the kata binaries and VM artifacts and update
the label to kata-runtime=cleanup.
3) crio and containerd cleanup: Either of these two daemonsets will run,
pending the container-runtime label value and if the node has label
kata-runtime=cleanup. This daemonset simply restarts crio/containerd as
well as kubelet. This was not feasible in a preStepHook, hence the
seperate cleanup step.
An RBAC is created to allow the daemonsets to modify labels on the node.
To deploy kata:
kubectl apply -f kata-rbac.yaml
kubectl apply -f kata-deploy.yaml
To remove kata:
kubectl delete -f kata-deploy.yaml
kubectl apply -f kata-cleanup.yaml
kubectl delete -f kata-cleanup.yaml
kubectl delete -f kata-rbac.yaml
This initial commit is based on contributions by a few folks on
github.com/egernst/kata-deploy
Also-by: Saikrishna Edupuganti <saikrishna.edupuganti@intel.com>
Signed-off-by: Eric Ernst <eric.ernst@intel.com>
Signed-off-by: Jon Olson <jonolson@google.com>
Signed-off-by: Ricardo Aravena <raravena@branch.io>
Signed-off-by: Eric Ernst <eric.ernst@intel.com>
