Single Pane of Glass through the Terminal (using the CLI) - yes, it seems it could be; I'm wondering if there's opportunity to integrate with Cluster API for Mgmt Cluster. Also, is it a matter of time before a UI becomes available to look/filter across clusters?
@ErickCarty Until (and if) they build a UI we can use any kubernetes UI with it. Lens, for example, works with it. That's the beauty of the solution. Even though it is data stored in postgresql, it's exposed through a kube API compatible interface so any tool used to visualize kubernetes should work with it.
Thanks for another great video! I didn't know about this project and it looks promising. Another feature is that it allows to have a single pane of glass for kube-state-metrics which adds the "cluster" label to all the metrics that are normally exposed by kube-state-metrics and this could be useful for a centralized monitoring solution.
Imho this is a passive pane of glass, ie does not let you remediate issue/problem related with cluster's infra resources beneath for which it would need iaas api integrations, also tenancy (tenant-admin) seems lacking. To be honest; open cluster management (ocm) addresses much better platform ops scope. However I see the value for having such cli level hero capabilities for pods.
The goal is to be a single pane of glass for observability (e.g., read-only kubectl commands). That's actually what I like about it. It does not "clash" with anything else. OCM, on the other hand, requires changes to how we manage resources across cluster (e.g., does it replace Argo CD or suplement it?).
This is in the roadmap of clusterpedia to edit things, but may not be implemented.(It depends) And it can collaborate with other tools OCM/Karmada/ClusterNet. In Karmada, there is a search tool which is similar to clusterpedia but is quite simple one.
I think they are very different. KCP is about distributing resources across clusters while Clusterpedia is about observing resources across clusters. There is some overlap, but not much though.
In the past, OCM and Clusterpedia had some key differences... OCM: Collects all resources including custom resources by default. Collects resource relationships. RBAC per user and managed cluster. UI and API. Missing CLI Easy access to YAML for any resource. Easy access to pod logs. Edit and delete actions on any resource. Clusterpedia: User needs to configure which resources will get collected. No resource relationship data. No RBAC for collected resources. Optimized for CLI Limited to list view. Need to switch context to access resource yaml. Need to switch context to access pod logs. No edit or delete from Clusterpedia, need to switch context.
I use steampipe for this functionality but at the same time I get native postgres queries, cache, the ability to query aws and azure, as well as join all those results and I don't have to install anything on a cluster to do all of it. you should do a video about steampipe
I just don't see it. A read-only cache of cherry picked resources, reliant on a secondary data store, and certificate credentials embedded in the YAML. How hard could it be to switch contexts and enumerate resources directly from the clusters? For loop anyone? Hiding resources by failing to index them is not security, and it seems like that was the spin they wanted to put on the tool - adjusting the RBAC is how one affects this. This wasn't up to your usual level. Look forward to the next one.
Actually, having a loop that switches context and makes requests from each of the clusters is not a good idea at scale. Etcd is a common bottleneck and such a set of queries can take a while to run. Essentially, one of the goals of the tool is to remove etcd from being the bottleneck.
@@DevOpsToolkit - If the problem is etcd slowness, what's happening on the etcd dev front to address that? If an RO cache of multiple etcd states is in fact desireable - as you seem to think it is - why use such a heavy weight mechanisms to build the cache?
@roganl i think that's the question to be addressed outside the scope of clusterpedia. Kubernetes does have the possibility to change etcd for some other DB but, in most cases, that is not used (especially by vendors). If the question is whether we should replace etcd by something else, my answer is yes. When that becomes a norm, there might be no need for clusterpedia in it's current form.
@@DevOpsToolkit WRT the etcd bottleneck, the queries are all independent of each other, and could easily be forked off, and concatenated upon completion - the aggregation need only take as long as the slowest cluster to respond. LMK if I am missing something here.
@@roganl There are other fundamental problems. For example, there is no option to retrieve all resources from a Kubernetes cluster. `kubectl get all` returns only some of the resources. Further on, there is no option to query resources beyond using labels and annotation, there are no historical data, etc. Kubernetes maintains the current state of itself in a key value store. That's very different from having data in a SQL database. Key/value might serve Kubernetes well for what it's meant to do (have a record of the current state), but not for observing, querying, etc. Internally, completely unrelated to Clusterpedia, we are replacing etcd with a SQL database and making it a central DB for multiple clusters. That allows us to do some thing we could not do before or were too slow. I can't say much about it since it's not public so I'm mentioning only to illustrate that etcd is not always the right answer and that it often depends on what you're trying to accomplish.
Is Clusterpedia the single pane of glass we need for Kubernetes clusters?
Single Pane of Glass through the Terminal (using the CLI) - yes, it seems it could be; I'm wondering if there's opportunity to integrate with Cluster API for Mgmt Cluster. Also, is it a matter of time before a UI becomes available to look/filter across clusters?
@ErickCarty Until (and if) they build a UI we can use any kubernetes UI with it. Lens, for example, works with it. That's the beauty of the solution. Even though it is data stored in postgresql, it's exposed through a kube API compatible interface so any tool used to visualize kubernetes should work with it.
Thanks for another great video! I didn't know about this project and it looks promising.
Another feature is that it allows to have a single pane of glass for kube-state-metrics which adds the "cluster" label to all the metrics that are normally exposed by kube-state-metrics and this could be useful for a centralized monitoring solution.
That's the beauty of it. Kube state metrics are essentially Kubernetes resources and, therefore, synceable into Clusterpedia's DB like any other.
Loving the hair dude!!
interesting, I will give this a try. Thanks.
Imho this is a passive pane of glass, ie does not let you remediate issue/problem related with cluster's infra resources beneath for which it would need iaas api integrations, also tenancy (tenant-admin) seems lacking. To be honest; open cluster management (ocm) addresses much better platform ops scope. However I see the value for having such cli level hero capabilities for pods.
The goal is to be a single pane of glass for observability (e.g., read-only kubectl commands). That's actually what I like about it. It does not "clash" with anything else. OCM, on the other hand, requires changes to how we manage resources across cluster (e.g., does it replace Argo CD or suplement it?).
@@DevOpsToolkit OCM uses ArgoCD extensively
This is in the roadmap of clusterpedia to edit things, but may not be implemented.(It depends)
And it can collaborate with other tools OCM/Karmada/ClusterNet.
In Karmada, there is a search tool which is similar to clusterpedia but is quite simple one.
@prometheon123 I should revisit OCM. It's been a while since i checked it out and do not even remember the details any more. Next week...
Fantastic tool !!
Would've liked to see a short comparison of this with kcp or other similar projects somewhere in the video
I think they are very different. KCP is about distributing resources across clusters while Clusterpedia is about observing resources across clusters. There is some overlap, but not much though.
In the past, OCM and Clusterpedia had some key differences...
OCM:
Collects all resources including custom resources by default.
Collects resource relationships.
RBAC per user and managed cluster.
UI and API. Missing CLI
Easy access to YAML for any resource.
Easy access to pod logs.
Edit and delete actions on any resource.
Clusterpedia:
User needs to configure which resources will get collected.
No resource relationship data.
No RBAC for collected resources.
Optimized for CLI
Limited to list view. Need to switch context to access resource yaml.
Need to switch context to access pod logs.
No edit or delete from Clusterpedia, need to switch context.
I use steampipe for this functionality but at the same time I get native postgres queries, cache, the ability to query aws and azure, as well as join all those results and I don't have to install anything on a cluster to do all of it.
you should do a video about steampipe
I already have it on my to-do list for one of the upcoming videos 🙂
I was already working on a Steampipe video in parallel with Clusterpedia. It took me a while to finish it.
ruclips.net/video/0pG3txMPKJI/видео.html
Pretty Cool Viktor!!! Can you review Opni for Multi-Cluster Observability???
Adding it to my TODO list... :)
Would love to have a k9s plugin for this, though will have to see how it performs out of the box.
I haven't tried it with k9s (yet) but I'm guessing that it should work without the need for any plugin.
Can Clusterpedia connect to other Clusterpedias?
I haven't tried that (yet).
A possible solution is that multi clusterpedia may share the same datebase. Then each clusterpedia help to sync clusters under its management.
I just don't see it. A read-only cache of cherry picked resources, reliant on a secondary data store, and certificate credentials embedded in the YAML. How hard could it be to switch contexts and enumerate resources directly from the clusters? For loop anyone? Hiding resources by failing to index them is not security, and it seems like that was the spin they wanted to put on the tool - adjusting the RBAC is how one affects this. This wasn't up to your usual level. Look forward to the next one.
Actually, having a loop that switches context and makes requests from each of the clusters is not a good idea at scale. Etcd is a common bottleneck and such a set of queries can take a while to run. Essentially, one of the goals of the tool is to remove etcd from being the bottleneck.
@@DevOpsToolkit - If the problem is etcd slowness, what's happening on the etcd dev front to address that? If an RO cache of multiple etcd states is in fact desireable - as you seem to think it is - why use such a heavy weight mechanisms to build the cache?
@roganl i think that's the question to be addressed outside the scope of clusterpedia. Kubernetes does have the possibility to change etcd for some other DB but, in most cases, that is not used (especially by vendors). If the question is whether we should replace etcd by something else, my answer is yes. When that becomes a norm, there might be no need for clusterpedia in it's current form.
@@DevOpsToolkit WRT the etcd bottleneck, the queries are all independent of each other, and could easily be forked off, and concatenated upon completion - the aggregation need only take as long as the slowest cluster to respond. LMK if I am missing something here.
@@roganl There are other fundamental problems. For example, there is no option to retrieve all resources from a Kubernetes cluster. `kubectl get all` returns only some of the resources. Further on, there is no option to query resources beyond using labels and annotation, there are no historical data, etc. Kubernetes maintains the current state of itself in a key value store. That's very different from having data in a SQL database. Key/value might serve Kubernetes well for what it's meant to do (have a record of the current state), but not for observing, querying, etc.
Internally, completely unrelated to Clusterpedia, we are replacing etcd with a SQL database and making it a central DB for multiple clusters. That allows us to do some thing we could not do before or were too slow. I can't say much about it since it's not public so I'm mentioning only to illustrate that etcd is not always the right answer and that it often depends on what you're trying to accomplish.
Is there a UI for clusterpedia, or are there any other tools can help view multi cluster inventories in a single UI?
Since it exposes information as a kube API compatible interface, You can use any UI you would normally use for kubernetes (e.g. Lens).
#til