Cyphernetes: A Query Language for Kubernetes • Hacker News Board

Re: Cyphernetes: A Query Language for Kubernetes

#61

Post by moshloop » Mon, Dec 16, 2024, 7:41 PM UTC

alpb wrote: post #13

During many years of operating several-thousands of nodes production clusters on Kubernetes, I've never seen any of these observability tools that query kube-apiserver work at that scale. Even the popular tools like k9s make super expensive queries like listing all pods in the cluster that if you don't have enough load protections, can tip your Kubernetes apiserver over and cause an incident. If you're serious about…

This is the approach we took while building our Internal Developer Platform: watches (via client-go informers with client-side caching) to sync data into a Postgres database as JSONB. Changes are tracked using JSON patches and Kubernetes events. To avoid a watch on every resource kind, we handle this by performing incremental object fetches for the objects involved in watched events.

Getting this to perform well required several optimizations at both the Go and Postgres levels. On the Go side, we use prioritized work queues, event de-duplication, and even switched to Rust for efficient JSON diffs. For Postgres, we leverage materialized views and trigger-based optimistic locking

Re: Cyphernetes: A Query Language for Kubernetes

#62

Post by jeffreyaven » Mon, Dec 16, 2024, 9:57 PM UTC

our project https://github.com/stackql/stackql has a k8s provider which might be of interest here, we implement our own front end SQL parser and expose all control plane routes (and data plane routes in many cases) through overloaded SQL methods, this is not FDW based and does not require a server (postgres etc)

Re: Cyphernetes: A Query Language for Kubernetes

#63

Post by elliotxx » Tue, Dec 17, 2024, 3:42 AM UTC

alpb wrote: post #13

During many years of operating several-thousands of nodes production clusters on Kubernetes, I've never seen any of these observability tools that query kube-apiserver work at that scale. Even the popular tools like k9s make super expensive queries like listing all pods in the cluster that if you don't have enough load protections, can tip your Kubernetes apiserver over and cause an incident. If you're serious about…

That's how https://github.com/KusionStack/karpor did it. It has a resource-syncer component to synchronize resources in real time to Elasticsearch, and then allows users to search for K8S resources through SQL and natural language through a search bar on a web UI.

In fact, recently it is preparing to integrate Cyphernetes as a new search method. I believe this will be a new start!

Re: Cyphernetes: A Query Language for Kubernetes

#64

Post by fatliverfreddy » Tue, Dec 17, 2024, 4:57 AM UTC

atombender wrote: post #54

This looks great for scripting. I will say that the query language looks a bit too verbose for daily use — meaning when you're interacting with a cluster to diagnose a problem, follow a job, testing the rollout of something experimental, or similar. For example, I'd love to be able to just do this as the whole query: metadata.name =~ "foo%" or maybe: .. =~ "foo%" // Any field matches or maybe: $pod and metadata.name…

Hey, thanks for the feedback!

re. intended purpose: Initially I started writing this to help tackle bigger problems - stuff you'd normally use multiple nested kubectl commands or write a lot of code for interacting with api-server.

Over time, I developed the shell environment around it and it became a daily driver for me as well. Indeed, there's a threshold where writing Cyphernetes becomes more economical than using kubectl but for doing most of the simple day to day stuff writing Cypher is too verbose.

The Cyphernetes shell has an early-stage feature that allows a syntax like you suggested - there's a tiny "macros" feature that lets you define custom procedures of one or more queries (currently shell only, not supported in the web client yet).

Macros are prefixed by ":" and you could define something like:

:pod condition

MATCH (pods:Pod) WHERE $condition

RETURN p.metadata.name, p.status.phase; // and whatever other fields you'd like

Then use it like this: > :pod .metadata.name=~"foo%"

So it gives you a tiny way to customize how you do this day-to-day stuff. Ships out-of-the-box with common stuff you do with kubectl like :getpo, :getdeploy, :createdeploy, :expose and so on - definitely a feature that could be developed further to make this more of a daily driver.

