This adds an optional `GET` parameter `runsc-sandbox-metrics-filter` which can
be used to filter the set of sandbox metrics requested from each sandbox. In
cases where the metric client isn't interested in learning everything about
the sandboxes, this saves on RPC cost and latency.
This also has the benefit of reducing memory usage of the `metric-server`
further, as it does not need to hold onto data that it will not export.
As the sandbox process is untrusted, the metrics returned are double-checked
on the `metric-server` side to ensure that the filter was respected.
PiperOrigin-RevId: 521055953
Prior to this change, the `--metric-server-allow-unknown-root` flag was set
at the `runsc` top level, which made sense for the case where this needed to
be set in e.g. Docker runtime flags with auto-spawn. Since this is no longer
the supported mode, having this flag at the top level no longer makes sense.
This change moves this flag to be a subcommand flag of `runsc metric-server`
instead, and renames it to `--allow-unknown-root` (since it's obvious it's
about the metric server now).
This change is backwards-incompatible to anyone who was specifying this flag,
but as this feature is very new and this flag was never documented, hopefully
this isn't much of a disruption.
Same deal for `--metric-exporter-prefix`, though this one is used in the
`runsc export-metrics` subcommand as well, so duplicated it in both places.
PiperOrigin-RevId: 514580178
If you're interested in gVisor to the extent of reading this commit message,
please try out this platform and report about your experience!
[email protected]
This change also rewords Systrap's README file slightly.
PiperOrigin-RevId: 513042723
This medium instructs runsc to place the overlay-backing host file inside the
mount being overlayed itself. The file is placed inside the root directory of
the mount at path `.gvisor.overlay.img.{CID}/filestore-{random}`.
Note that the same volume may be mounted at various places in the same
container. Furthermore, the same volume may be mounted by multiple containers
in the same pod. So we create a filestore directory in the mount which is
unique to each container. This filestore directory hosts all the filestore
files for the mount for the given container. This directory is destroyed along
with the contianer on `runsc delete`.
The self medium based host file is a named file because it needs to be
discoverable via path traversal from the host. For the root mount, this allows
k8s to scan the container's root filesystem and apply local ephemeral storage
limits appropriately. This makes self medium appropriate for k8s usage.
Note that the overlay host file (MemoryFile) is a sparse file. Thankfully k8s
uses stat.st_blocks to perform accounting, not stat.st_size. stat.st_blocks
indicates the number of pages allocated towards a file, which works well with
sparse files.
PiperOrigin-RevId: 507301254
This is to make it clear that the host file will be created inside this
directory. This also makes it look cleaner when other medium options are added
later.
PiperOrigin-RevId: 505033408
--overlay2 flag supersedes --overlay flag. It allows more granular
configuration for overlayfs in runsc. It does so in two ways:
1. Allows to apply overlay on all mounts or only the root mount.
--overlay applies overlay to all mounts.
2. Allows to specify if overlay's upper layer should be backed by
container memory or disk. --overlay always used container memory.
Allowing tmpfs to be backed by a file on disk prevents the container
memory from bloating up. Note that the tmpfs filesystem tree will
still be stored in sentry memory.
Using overlay on the root filesystem, helps avoid expensive
communication with the gofer process. The root filesystem of the
container is not preserved across container lifecycle. So we don't
need to keep updating the host filesystem, which will anyways be
destroyed once the container is destroyed. It is wasted effort.
Instead we keep all the changes to the root filesystem in tmpfs which
is directly accessible by the sentry.
The host file is created as an unnamed file using O_TMPFILE. Support
has been added for sub-containers too. Save/restore support is
still lacking.
Co-authored-by: Andrei Vagin <[email protected]>
PiperOrigin-RevId: 491988485
This page does not document anything new, but it aims to be a
central document to list all the steps and considerations
necessary to run gVisor in a production environment.
This includes:
- How to make the decision to use sandboxing at all or not
(which security benefits sandboxing bring, how to think
about them).
- How to make the decision about which components to sandbox.
- What the security/performance tradeoffs are.
- How to minimize the performance impact.
- How to configure gVisor for best performance.
Also includes a crude comparative diagrams of various ways
to organize a typical production stack.
PiperOrigin-RevId: 466491023
- Explain the consequences of using KVM in a nested virtualization
environment.
- Mention GKE Sandbox proprietary platform.
- Fix command to check if the user is part of the `kvm` group.
- Small fixes here and there.
PiperOrigin-RevId: 465625190
A libpcap change broke tcpdump support in gvisor. As a result tcpdump
w/ libpcap> 1.10 fails with gvisor.
Updates #6664, #6699
PiperOrigin-RevId: 401633061
tcpdump is largely supported. We've also chose not to implement writeable
AF_PACKET sockets, and there's a bug specifically for promiscuous mode (#3333).
Fixes#173.
PiperOrigin-RevId: 380733686
Update the debugging example to use make to make sure the debuggable `runsc`
binary is installed as a docker runtime before attempting to start a container.
Also use nginx as an example container and Accept as an example break point
since it's easy to trigger.
PiperOrigin-RevId: 379393892
This adds a new short tutorial on how to run Knative services in gVisor by
enabling the runtime class feature flag for Knative.
Fixes#3634
PiperOrigin-RevId: 374999528
