The list of possible topics for the current academic year are the following:
Students use LLMs every day, almost always through external commercial services. For any organization, included universities, this raises several problems:
Data leave the organization. Prompts, documents, and code are processed on someone else's servers.
The service can disappear at any time, for reasons outside the organization's control. For example, in June 2026 access to Anthropic's Claude Fable 5 and Mythos 5 models was suspended for almost three weeks to comply with U.S. export controls (link).
Costs and available models are decided by the provider. Prices, usage limits, and model versions can change without notice.
Running the service in-house solves these problems but creates new ones. Serving LLMs is very different from the VMs and containers. For instance on CrownLabs each request keeps a GPU busy for seconds, demand spikes during lectures, and a model takes minutes to start on a new GPU. This project aims at building a self-hosted chat service similar to ChatGPT for CrownLabs users, by assembling existing open-source projects instead of writing new code:
a web interface, e.g., Open WebUI or LibreChat;
a gateway handling users, API keys, and quotas, e.g., LiteLLM;
an inference engine, e.g., vLLM, running on our GPUs.
Users log in with their CrownLabs account (Keycloak). The two main challenges are:
accounting: how many tokens can a student use per day, and how are quotas assigned per course?
scaling: what happens when 100 students send a prompt at the same time and no GPU is free?
The result will be validated with a load test that simulates a full class. Optionally, the project can experiment with inference-aware routing through the Gateway API Inference Extension.
Technologies: Kubernetes, vLLM, Open WebUI/LibreChat, LiteLLM, Keycloak, Prometheus, Grafana, ArgoCD.
Students: Falcone/Bartolini (tentative); tutor: Attilio Oliva
GPU workloads come with huge container images: CUDA, PyTorch, and their dependencies easily exceed 1 GB. When a student starts such an environment on a node that has never seen the image, the whole image must be downloaded before the container starts, which can take minutes. When an entire class launches the same image at the beginning of a lab, all nodes hit the registry at once. Yet a container reads only a small part of its image at startup.
Lazy loading addresses exactly this: the container starts immediately, and files are fetched only when they are actually read. Nydus, part of the CNCF Dragonfly project, implements this as a containerd plugin, and the Harbor registry can convert images to the Nydus format automatically with its Acceleration Service.
This project aims at installing Nydus on some CrownLabs nodes and measuring how much it speeds up the start of large GPU environments, compared with the current setup and with simpler alternatives such as image pre-pulling. The evaluation should measure the time until the environment is really usable (the notebook is ready and the GPU is accessible), not just the container start. It should also check what happens when something breaks, for example when the Nydus daemon crashes.
Technologies: Kubernetes, containerd, Nydus, Harbor, Prometheus.
Student: Alessio s351638 (tentative); tutor: Attilio Oliva
Kro (Kube Resource Orchestrator) is an open-source, Kubernetes-native framework designed to simplify the deployment and management of complex Kubernetes resources. It achieves this by allowing users to define custom Kubernetes APIs that encapsulate multiple resources and their dependencies as a single, reusable unit. It has been recently proposed as a joint effort between Amazon/Google/Microsoft to the Kubernetes community.
This project aims at analyzing and experimenting what Kro is, which advantages it brings compared to alternative technologies, and which are the differences compared to the well-established (and widely used) Helm project.
Some initial pointers:
Wilson Spearman, "Is the Helm Killer Finally Here?", Jan 31st, 2025. https://www.tryparity.com/blog/is-the-helm-killer-finally-here-enter-kro
The Kube Research Orchestrator official GitHub repository. https://github.com/kubernetes-sigs/kro
Technologies: Kubernetes, GitOps, ArgoCD, Helm, Kro
Student: Luca (s366773) (tentative); tutor: Marco Miracapillo, Fulvio Risso
The CrownLabs computing facility @ Polito offers immutable VMs to students. This means that any data written on the VM disk could be permanently lost when the VM is deleted and re-created.
To handle data storage and sharing (across different VMs of the same student, but also with othe students) Crownlabs offers two different primitives:
the "my drive" facility, which implements a permanent drive where student can store its data, which are mounted on the VM main disk;
the "shared drive" facility, under the control of workspace administrators (e.g., professors), where data can be shared across all the members of the workspace, also mounted on the VM main disk.
Currently, the above primitives are implemented leveraging "logical volumes" provided by Kubernetes. However, this primitive does not offer easy portability of the volumes themselves (e.g., accessing a given volume from another Kubernetes namespace can be cumbersome), nor is compatible with Liqo (getting access to the above volume when the computing is moved onto a remote cluster).
This project aims at exploring the possibility to attach a "my drive" instance to a VM that is provided through an S3 service, such as DittoFS. In a nutshell, the user attaches mydrive to its VM, while mydrive is handled through a software based on an S3 backend.
The work is expected to provide :
a list of software that can be used to provide such a service (both for filesystem-to-s3 part, and S3 storage providers);
a PoC of the system working, using the software that is selected after a proper presentation and discussion with your tutor;
a preliminary benchmarking of the performance achievable by this solution, compared with the current implementation of mydrive.
This work is not expected to produce software; however, if the project is successful, it could be a nice start for a project for the Cloud Computing Programming course in order to integrate such a solution within CrownLabs.
Technologies: Kubernetes, S3
Student: Matteo (s364179) + Alberto (s360540) (tentative); tutor: Marco Miracapillo, Fulvio Risso, Federico Cucinella
Main open-source projects to handle storage in Kubernetes are Minio, LongHorn, and Rook/Ceph. MinIO offers simpler, high-performance S3 object storage, ideal for cloud-native apps needing speed and ease, while Rook/Ceph provides a powerful, complex, unified storage platform (object, block, file) for enterprise-grade scale, diverse workloads, and greater control.
The project aims at comparing the features and the capabilities provided by the two approaches, including their cloud-native support (for Minio we should consider both the open-source operator, and the proprietary AIStor one), providing suggestions and examples how to scale a cluster over a multitude of nodes. Finally, the project should also analyze the capability to access to storage in case of multi-cluster topologies created with the Liqo.io open-source software.
Technologies: Kubernetes, Minio, Rook/Ceph, Liqo
Student: Ali (s375419) (tentative); tutor: Marco Miracapillo
CrownLabs users make heavily usage of virtual machines. However, in case of server maintenance, all VMs on the server are powered off, and all the content inside the VM itself (e.g., in the main memory) is lost.
This project aims at evaluating the capabilities of Kubevirt to migrate the VMs on another server, first on a standalone Kubernetes cluster, then on CrownLabs. The expected outcome are the following: (1) a set of guidelines and commands in order to guide a possible developer to extend CrownLabs with this capability, which could greatly facilitate the maintenance operations on the cluster; (2) a technical deep dive about the different migration possibilities (e.g., cold vs hot vs live migration) and their performance.
Technologies: Kubernetes, Kubevirt
Student: XXX; tutor: Marco Miracapillo