The list of projects for the current academic year are the following:
CrownLabs was defined to allow students to perform computing labs online, and the most important resources were the tenants, which corresponds to a student, workspaces, i.e., courses, and instances, which represent running VMs/containers. While workspaces and instances were refined later within the CrownLabs life, the tenant is still mostly relying on the original code, written in 2020. Hence, the code developed at that time was rather primitive, with people lacking of the proper knowledge about modern coding standards. In addition, a non-negligible amount of resources in CrownLabs is now used by students performing personal projects, thesis, etc., which does no longer match the original design choices underlying the definition of the tenant, hence making cumbersome, for students, to obtain access to images/applications uploaded for other courses.
The current project aims at a complete refactoring of the tenant operator, and the required changes to other companion resources (e.g., instances, workspaces), with the following requirements in mind:
Refactoring of the tenant code, bringing it to higher quality standard, and an improved coverage for automatic testing.
Alignment of the current architecture, based on multiple controllers, to modern Kubernetes best practices. This implies transforming the current architecture with multiple controllers into a new one with multiple operators (e.g., instance operators and tenant operators), all working within the same controller.
(In collaboration with project #8) Extend the tenant and the instance resources to simplify, for a tenant, the possibility to import other VMs/containers that available in other courses in the personal workspace of the tenant.
Introduce the concept of "course administrator" user, which can create and configure workspaces without being the general administrator of the CrownLabs cluster.
Technologies: Kubernetes, Go, Git
Students: XXX; Tutor: YYY
CrownLabs was designed to provide VM/containers to students, where the above objects are intended to contain the applications required to carry out the planned lab. However, there are some labs in which multiple VM/containers are required (e.g., create a Kubernetes cluster with 3 nodes), which require to start all the VM individually.
This project aims at extending the VM/container template (or creating a new data structure) in order to group together multiple VMs/containers, which can be started at once, and extending the current GUI to leverage the new feature, hence providing a new template/supertemplate to group admins to play with.
Technologies: Kubernetes, Go, Javascript, React, Git
Students: XXX; Tutor: YYY
CrownLabs is able to run applications using VMs or containers. This project aims at extending CrownLabs in order to allow the platform to create and manage other Kubernetes clusters, by means of technologies such as ClusterAPI and Kubevirt. This allows student to instantiate their own native Kubernetes cluster, where they have fully administrative access, which is set up by creating multiple VMs (with Kubevirt) and automatically installing the required software (e.g., K8s control plane on one node, workers on the others, the add the required components such as CNIs, etc).
This project would provide a more secure and isolate solution compared to the current "CrownLabs sandbox" that is used for this purposes.
The setup of a minimal GUI to visualize the current state of the clusters (https://github.com/Jont828/cluster-api-visualizer ) would be a nice addition to this project.
Optional feature: it would be helpful if the children Kubernetes clusters are integrated with the controller manager of the main cluster (i.e., CrownLabs) in order to provide external access to the cluster itself.
Technologies: Kubernetes, Go, Git (Javascript, React)
Students: XXX; Tutor: YYY
The novnc software (https://novnc.com) is a an open-source VNC browser client, i.e., a component that enables the interaction to a VNC server running in a VM through a web browser. This is the standard way of interacting for CrownLabs, but the current architecture requires the no-vnc component to be installed in the VM itself. However, this complicates the building process of new VMs (or the update of existing VMs), as this mandatory software has to be installed/updated within each VM image.
This project aims at creating a dedicated component, namely a sidecar, which hosts only the novnc software, which is automatically attached to the running VMs. This sidecar will provide the conversion between the websocket, used to transfer data to the client web browser, and the VNC server that has to be running in the VM. This simplifies the operations of building/updating VM images, and also simplifies any possible updates to the novnc software.
Note: this project may be included in project #5, which may require this feature to complete.
Technologies: Kubernetes, Go, Git
Students: XXX; Tutor: YYY
The Kubevirt project provides an interface to run VMs into the cloud-native Kubernetes platform. In this respect, Kubevirt provides already a VNC server for the VM, hence a client can connect to it using the VNC protocol and without having to install a dedicated VNC server to the VM. However, Kubevirt currently exports a UNIX socket where the VNC client has to attach to, which is not appropriate when the VNC client is running remotely. Past discussion on the Kubevirt project (https://github.com/kubevirt/kubevirt/issues/9553) concluded that the possibility to get access to the Kubevirt VNC server would be helpful, but nobody implemented this feature.
This project aims at tackling this issue, investigating which one of the two possible approaches are the most appropriate:
extend Kubevirt to export the VNC port as a TCP socket
extend novnc to connect to a UNIX socket instead of a TCP server
Once defined the approach, this project aims at extending the selected project (either novnc or kubevirt) to implement the specific feature. Please note that this project requires to interact with non-POLITO development communities, which should be done carefully in order to get the new developed code accepted and merged within the main project.
Note: this project may be merged with project #4, given that a sidecar may be needed to provide the novnc conversion towards VMs.
Technologies: Kubernetes, Go, Git
Students: XXX; Tutor: YYY
RDP is known for its superior performance compared to VNC. However, most of the software projects, including CrownLabs, still use VNC to provide GUI-based access to remote VMs. This project aims at exploring the potential advantage in adopting RDP (e.g., Guacamole) instead of VNC in CrownLabs, and the changes that may be required to achieve such this goal.
Note: while this project requires to build real code working on CrownLabs, we do not expect to merge it within CrownLabs. The objective of the project is to create a proof-of-concept that will help the CrownLabs maintainers to decide whether it could be appropriate to replace VNC with RDP in the future.
Technologies: Kubernetes, Go, Git
Students: XXX; Tutor: YYY
Currently, Crownlabs provides two ways to connect and interact with VMs:
For GUI-based VMs, the interaction happens via browser, through the VNC protocol.
For console-based VMs, the interaction happens via SSH, either from the user's computer (e.g., personal laptop), or by using a GUI-based VM as a frontend, where the first method is the suggested one.
However, many (unexperienced) users have problems in to use SSH, mainly for the difficulties to generate the proper set of SSH keys and use them for the authentication.
This project aims at integrating a third way of interaction with consoled-based VMs, which consists in a web-based SSH client running in the browser, coupled with a back-end system that generates the proper SSH keys for the user, and uploads them automatically (a) in the user VMs, and (b) in the SSH client. This would simplify the life to non-experienced users (thanks to the automatic generation and handling of SSH keys), and provide a seamless access, via browser, to console-based VMs, without requiring any client-based tools in addition to a web browser.
Technologies: Kubernetes, Go, Git, Javascript, React
Students: XXX; Tutor: YYY
CrownLabs was designed to provide VM/containers to carry out computing labs within University courses. As a consequence, the data model is structured with students (tenants) that are enrolled in courses (workspaces). However, an increasing number of students leverages CrownLabs to carry out personal tasks, projects, thesis, hence requiring resources that are no longer associated to courses.
This project aims at introducing the concept of Personal Workspace in Crownlabs, in which each student is also associated to a personal environment where he can create new templates (VMs, containers), for his own personal use.
Technologies: Kubernetes, Go, Git, Javascript, React
Students: XXX; Tutor: YYY
CrownLabs was designed to provide VM/containers to carry out computing labs within University courses. However, an increasing number of students leverages CrownLabs to carry out personal tasks, projects, thesis, hence requiring resources (e.g., number of VMs running; vCPU, RAM) that are no longer the ones associated to the courses.
This project aims at facilitating the customization of the above limits by creating a small GUI, within the CrownLabs user interface, that allows cluster administrators to customize the above limits without having to deal with Kubernetes CLI commands.
Note: this project is strongly related to the #8 ("Introduce the Personal Workspace in CrownLabs") and it is mainly a front-end (Javascript-based) project. Therefore it may be merged with the project #8.
Technologies: Kubernetes, Go, Git, Javascript, React
Students: XXX; Tutor: YYY
CrownLabs was designed to provide VM/containers to carry out computing labs within University courses. However, a new request from potential users speculates that CrownLabs could become an excellent backend for remote experimentations, e.g., VMs hosting "server" services reachable from the Internet.
This project aims at tackling this challenge and enable the creation of a "load balancer" address (similar to FloatingIPs in OpenStack) that is associated with a given VM/container, which enables the reachability of the backend service from the Internet. This feature will include also:
a graphical front-end that allow users to enable this feature on a given VM/container, autonomously, without the intervention of the CrownLabs administrators;
a graphical front-end that enables administrators to edit the profile of each user, setting if this feature is enabled or not, and how many IP can be allocated per each user;
the capability (for both users and administrators) to select whether a LoadBalancer IP is required, or if a similar objective can be achieved by customizing the Ingress resource of the main cluster.
Finally, given the scarcity of public IP addresses, it would be useful to create a mapping between selected TCP/UDP ports from the "public" network side and the corresponding ports on the "internal" side, hence saving IP addresses. E.g., a VM can ask for the above mapping:
PublicIP:2222 --> VMIP:22 - Description: ssh
PublicIP:8080 --> VMIP:80 - Description: internal web server
Technologies: Kubernetes, Go, Git, Javascript, React
Students: XXX; Tutor: YYY
CrownLabs is used by many students for their course labs, and they tend to keep their services (e.g., VMs, containers) active even if they are no longer used.
This project aims at identifying which resources are no longer active from a given amount of time (e.g., 1 week) and send a warning message to the owner, asking him to log-in again to keep it active. If this action is not done after a given number of warning is issued (e.g., N warnings over N days), the service is removed from the cluster.
Optionally, a more sophisticated action policy can be implemented, e.g., depending on the nature of the workload:
stateless pod: it may be removed from the cluster (e.g., deleted);
stateful pod (VM): it could be "paused" and saved on disk, ready to be restored in the future;
pods whose workload is below a given threshold (e.g., web server with very low traffic): the resource limits in Kubernetes can be adjusted in order to be more aligned with the actual resource consumption (e.g., 1vCPU limit changed to 0.1vCPU)
Finally, as a further optional optimization, Kubernetes worker nodes can be drained and their pods can be moved to other workers, hence consolidating the workload on an inferior number of servers.
This project can leverage/get inspiration from the KubeGreen (https://kube-green.dev/) software, which aims at reducing the energy footprint of the cluster.
Technologies: Kubernetes, Go, Git
Students: XXX; Tutor: YYY
Integrate Liqo namespaces management logic in CrownLabs. Liqo is a project that allows to acquire resources in another cluster and give them visibility such as being local. This starts with a peering process with the "donor" cluster, and continues by selecting the namespace which needs to be offloaded on the remote cluster, in this case the namespace of the user. This project aims at creating a controller that can (1) automatically offload the namespace when a target node is selected for the pod deployment (and remove the offloading strategy when the pod is removed), and (2) can set the proper offloading policies if, in general, the user has the right to use remote resources (i.e., it requires an extension of the "tenant" attributes").
Integrate the management of "snapshot" images within CrownLabs.
Optimizing inactive cloud workloads, considering that there are several instances of persistent images that are powered off, but that consume space on disk. If a persistent image is not powered on from more than X months, the image should be deleted.
Introduce automatic vertical pod autoscaler in CrownLabs
Cluster-in-Cluster using Cluster API
Resource quotas refined: currently there's a resource quota in each workspace, but the actual resource quota for a user depends on the sum of the resource quota of each workspace it belongs to. For instance, if it it belongs to a first workspace whose CPU limit is 10, and a second workspace whose CPU limit is 8, the total CPU limit for the user is 18, no matter which workspace it is currently using. This project aims at changing how quotas are enforced, avoiding that, in each workspace, the limit is exceeded. NOTE: this requires also to change the grafana dashboard, as quotas have to be reported per workspace, not as an absolute number.
Introduce the capability to run lambda functions (perhaps it's a big project, could be split in several sub-projects)