What problem it solves

Containers share a single kernel, so a single kernel vulnerability can allow container escape, and running untrusted or potentially malicious code in them without additional isolation is not a good idea. gVisor addresses this by interposing an application kernel that limits the host kernel surface accessible to the application while still giving the application the features it expects.

Key features

• OCI runtime for existing container tooling — The `runsc` runtime implements the Open Container Initiative interface and integrates with Docker and Kubernetes, making it simple to run sandboxed containers with existing tooling.

  Source: README, runsc

• Build and test tooling — The project builds with Make and Bazel, supports x86_64 and ARM64, and provides standard test suites plus targeted test invocations through Makefile or Bazel targets.

  Source: README

Quick start

Copied verbatim from the project's README.

make release-tarball DESTINATION=bin/
sudo tar -C /usr/local/bin -xf bin/gvisor.tar.bz2

Who it may suit

Inference: may suit teams that need to run untrusted or potentially malicious code in containers and want an isolation layer between applications and the host kernel, as well as developers importing gVisor subpackages such as userspace networking via Netstack.

Topics to discuss

• How does the sentry architecture compare in practice with running containers directly on a shared host kernel?

• What workloads see the largest behavior differences when running under `runsc` rather than a standard runtime?

• How should operators tune the balance between isolation and application compatibility when adopting an application kernel?

Written by ReadmeX AI from the project's README, source and public GitHub data; it may contain mistakes.

Read the original README https://github.com/google/gvisor#readme

ReadmeX opened this community for a trending project; it is not run by the project. Maintainers can claim it from the community page.