Key Features

KubeSlice makes Kubernetes simple at scale for multi cluster/multi-tenant/ multi-region/multi-cloud application deployments. It is a platform that combines network, application, Kubernetes, and deployment services to bring uniformity across clusters for multi-cluster applications, thus dramatically increasing development velocity for platform and product teams.

KubeSlice bundles the following services into its architecture:

Services	Feature	Description
Application	Namespace sameness	Allows the freedom to deploy applications across clusters with namespace parity.
	Service exports and Service imports	Automatic service imports and exports allow service discovery across cluster boundaries.
	Isolation	Allows isolation by association of application namespaces with a slice.-
Network	East-West cluster communication	Enabled by automatically creating tunnels between clusters, on a per slice basis, establishing an overlay network enabling service-to-service communication as a flat Layer 3 network. KubeSlice can also be configured to utilize East-West ingress and egress gateways.
	Remove IP Addressing Complexity-	KubeSlice solves the complex problem of overlapping IP addressing between clusters across cloud providers, data centers, and edge locations. The overlay network is configured with a non-overlapping RFC1918 address space removing overlapping CNI CIDR concerns.
	QoS Profiling	Slices in a cluster have a QoS profile defined per slice, allowing granular traffic control between clusters.
Security	Cross cluster Layer 3 secure connectivity	KubeSlice gateway nodes establish encrypted VPN tunnels between all registered clusters.
	Network Policy Management	KubeSlice provides Network Policies that are normalized across all clusters. The clusters registered in the slice configuration can be tied to a slice forming network segmentation at Layer 3 that allow/deny traffic to applications external from the slice application and allowed namespaces.
	Multi-Tenancy	KubeSlice manages namespaces that are associated with a slice, creating application isolation and reducing the blast radius.

Multi-Cluster Support

Application Connectivity

Enables application connectivity across clusters/clouds with zero touch provisioning.

Virtual Overlay

Constructs virtual clusters across physical clusters by establishing an overlay network.

Traffic Prioritization

Guarantees the ability to dependably run high-priority applications and traffic with QoS configuration for inter-cluster network connections.

Slice Overlay Network Deployment Mode

KubeSlice supports the following overlay network types for inter-cluster connectivity:

• No-network overlay
• Single-network (default option) overlay
• Multi-network overlay

No-network Overlay

This option is also referred to as No Connectivity. It provides no overlay network that is no inter-cluster connectivity among all clusters of a slice. The main benefit of this mode is that you can manage all your clusters on a slice and estimate their costs and isolate clusters from communicating with each other cluster on the no-network slice. This no-network slice supports the operations such as RBAC, resource quota management, and node affinity.

The participating clusters of a no-network overlay slice contains networking enabled to true by default. Thus this property facilitates switching a slice from no-network overlay to single or multiple network overlay slice only when all the clusters on that slice have networking enabled. However, switching back from single/multi-network overlay to no-network overlay is unsupported.

Single-Network Overlay

This option is also referred to as Overlay Connectivity. It provides a single, flat, overlay network across all the clusters of a slice. The pod-to-pod connectivity is provided at L3, with each pod receiving a unique IP address. The service discovery relies on the slice DNS to resolve service names exposed on a slice.

Multi-Network Overlay

This option is also referred to as Service Mapped Connectivity. It sets up the inter-cluster connectivity for applications by creating and managing a network of ingress and egress gateways based on the Gateway API. The pod-to-pod connectivity is provided at L7 for HTTP and HTTPS protocols. Unlike the single-network option, there is no flat inter-cluster network at L3. The service discovery for application services exposed on a slice is provided through local cluster IP services.

Differences Between Single-Network and Multi-Network Slice Overlay

The figure below illustrates the difference between the single-network and multi-network overlay.

Single-Network Slice	Multi-Network Slice
There is single flat overlay network and pod-to-pod connectivity is at L3.	The pod to pod connectivity across clusters is set up through a network of L7 ingress and egress gateways. There is no L3 reachability.
The application pod receives a new interface and an IP address.	The application pod is left untouched. There is no new interface injection or new IP address for the pod.
The application service discovery is through KubeSlice-DNS and service import/export mechanism. There is no cluster IP address.	The application service discovery is through the local cluster IP service and Kubernetes-DNS.
HTTP, HTTPs, TCP, and UDP are the supported protocols.	Only HTTP and HTTPs are the supported protocols.