Re: Cyphernetes: A Query Language for Kubernetes

#65

Post by ricenb » Tue, Dec 17, 2024, 5:41 AM UTC

danpalmer wrote: post #6

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.

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.

Re: Cyphernetes: A Query Language for Kubernetes

#66

Post by ricenb » Tue, Dec 17, 2024, 5:51 AM UTC

omrispector wrote: post #29

This is way cool. The ability to visualize the k8s object model as a graph and query it as such makes so much sense! The hottest feature in my mind is applying this in an operator - maintaining state as defined by a simple graph query. It is much more readable, and does so with very little code. Well Done!

Since you mentioned visualize k8s object model as a graph, I guess you might be interested in: https://karpor-demo.kusionstack.io/, hope this can bring some new possibility to you.

Disclaimer: I am the creator of Karpor.

Re: Cyphernetes: A Query Language for Kubernetes

#67

Post by wwader » Tue, Dec 17, 2024, 10:19 AM UTC

mdaniel wrote: post #60

Thaxll wrote: post #4

Earlier quoted context omitted.

You usually don't need that, since kubectl supports jsonpath.

I am firmly in the camp of jq because (a) I am able to bring my years of muscle memory to this problem (b) jq is without a doubt more expressive than jsonpath (c) related to the muscle memory part I have uncanny valley syndrome trying to context switch between jsonpath and jmespath (used by awscli for some stupid reason) so it's much easier to just use the one true json swiss-army tool upon the json those clis emit

Note on (b): As i understand it JSONPath by design is limited to only be able to select things from the input, so can't build a new object, array etc.

Re: Cyphernetes: A Query Language for Kubernetes

#68

Post by devops99 » Thu, Dec 19, 2024, 2:58 AM UTC

marxisttemp wrote: post #59

rjh29 wrote: post #20

Earlier quoted context omitted.

Agree but I'm not sure why. I'm not a mac user so the initial impression is like "this isn't for you, go away". At least add a linux command alongside it!

Even on macOS, brew is wildly inferior to MacPorts; to be fair, brew is “blessed” by Swift Package Manager whereas MacPorts is not, but this is ironic given the guy behind MacPorts both worked at Apple and designed the original FreeBSD ports system.

That's the very weird thing about the little universe within Apple's macOS, there are pockets of very high quality here and there, next to "what the fuck are you guys even doing?", and a Unix core that's been effectively bastardized, abandoned, and frankenstein'd

Instead of Compton a short ride from Beverly Hills it's like the houses from those two wildly different hoods all stacked in a repeatedly alternating sequence.

Re: Cyphernetes: A Query Language for Kubernetes

#69

Post by marxisttemp » Fri, Dec 20, 2024, 6:20 PM UTC

devops99 wrote: post #68

marxisttemp wrote: post #59

Earlier quoted context omitted.

Even on macOS, brew is wildly inferior to MacPorts; to be fair, brew is “blessed” by Swift Package Manager whereas MacPorts is not, but this is ironic given the guy behind MacPorts both worked at Apple and designed the original FreeBSD ports system.

That's the very weird thing about the little universe within Apple's macOS, there are pockets of very high quality here and there, next to "what the fuck are you guys even doing?", and a Unix core that's been effectively bastardized, abandoned, and frankenstein'd Instead of Compton a short ride from Beverly Hills it's like the houses from those two wildly different hoods all stacked in a repeatedly alternating sequen…

I think the overall quality level on Macs is leagues above anyone else, even the UNIX stuff (I personally prefer the BSD utils to the GNU ones, which pretty much anyone else running POSIX stuff is using unless they’re daily-driving an actual BSD.

I just don’t get why Apple would hire Jordan Hubbard for their UNIX team, see him implement a very well thought out version of the standard package manager of all time that he also wrote, and then decide to use brew as their blessed package manager for their various open source releases, .systemLibrary in Swift packages, etc.