sveltos-agent
demos
| sveltos-agent | demos | |
|---|---|---|
| 1 | 7 | |
| 3 | 3 | |
| - | - | |
| 8.4 | 6.0 | |
| 6 days ago | 3 months 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.
sveltos-agent
-
Collect logs and Kubernetes resources when Pod is in crashloopbackoff state
To detect events in managed cluster and evaluate health, Lua language is used. Create an EventSource instance can be created to define what an event is. HealthCheck instance can be created to define what an health rule is.
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).
What are some alternatives?
helmsman - Helm Charts as Code
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.
capsule - Multi-tenancy and policy-based framework for Kubernetes.
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]
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)