demos
sveltosctl
| demos | sveltosctl | |
|---|---|---|
| 7 | 5 | |
| 3 | 19 | |
| - | - | |
| 6.0 | 8.2 | |
| 3 months ago | 8 days ago | |
| Go | ||
| - | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
demos
-
Simplifying Kubernetes Cluster Management with Claudie and Sveltos
can be found here.
-
Collect logs and Kubernetes resources when Pod is in crashloopbackoff state
The ConfigMap referenced by EventBasedAddOn instance contains all resources that will be deployed in each cluster where a Pod in crashing state is found. In this case:
-
Send Slack Notification when Pod is in crashloopbackoff state
All YAMLs used in this example can be found here
-
Multi-tenancy with ProjectSveltos
-
Projectsveltos: Manage Kubernetes addons in multiple clusters
https://github.com/projectsveltos/sveltosctl#display-outcome...
But I was still not happy. Main reason, users still had to go and manage cluster labels. I wanted clusters' labels to change as cluster runtime state was changing. So I can express my intent and then forget about it.
So I introduced a second concept in Sveltos. Classifier CRD (https://github.com/projectsveltos/demos/blob/main/classifier...) which allows users to classify clusters based on cluster runtime state (currently kubernetes version and/or resources deployed, but I am working on adding more).
Doing so I can easily now say:
-
Upgrading Kubernetes addons automatically as cluster runtime state changes
1) I wanted a controller running in the management cluster, so I can express my intent and as clusters come and go or change their runtime state, controller can make sure my intent is applied. For instance, combing Classifier and ClusterProfile I can say things like, in any cluster running kubernetes version v1.24.x install calico v3.23 and in any cluster running kubernetes version v1.25.x install calico v3.24. as clusters are created/upgraded, sveltos makes sure my intent is deployed (https://github.com/projectsveltos/demos/blob/main/classifier/classifier.gif)
-
Deploy Kubernetes add ons in ClusterAPI powered cluster
So a second concept was introduced in Sveltos: Classifier CRD (https://github.com/projectsveltos/demos/blob/main/classifier/classifier.gif) which allows users to classify clusters based on cluster runtime state (currently Kubernetes version and/or resources deployed, but I am working on adding more).
sveltosctl
-
5-Step Approach: ProjectSveltos Event Framework for Kubernetes Deployment with Cilium Gateway API
Once the RKE2 cluster is in a “Running” state, we will use the sveltosctl to register it. For the registration, we need three things: a service account, a kubeconfig associated with that account and a namespace. If you are unsure how to create a Service Account and an associated kubeconfig, there is a script publicly available to help you out.
-
5-Step Approach: Projectsveltos for Kubernetes add-on deployment and management on RKE2
The Sveltosctl, is the command-line interface (CLI) for Sveltos. This is an available option to query Sveltos resources and it is available as a Kubernetes pod or as a binary.
-
Collecting tech-supports from managed Kubernetes clusters (and more)
sveltosctl can be used to display collected techsupports.
-
Kubernetes multi-tenancy with projectsveltos
Using sveltosctl we can verify Sveltos is aware system-admin has full access to managed cluster with label env:production
-
Projectsveltos: Manage Kubernetes addons in multiple clusters
https://github.com/projectsveltos/sveltosctl#display-outcome...
But I was still not happy. Main reason, users still had to go and manage cluster labels. I wanted clusters' labels to change as cluster runtime state was changing. So I can express my intent and then forget about it.
So I introduced a second concept in Sveltos. Classifier CRD (https://github.com/projectsveltos/demos/blob/main/classifier...) which allows users to classify clusters based on cluster runtime state (currently kubernetes version and/or resources deployed, but I am working on adding more).
Doing so I can easily now say:
What are some alternatives?
addon-controller - Sveltos Kubernetes add-on controller programmatically deploys add-ons and applications in tens of clusters. Support for ClusterAPI powered clusters, Helm charts, kustomize ,YAMLs. Sveltos has built-in support for multi-tenancy.
sveltos-manager - Sveltos is tool for managing Kubernetes add-ons in tens of clusters. Support for ClusterAPI powered clusters and helm charts. Sveltos has built-in support for multi-tenancy. [Moved to: https://github.com/projectsveltos/addon-manager]
sveltos - Contains documentation for projectsveltos
sveltos-agent - Classify cluster and report back to management cluster. Evaluates cluster health based on custom health checks. Watches for events and reports those to management cluster.
k8s_collector - A Kubernetes Job to collect resources, logs and events
classifier - Sveltos Classifier dynamically classify a cluster based on run time information (Kubernetes version, deployed resources and more)
kind - Kubernetes IN Docker - local clusters for testing Kubernetes
cluster-api - Home for Cluster API, a subproject of sig-cluster-lifecycle
Kyverno - Kubernetes Native Policy Management
claudie-sveltos-integration - This repository aims to streamline the integration between Claudie and Sveltos. It incorporates a controller that monitors Claudie's Secrets for kubeconfig files of Claudie-managed clusters and automatically creates corresponding SveltosCluster resources.