mirror of
https://github.com/aljazceru/kata-containers.git
synced 2026-02-02 13:14:33 +01:00
e477ed0e86
First of all, this is a controversial piece, and I know that. In this commit we're trying to make a less greedy approach regards the amount of vCPUs we allocate for the VMM, which will be advantageous mainly when using the `static_sandbox_resource_mgmt` feature, which is used by the confidential guests. The current approach we have basically does: * Gets the amount of vCPUs set in the config (an integer) * Gets the amount of vCPUs set as limit (an integer) * Sum those up * Starts / Updates the VMM to use that total amount of vCPUs The fact we're dealing with integers is logical, as we cannot request 500m vCPUs to the VMMs. However, it leads us to, in several cases, be wasting one vCPU. Let's take the example that we know the VMM requires 500m vCPUs to be running, and the workload sets 250m vCPUs as a resource limit. In that case, we'd do: * Gets the amount of vCPUs set in the config: 1 * Gets the amount of vCPUs set as limit: ceil(0.25) * 1 + ceil(0.25) = 1 + 1 = 2 vCPUs * Starts / Updates the VMM to use 2 vCPUs With the logic changed here, what we're doing is considering everything as float till just before we start / update the VMM. So, the flow describe above would be: * Gets the amount of vCPUs set in the config: 0.5 * Gets the amount of vCPUs set as limit: 0.25 * ceil(0.5 + 0.25) = 1 vCPUs * Starts / Updates the VMM to use 1 vCPUs In the way I've written this patch we introduce zero regressions, as the default values set are still the same, and those will only be changed for the TEE use cases (although I can see firecracker, or any other user of `static_sandbox_resource_mgmt=true` taking advantage of this). There's, though, an implicit assumption in this patch that we'd need to make explicit, and that's that the default_vcpus / default_memory is the amount of vcpus / memory required by the VMM, and absolutely nothing else. Also, the amount set there should be reflected in the podOverhead for the specific runtime class. One other possible approach, which I am not that much in favour of taking as I think it's **less clear**, is that we could actually get the podOverhead amount, subtract it from the default_vcpus (treating the result as a float), then sum up what the user set as limit (as a float), and finally ceil the result. It could work, but IMHO this is **less clear**, and **less explicit** on what we're actually doing, and how the default_vcpus / default_memory should be used. Fixes: #6909 Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com> Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Documentation
The Kata Containers documentation repository hosts overall system documentation, with information common to multiple components.
For details of the other Kata Containers repositories, see the repository summary.
Getting Started
- Installation guides: Install and run Kata Containers with Docker or Kubernetes
Tracing
See the tracing documentation.
More User Guides
- Upgrading: how to upgrade from Clear Containers and runV to Kata Containers and how to upgrade an existing Kata Containers system to the latest version.
- Limitations: differences and limitations compared with the default Docker runtime,
runc.
How-to guides
See the how-to documentation.
Kata Use-Cases
- GPU Passthrough with Kata
- SR-IOV with Kata
- Intel QAT with Kata
- SPDK vhost-user with Kata
- Intel SGX with Kata
Developer Guide
Documents that help to understand and contribute to Kata Containers.
Design and Implementations
- Kata Containers Architecture: Architectural overview of Kata Containers
- Kata Containers E2E Flow: The entire end-to-end flow of Kata Containers
- Kata Containers design: More Kata Containers design documents
- Kata Containers threat model: Kata Containers threat model
How to Contribute
- Developer Guide: Setup the Kata Containers developing environments
- How to contribute to Kata Containers
- Code of Conduct
Help Writing a Code PR
Help Writing Unit Tests
Help Improving the Documents
Code Licensing
- Licensing: About the licensing strategy of Kata Containers.
The Release Process
Presentations
Website Changes
If you have a suggestion for how we can improve the website, please raise an issue (or a PR) on the repository that holds the source for the website.