Imagine KubeStellar as a post office for your Kubernetes resources. When you drop packages at the post office, they don't open them; they deliver them to the right recipients. Similarly, KubeStellar works like this for your Kubernetes resources. Instead of running resources right away, KubeStellar safely stores and sends resources to selected clusters across the globe—whether they're in public clouds, private clouds, or on the edge of your network. It's a super useful tool for spreading your Kubernetes resources wherever you need them without disrupting your existing tools and workflows.
How does KubeStellar resist the temptation to run your Kubernetes resources right away? KubeStellar accepts your applied resources in a special staging area (virtual cluster) where pods can't be created. Then, at your direction, KubeStellar transfers your applied resources to remote clusters where they can create pods and other required resource dependencies. KubeStellar does this using many different lightweight virtual cluster providers (Kind, KubeFlex, KCP, etc.) to create this special staging area.
KubeStellar is an innovative way to stage inactive Kubernetes resources and then apply them to any cluster to run. KubeStellar introduces a native way to expand, optimize, and protect your Kubernetes resources from individual cluster misconfiguration, utilization, and failure.
Don't change anything, just add KubeStellar!
- Centrally apply Kubernetes resources for selective deployment across multiple clusters
- Use standard Kubernetes native deployment tools (kubectl, Helm, Kustomize, ArgoCD, Flux); no resource bundling required
- Discover dynamically created objects created on remote clusters
- Make disconnected cluster operation possible
- Scale with 1:many and many:1 scenarios
- Remain compatible with cloud-native solutions
- KubeStellar uses lightweight virtual clusters (Spaces) that run inside the KubeStellar hosting cluster
- Standard Kubernetes clusters have 2-300 api-resources, KubeStellar Spaces have only 40
- Fewer api-resources mean resources remain inactive (denatured) – they do not expand into other resources like replicasets, pods, etc.
- Denaturing is the key to accepting native, unbundled Kubernetes resources as input without running them
- Unbundled resources are the default and preferred output of most cloud-native tools making KubeStellar use and integration easy
Checkout our QuickStart Guide
We have defined and largely completed the PoC2023q1. The current activity is refining the definition of, and producing, the PoC2023q4. Goals not addressed in that PoC are to be explored later.
We ❤️ our contributors! If you're interested in helping us out, please head over to our Contributing guide.
This community has a Code of Conduct. Please make sure to follow it.
There are several ways to communicate with us:
Instantly get access to our documents and meeting invites at http://kubestellar.io/joinus
- The
#kubestellar-devchannel in the Kubernetes Slack workspace - Our mailing lists:
- kubestellar-dev for development discussions
- kubestellar-users for discussions among users and potential users
- Subscribe to the community calendar for community meetings and events
- The kubestellar-dev mailing list is subscribed to this calendar
- See recordings of past KubeStellar community meetings on YouTube
- See upcoming and past community meeting agendas and notes
- Browse the shared Google Drive to share design docs, notes, etc.
- Members of the kubestellar-dev mailing list can view this drive
- Read our documentation
- Follow us on:
- LinkedIn - #kubestellar
- Medium - kubestellar.medium.com
Thanks go to these wonderful people:
