Fetching the latest programs, projects, and workspace data.
<p>Add partial mesh support to KubeSlice using a small-scope MVP topology: **Hub-and-Spoke**. Users can define one (or two) hub clusters for a slice; the controller computes desired connections so only hub↔spoke links are established (no spoke↔spoke), and workers reconcile connectivity accordingly. Includes status reporting for convergence and failure reasons.</p><p><br></p><p>Expected Outcome: Users can create a slice with hub-and-spoke partial mesh topology and see it converge across multiple worker clusters. Topology updates (e.g., changing the hub) rewire connections safely. Slice/worker status surfaces readiness and errors for debugging.</p><p><br></p>
Showing 5 of 6 projects. Click any project card for scope, mentors, and proposal studio.
In the current KubeSlice design, IP address management (IPAM) for slice overlay networks is static and inefficient. A predefined CIDR block (e.g., 10.1.0.0/16) is divided into a fixed number of subnets regardless of how many clusters participate in the slice, leading to significant IP space wastage. This project aims to implement a dynamic IPAM system that allocates IP subnets to clusters on demand and reclaims unused ranges when clusters leave the slice. It will ensure efficient address utilization, synchronization across clusters, and integration with the KubeSlice control plane. Expected Outcome: 1. A dynamic IPAM allocator integrated with the KubeSlice controller or sidecar component. 2. Support for on-demand IP allocation and subnet reclamation when clusters join or leave a slice. 3. Conflict resolution and state synchronization across clusters using CRDs or distributed storage. 4. Documentation on how the system works, configuration options, and edge case behaviour.
KubeSlice currently uses a full-mesh topology for the slice overlay network, where every cluster connects to every other cluster in the slice. This results in unnecessary tunnel creation and resource consumption. This project proposes a topology-aware design, allowing users to define custom connectivity matrices for slices. Users can specify partial meshes. Additionally, the project will support configuring each cluster's VPN deployment type (client/server) to accommodate network constraints such as firewalls or NAT. Expected Outcome: 1. Extension of the Slice CRD to support custom topology and VPN role definitions. 2. Logic to establish tunnels based only on the defined connectivity matrix. 3. Support for various deployment topologies (full-mesh, partial mesh, hub-spoke). 4. Sample configurations and documentation on how to define and validate topologies.
The kubeslice-cli repository currently lacks comprehensive unit and integration tests making it hard to test the changes. This project aims to implement a robust testing framework to ensure the reliability and stability of the CLI tool. The Mentee will write unit tests for existing functions & integration tests for the CLI commands & also set up a continuous integration pipeline to run these tests automatically on every commit and pull request. Expected Outcome: 1. A fully configured testing framework for kubeslice-cli with unit and integration tests covering all critical functionalities. 2. A CI/CD pipeline configuration (e.g., GitHub Actions) that automatically runs the tests on every pull request. 3. Documentation on how to run these tests & add new ones.
<p>Add Active/Standby HA support for the KubeSlice Controller.</p><p> - Leader election: Only one controller cluster (the “Active” node) holds a distributed lock (e.g., a Lease) and is permitted to write updates to worker clusters or manage Slice configurations.</p><p> - Constant state sync: The Standby cluster continuously mirrors the Active cluster’s state, including relevant KubeSlice CRDs (Slices, ServiceExports, Clusters, etc.).</p><p> - Heartbeating: The Standby cluster monitors the health of the Active cluster.</p><p> - Failover: If the Active cluster fails to renew its lease, the Standby cluster detects the timeout, acquires the lock, promotes itself to Active, and worker clusters are updated to use the new Active controller.</p><p><br></p><p>Expected Outcome: Implement an Active/Standby HA architecture that makes the KubeSlice management plane resilient and disaster-recovery-ready.</p><p><br></p>
The KubeSlice project consists of multiple repositories that work together to provide application connectivity and network services across Kubernetes clusters. Currently, our E2E tests are outdated and need significant improvement. This project aims to automate the E2E testing process by improving the current test suite and implementing new tests where necessary. This will ensure that the entire KubeSlice ecosystem works seamlessly together. Expected Outcome: 1. A comprehensive set of E2E tests covering all critical functionalities of KubeSlice. 2. Integration of the E2E tests into the CI/CD pipeline to run automatically. 3. Clear Documentation for running & extending the E2E tests.