In GritivaCore, a Scope is defined as a Linux network namespace (netns) combined with a cgroup v2 isolation unit. It is managed by the gritiva-agent on each virtual machine (VM). This document will clarify what a Scope is, why it is used, its capabilities, lifecycle commands, and its relationship with the Gritiva mesh.
A Scope in GritivaCore is not a project, tenant, container, or VM. Instead, it is a lightweight unit that allows multiple independent network stacks to run on a single host. Each VM has one agent that manages multiple Scopes. Each Scope operates within its own netns and cgroup, providing strong isolation and resource management.
Scopes provide several advantages over traditional VMs and containers. VMs require their own kernel and are resource-intensive, while containers share the host network and offer weaker isolation. Scopes deliver container-like density with VM-like isolation, allowing a single host to efficiently run many independent network stacks.
To operate Scopes, the gritiva-agent must have the following capabilities granted via the systemd unit:
CAP_NET_ADMIN
CAP_SYS_ADMIN
These capabilities are set using the AmbientCapabilities= directive and are not setuid.
A Scope can join a Gritiva mesh (gmesh) using the command scope_mesh_connect. The WireGuard gmesh interface operates within the Scope's netns, allowing secure communication between Scopes.
It is important to clarify that Scopes are not synonymous with VMs or containers. They are distinct entities designed for specific use cases in network isolation and resource management.
GritivaCore Scopes provide a powerful mechanism for managing network namespaces and resource isolation in a lightweight manner. Understanding their structure and capabilities is essential for effective use in virtualized environments.
Open Questions
Open Questions
Are there additional use cases for Scopes that should be documented? What further examples can illustrate the benefits of using Scopes?