[Sandbox] KubeSlice

[pnavali]

Application contact emails

prabhu@avesha.io, eric@avesha.io, bharath@avesha.io

Project Summary

KubeSlice is a multi-cluster networking application for pod-to-pod communication across clusters.

Project Description

KubeSlice is an open-source project that simplifies multi-cluster networking for, multi-cloud, edge, cloud, hybrid-cloud and bare-metal Kubernetes clusters. It is a vendor-neutral extensible framework to build flat overlay networks across heterogeneous Kubernetes clusters. It enables and simplifies pod-to-pod communications for L3-L7 protocols across a fleet of clusters by using a construct called ‘Slice’. Each Slice can be associated with a set of clusters with varying topologies and can be associated with one or more namespaces in each cluster. The pods in the Slice namespaces can reach each other over the Slice specific flat overlay network. KubeSlice allows creating multiple Slices across clusters with each slice having a dedicated set of namespaces in each associated cluster. It enables easy segmentation and isolation of applications using slices. It allows namespace -sameness across the associated clusters in a slice. KubeSlice brings with it software-defined, highly-available and secure connections across clusters using VPN gateways. KubeSlice enables service discovery across the Slice using Service Exports and Imports in each cluster. A Slice associated namespace service running on a cluster can be exported and made available to all the other clusters namespaces associated with the Slice. SliceDNS in each cluster can be used for FQDN based inter-cluster service-service communications across the Slice. Slice DNS has service entries with overlay network IP addresses for service endpoints.

Slice flat overlay network is CNI agnostic, and it does not require non-conflicting pod subnets on the associated clusters.

KubeSlice integrates with service meshes like Istio to deploy slice Ingress/Egress gateways for east-west traffic across multi-cluster Istio deployments, by automating the creation of gateways and virtual services for cross cluster distribution of workloads.

This architectural prowess is vital for distributed applications across clusters, fostering data consistency, availability, and performance.

KubeSlice offers a unified service connectivity layer that enables easy segmentation and
isolation of applications across multiple Kubernetes clusters. KubeSlice multi-cluster Kubernetes networking removes complexities of building and managing a service connectivity layer across multiple clusters. It further enables distributed application fabric through seamless data access and management. Users can craft data placement policies based on latency and data sovereignty and replicate data in optimal regions or clusters.

Org repo URL (provide if all repos under the org are in scope of the application)

https://github.com/kubeslice

Project repo URL in scope of application

https://github.com/kubeslice/kubeslice

Additional repos in scope of the application

https://github.com/orgs/kubeslice/repositories has all the related repos.

Website URL

https://kubeslice.io/

Roadmap

KubeSlice Roadmap

Roadmap context

In our office hours and CNCF community channels, we openly discuss the Roadmap, gathering input and prioritizing items through collaborative discussions. Our approach is strongly oriented towards fostering a thriving ecosystem, and we actively seek opportunities for interoperability with CNCF projects and other open-source initiatives. This commitment helps us better address the interests and needs of our community.

Contributing Guide

://github.com/kubeslice/worker-httpsoperator/blob/master/CONTRIBUTING.md

Code of Conduct (CoC)

https://github.com/kubeslice/worker-operator/blob/master/code_of_conduct.md

Adopters

No response

Contributing or Sponsoring Org

https://avesha.io/

Maintainers file

https://github.com/kubeslice/worker-operator/blob/master/MAINTAINERS.md

IP Policy

• If the project is accepted, I agree the project will follow the CNCF IP Policy

Trademark and accounts

• If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

Why CNCF?

By joining CNCF, we want to motivate more innovation and participation from the open-source community. Some significant values joining CNCF could bring to the project are:

Be vendor-neutral: KubeSlice can get a neutral home in CNCF, to facilitate further project development through a more diverse and neutral community.

Be more aware: leverage CNCF to promote the project and get more users and contributors through official events, mailing lists, blog posts, etc.

We also believe that KubeSlice could be an excellent addition to the existing CNCF landscape. KubeSlice is based on Kubernetes, and it is a significant attempt to tackle the challenges with applications specific multi-cluster networking across a fleet of clusters.

Benefit to the Landscape

As organizations move towards adopting or extending the use of Kubernetes clusters for their applications, they would inevitably have to deal with the complexities of building and managing a unified service connectivity layer for easy segmentation and isolation of applications across multiple clusters.

