The list of possible topics for the current academic year are the following:
The availability of GPUs is becoming really critical for scientific research. Giovanni Mirarchi, a newly graduated student at POLITO, carried out an extensive study about the possibility to integrate Ray to support GPU-oriented jobs with an HPC-based approach. At the end of his thesis, he produced a working proof of concept, installed and operating on a dedicated K3s cluster. This project aims at porting the above solution onto CrownLabs, creating all the configuration files (e.g., YAML, manifests, configmaps, etc.) required for this system to be used by students in the CrownLabs production cluster. This system is intended to be used from within a python program, e.g., delivered through a Jupiter Notebook; hence, this work includes also the creation of an appropriate container, such as a Jupiter Notebook, to be made available to students who have to use GPU resources.
Optionally, this project should also investigate how Kueue, or alternative solutions, can be integrated in the workflow, which could help to set the proper queuing policies in case the number of jobs submitted exceeds the number of available GPUs. Alternatively, the project may experiment with the NVIDIA KAI Scheduler, evaluating its effectiveness and integration potential within the same workflow, as a possible complement or replacement for Kueue in managing GPU allocation and scheduling.
Technologies: Kubernetes, Docker, Helm, ArgoCD, Git.
Student: Salvo P. (s354138); tutor(s): Attilio Oliva, Marco Miracapillo
Kubernetes, and many associated tools, export a large number of information that are used for continuous monitoring and troubleshooting. However, information about physical servers cannot be retrieved within Kubernetes, although this data is available from within the BMC interface , available on all servers for offline management.
The project https://github.com/mrlhansen/idrac_exporter is a nice example of a Kubernetes software that can interface with the BMC interface of the servers, and retrieve information from there. For example, it can know the state of the hardware of each server, the energy consumed by the server itself, etc.
This project aims at deploying this project on the CrownLabs cluster, with the proper configuration (using ArgoCD), and push relevant information in Prometheus, assessing the capabilities of this software (e.g., to support multiple BMC interfaces, such as iLO, iDrac, and others) and its readiness to be used in production (e.g., in terms of quality of the exported data).
Finally, this project will create one or more Grafana Dashboards to show the information gathered from the above software and make them easily readable from external users.
Technologies: Kubernetes, Docker, Helm, ArgoCD, IPMI, Grafana.
Student: Lorenzo D. (s349496); tutor(s): Stefano Galantino, Marco Miracapillo, Attilio Oliva
Giovanni Mirarchi, a newly graduated student at POLITO, created a software to book physical resources, such as bare metal servers. In short, this tool includes both an online reservation component and the server provisioning mechanism itself: when a user requests to use a specific server, all the data are wiped out and a clean version of the operating system is installed. The problem we would ask you to solve is to extend this system in the following way:
extend the graphical interface to allow the user to choose among a set of operating systems to be installed;
extend the graphical interface to allow the user to choose an .ISO file to use to install its own preferred operating system (which overcomes the case in which the desired operating system is not provided by default within the PROGNOSE platform);
extend the graphical interface to allow users to upload an arbitrary number of security keys (for SSH access);
extend the Kubernetes-based backend to perform the indicated actions.
Technologies: Kubernetes, Docker, Helm, ArgoCD, IPMI.
Student: Michele S. (s304046); tutor: Attilio Oliva, Stefano Galantino
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: XXX; tutor: YYY
The Kubernetes Gateway API is a set of resources designed to improve and standardize traffic routing within Kubernetes clusters, serving as a successor to the Ingress API. It provides a more flexible and expressive way to manage ingress, load balancing, and service mesh functionalities.
In addition, a recent announcement (https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/) made the migration to the GatewayAPI even more compelling. The nginx Ingress controller, by far the mostly used in Kubernetes, has been recently retired because of lack of support. This creates yet another problem for Kubernetes platform engineers, who need to plan a replacement for nginx, while at the same time evaluating the migration to the newer Gateway API.
This project aims at analyzing and experimenting about what Gateways APIs are, which advantages they bring compared to alternative technologies, and which are the differences compared to the well-established (and widely used) Ingress API. Furthermore, the project is expected to provide a proof-of-concept implementation of some existing services (e.g., on CrownLabs) delivered through the Gateway API, if feasible.
Technologies: Kubernetes, Ingress API, Gateway API
Student: XXX; tutor: YYY
Main open-source projects to handle storage in Kubernetes are Minio 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 moltitude 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: XXX; tutor: YYY