[danpalmer]

I'm not against replacing jq/jsonpath for the right tool, they're not the most ergonomic. What isn't clear to me though is why this isn't SQL? It's so nearly SQL, and seems to support almost identical semantics. I realise SQL isn't perfect, but the goal of this project isn't (I assume) to invent a new query language, but to make Kubernetes more easily queryable.

[rubenvanwyk]

It's based on Cypher, which is a query languages for graph databases. The author/s probably thought the data is more graph-like than relational.

[danpalmer]

Ah. I’ve not heard of Cypher before.

I’d disagree and say that Kubernetes is much more relational that graph based, and SQL is pretty good for querying graphs anyway, especially with some custom extensions.

This does make more sense though.

[amanj41]

Graph DBs are generalized relationship stores. SQL can work for querying graphs, but graph DB DSLs like Cypher become very powerful when you're trying to match across multiple relationship hops.

For example, to find all friend of a friend or friends of a friend of a friend: `MATCH (user:User {username: "amanj41"})-[:KNOWS*2..3]->(foaf) WHERE NOT((user)-[:KNOWS]->(foaf)) RETURN user, foaf`

[philsnow]

Reading your comment made me think that they're so close to "OSQuery for k8s", but that already seems to exist: https://www.uptycs.com/blog/kubequery-brings-the-power-of-os...

[captn3m0]

I haven't tried it , but steampipe has a k8s plugin which lets you use PG/sqlite: https://hub.steampipe.io/plugins/turbot/kubernetes/tables

[ricenb]

For SQL based query, you could take a look at Karpor(https://github.com/KusionStack/karpor), which provides powerful, flexible queries across multi clusters, also in the next release we will support Cyphernetes as other query method.