KubeSlice addresses these challenges by providing an extensible framework for creating and managing Slices where each Slice has its own flat overlay network and namespace associations for easy segmentation and isolation of applications across multiple clusters.
Each pod in a Slice overlay network spanning across multiple clusters is uniquely addressable at L3. Hence, a pod talking to another pod in a remote cluster is oblivious of its location and would communicate with it as though it were running on the same cluster. Since the connectivity between pods is at L3, there is no need to provision L7 ingress/egress application gateways between clusters to enable pod-to-service or service-to-service communication. It also facilitates Service Discovery across the set of clusters by automatically exporting and importing service endpoints.
KubeSlice not only enables applications that are based on L7 protocols, it also enables applications that are purely based on L4 protocols (TCP or UDP) to utilize multi-cluster topologies. KubeSlice does not have any restrictions on the CNI being used on the clusters. It is interoperable with any CNI, and it does not require the pod CIDR on the connecting clusters to be non-conflicting.

We believe KubeSlice would be a valuable addition to the CNCF landscape as the community navigates through the challenges of connecting applications across multiple clusters.

Cloud Native 'Fit'

KubeSlice is built as an extension to Kubernetes with Operators/Controllers and API extensions to build and manage Slices for applications connectivity across clusters. The Slice overlay network is built with cloud native network functions (CNFs). The state-based-management of Slices dramatically simplifies the multi-cluster connectivity orchestration and management, and improves the compatibility, scalability and configuration management of multi-cluster networking across heterogeneous Kubernetes clusters in edge, bare-metal or private/public cloud locations.

Cloud Native 'Integration'

KubeSlice uses CNCF sandbox project Network Service Mesh (NSM) for some of the Slice overlay network functions.

Cloud Native Overlap

N/A

Similar projects

N/A

Landscape

No

Business Product or Service to Project separation

Avesha’s KubeSlice enterprise product uses KubeSlice open-source as core, but the open source project roadmap and direction is driven by the needs of the community. This will continue to be true in the future. Avesha provides implementation & product enhancement services for enterprises which deviate from core open-source solutions.

Project presentations

No response

Project champions

No response

Additional information

No response

[TheFoxAtWork]

Please present to TAG - Network to provide additional awareness and understanding of what the project is and its scope with recommendation for align.

[mauilion]

Please present this project to tag network.

[pnavali]

Sure - will work with tag-network chairs to find a slot to present.

[pnavali]

Presented KubeSlice to TAG Network on 1/11. Thanks Nic Jackson @nicholasjackson, Lee Calcote @leecalcote and Lin Sun @istio for the opportunity to present it to the Network team and a good discussion. Presented slides are here.
KubeSlice is built with cloud-native network functions and other CNCF sandbox projects (like NSM/Spire). It enables multi-cluster application networking and service connectivity with its Application Slices - with a slice specific flat overlay network across clusters, namespace associations and service connectivity across slice. We believe it aligns well with the TAG Network charter and look forward to the next steps.

[amye]

@leecalcote @linsun - does TAG network have a recommendation?

[linsun]

@amye ack - I'm consulting @nicholasjackson for his recommendation as he helped us run the last meeting on 1/11. Will circle back.

@pnavali please give me access to your slides - just sent a req in google docs. Thanks!

[pnavali]

@linsun - I have fixed the share settings on the doc - should be accessible to anyone with the link. Thanks.
https://docs.google.com/presentation/d/1zU0_zCgRKG9IUSC2ad6MrUzd3treVaIO8zm2yFMMzBA/edit?usp=sharing

[linsun]

Hi @amye I have consulted @nicholasjackson and also gotten an update and demo from the KubeSlice team today in TAG-network meeting. We don't see any blocker for KubeSlide to be accepted as a CNCF incubation project. Both Nic and I found the project very interesting given our background of service mesh and networking, and have potential to integrate with various mesh products.

Nic wrote a great explanation: KubeSlice is a tool for Kubernetes with optional Service Mesh integration that allows you to distribute and connect services in your application securely across multiple Kubernetes clusters. For example, there are two teams in your organization. Team Frontend and Team Backend, each team manages a number of services and each team operates their own Kubernetes cluster. Team Backend would like to expose an API service securely to Team Frontend without exposing any other elements of the cluster. KubeSlice enables this by creating a slice, which is a logical partition of an application; this slice can then be exposed to an external cluster securely via the Slice VPN Gateways that run on each cluster. Since KubeSlice creates a custom DNS entry for the slice, all Team Frontend needs to do to call the service is to address it via the service DNS. KubeSlice handles the traffic routing to the Slice Gateway and then to the second cluster. Not only does this work between two clusters on the same VPC or network, but you can also use it on networks, vpcs, and even clouds.

One concern I have shared with the project is the lack of GitHub activities, there were a few months inactivity and no release towards 4Q 2023. The project maintainer mentioned they were working on a big feature thus skipped 1 release.