Hello everyone, here's an update for July!
Last month we introduced our new config system, with the ability to edit your Resoto configuration on the fly via Resoto Shell. Not everyone is comfortable working with the shell though, and so we added a new web-based UI.
So far, Resoto has worked out-of-the-box for the "native" cloud providers AWS, Google Cloud, and DigitalOcean. But our users have been telling us that they're not just running "bare metal" on these clouds. No surprise—most of them use Kubernetes for orchestration. You can now point Resoto to your kubeconfig file, with which Resoto will collect all available contexts.
Resoto's unified data model still applies. Common Resoto types like
volume are still relevant with Kubernetes. We went "deep" on Kubernetes from day one, meaning we support the entire set of 100+ Kubernetes properties. Full-text search, piping commands, and performing jobs (like tag and cleanup) also work for Kubernetes.
We think you will be delighted to use Resoto with Kubernetes. For more details, check out Matthias' blog post.
To add Kubernetes support, we first had to build new capabilities into our data model. Nested properties is one such capability.
The first version of Resoto supported simple structures—think "a resource with a property." This simple structure unfortunately doesn't work well with the nested structures commonplace in Kubernetes. For example, one Kubernetes pod can contain multiple containers. Within each of those containers, you then have a long list of possible properties (from the 100+ mentioned above). Each of those nested properties can be accessed and used for filtering or information retrieval.
Resoto now supports arbitrary complex models with nested properties. We also made sure autocomplete in Resoto Shell works with complex models. You can (literally) navigate through nested properties as you type.
Multi-Cloud Graph Edges
Another fundamental capability we launched with Kubernetes support is support for graph edges between different clouds.
Data collection and definition of resource dependencies within Resoto happens with cloud-specific collectors. Since collectors are cloud-specific, so far Resoto has only supported dependencies within a cloud, not between clouds.
Kubernetes resources are abstracted away from the underlying cloud provider. The Kubernetes collector knows nothing about AWS or EC2 instances, while the AWS collector only knows AWS services like EC2 and EKS. With multi-cloud edge support, Resoto can now track relationships between the two, creating the complete call graph for a view of the entire stack from ingress, via pod, deployment, k8s node, or compute instance down to the hardware.
This new feature provides insights across multi-cloud infrastructure. Since we see a lot of multi-cloud deployments in the enterprise, we will continue to extend our collectors to provide additional insights into relationships across clouds.
Read more about nested properties and multi-cloud graph edges in the release notes.
Have feedback or need help? Don’t be shy—we’d love to hear from you!