mirror of
https://github.com/kata-containers/kata-containers.git
synced 2025-06-23 22:17:19 +00:00
3f0f1ceba0
We're introducing a workaround for enabling users to utilize inotify on mounts that are backed by virtiofs. Let's add some documentation on how this work. Signed-off-by: Eric Ernst <eric_ernst@apple.com>
31 lines
1.9 KiB
Markdown
31 lines
1.9 KiB
Markdown
# Kata Containers support for `inotify`
|
|
|
|
## Background on `inotify` usage
|
|
|
|
A common pattern in Kubernetes is to watch for changes to files/directories passed in as `ConfigMaps`
|
|
or `Secrets`. Sidecar's normally use `inotify` to watch for changes and then signal the primary container to reload
|
|
the updated configuration. Kata Containers typically will pass these host files into the guest using `virtiofs`, which
|
|
does not support `inotify` today. While we work to enable this use case in `virtiofs`, we introduced a workaround in Kata Containers.
|
|
This document describes how Kata Containers implements this workaround.
|
|
|
|
### Detecting a `watchable` mount
|
|
|
|
Kubernetes creates `secrets` and `ConfigMap` mounts at very specific locations on the host filesystem. For container mounts,
|
|
the `Kata Containers` runtime will check the source of the mount to identify these special cases. For these use cases, only a single file
|
|
or very few would typically need to be watched. To avoid excessive overheads in making a mount watchable,
|
|
we enforce a limit of eight files per mount. If a `secret` or `ConfigMap` mount contains more than 8 files, it will not be
|
|
considered watchable. We similarly enforce a limit of 1 MB per mount to be considered watchable. Non-watchable mounts will
|
|
continue to propagate changes from the mount on the host to the container workload, but these updates will not trigger an
|
|
`inotify` event.
|
|
|
|
If at any point a mount grows beyond the eight file or 1MB limit, it will no longer be `watchable.`
|
|
|
|
### Presenting a `watchable` mount to the workload
|
|
|
|
For mounts that are considered `watchable`, inside the guest, the `kata-agent` will poll the mount presented from
|
|
the host through `virtiofs` and copy any changed files to a `tmpfs` mount that is presented to the container. In this way,
|
|
for `watchable` mounts, Kata will do the polling on behalf of the workload and existing workloads needn't change their usage
|
|
of `inotify`.
|
|
|
|
|