Multi-Tenancy Support

App Segmentation

Define QoS profiles on a per slice basis; thus providing the ability to isolate microservices on one slice from another.

Network Policies

Auto deploys network policies across clusters participating in the slice configuration, marshaling configuration drift.

Resource Management

Enables configuration of native Kubernetes resource quotas and limit ranges across clusters on a per slice basis.

Namespace Sameness

Multi-Cluster Namespace

Ensures namespace sameness on a slice across multi-cluster/cloud.

Multi-Cluster

Enables the aggregation of a group of namespaces across clusters thus allowing segmentation for multi-tenancy.

Access Controls

RBAC functionality is propagated across all clusters participating in the slice configuration.

Service Discovery

Auto Discovery of Services

Enables automatic service discovery across clusters participating in the slice configuration.

DNS Entry

When a service is exported on the slice by installing a Service Export object, the Slice Operator creates a DNS entry for the service in the slice DNS and a similar entry is created in the other clusters that are a part of the slice.

IP Address Management

IP Address Management (IPAM) is a method of planning, tracking, and managing the IP address space used in a network. On the KubeSlice Manager, the Maximum Clusters parameter of the slice creation page helps with IPAM. The corresponding YAML parameter is maxClusters.

This parameter sets the maximum number of worker clusters that you can connect to a slice. The maximum number of worker clusters affects the subnet calculation of a worker cluster. The subnet in turn determines the number of host addresses a worker cluster gets for its application pods.

For example, if the slice subnet is 10.1.0.0/16 and the maximum number of clusters is 16, then each cluster gets a subnet of 10.1.x.0/20, where x = 0, 16, or 32.

This is a significant parameter that can only be configured during slice creation. If this parameter is not set, it defaults to 16.

caution

The subnet of a worker cluster determines the number of host addresses that are available to that cluster. Hence, you must be prudent and cautious when you set the maximum worker clusters. The value of the maximum number of clusters set remains constant for the entire life of a slice, and it is immutable after a slice is created.

The fewer the clusters, the more IP addresses are available for the application pods of every worker cluster that is part of a slice. By default, the value of the Maximum Clusters parameter is 16. The supported value range is 2 to 32 clusters.

Connectivity to Clusters in Private VPCs

In addition to connecting public clusters, KubeSlice can also be used to connect clusters that are enclosed within a private VPC. Such clusters are accessed through network or application Load Balancer that are provisioned and managed by the cloud provider. KubeSlice relies on network Load Balancers to setup the inter-cluster connectivity to private clusters.

The following picture illustrates the inter-cluster connectivity set up by KubeSlice using a network Load Balancer (LB).

Users can specify the type of connectivity for a cluster. If the cluster is in a private VPC, the user can utilize the LoadBalancer connectivity type to connect it to other clusters. The default value is NodePort. The user can also configure the gateway protocol while configuring the gateway type. The value can be TCP or UDP. The default value is UDP.

Application Replication

Using KubeSlice, applications can be efficiently replicated from one cloud or data center to another cloud cluster or data center cluster. The replication of applications is facilitated by replication slice, a new type of slice. After the replication of namespaces is complete, the namespaces can be integrated into an application slice that manages them.

Backup and Restore Applications

A replication slice can also be used to back up namespaces by specifying the same cluster as the source and the destination during slice creation. The backed up namespaces can be restored later.

KubeTally

KubeTally is a cost-tracking tool designed for efficient multi-cluster resource management in Kubernetes environments. It provides teams with clear cost insights and accurate resource usage attribution across clusters, facilitating fair and transparent chargeback practices. KubeTally tracks costs for various resources such as Compute, PersistentVolume, and LoadBalancer, allowing for comprehensive cost analysis.

Managed Services Gateway

KubeSlice provides access to private cloud managed services in a VPC through an Envoy-Proxy-based egress gateway. The VPC egress gateway feature enables users to import a private managed service running outside a Kubernetes cluster into a slice. This allows the application pods running in remote clusters to access the managed service through the slice network.

When a worker-cluster with direct access to the cloud managed service in its own VPC is connected to a slice, all the other worker-clusters that are part of the same slice can now access the managed service.

The following figure illustrates how application pods access a cloud-managed service that is onboarded onto a slice.