Live data from Hacker News

Cyphernetes: A Query Language for Kubernetes

cyphernet.es

31–40 of 69 posts

Re: Cyphernetes: A Query Language for Kubernetes

#31
post #23
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…

how are Kubernetes apiservers suffering this much from this kind of query? Surely even in huge systems the amount of data that would need to be traversed is super small, right? Is this a question of Kubernetes just sticking everything into "standard" datastructures instead of using a database?

Pretty sure the apiserver just queries the etcd database (and maybe caches some things, not sure) but i guess it could be the apiserver itself that can't handle the data :P

Re: Cyphernetes: A Query Language for Kubernetes

#33
post #24
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!

Homebrew has a Linux variant, but I assume almost nobody uses it. Personally use a Mac with Nix, and so do many of my coworkers. Assuming Homebrew, even for a Mac user, leaves a bad impression on me.

I also prefer Mac with Nix over homebrew.

Re: Cyphernetes: A Query Language for Kubernetes

#35
post #22

Earlier quoted context omitted.

why?..

Kubernetes only runs on linux, so it follows to reason if you care about k8s you should care about linux. My experience is also that good experienced sysadmins often use linux for their own machines as well. Targetting a tool at macOS users, and omitting linux instructions, gives the impression that the tool isn't targeted at sysadmins or hackers (i.e. at us), but rather at beginners, frontend developers, etc.

Saying it's targeted at beginners because it supports MacOS shows a lot of disconnection with what many DevOps people use these days. The year of the linux desktop has yet to arrive, and Mac is king for people in IT (at least in the US)

Re: Cyphernetes: A Query Language for Kubernetes

#36

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.

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.

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.

Re: Cyphernetes: A Query Language for Kubernetes

#37
post #21

I really really like Steampipe to do this kind of query: https://steampipe.io , which is essentially PostgreSQL (literally) to query many different kind of APIs, which means you have access to all PostgreSQL's SQL language can offer to request data. They have a Kubernetes plugin at https://hub.steampipe.io/plugins/turbot/kubernetes and there are a couple of things I really like: * it's super easy to request multiple…

I really like Steampipe too. Writing the plugins is quite fun.

Re: Cyphernetes: A Query Language for Kubernetes

#38
post #23
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…

how are Kubernetes apiservers suffering this much from this kind of query? Surely even in huge systems the amount of data that would need to be traversed is super small, right? Is this a question of Kubernetes just sticking everything into "standard" datastructures instead of using a database?

I no longer know anything about Kubernetes, but share your surprise! From first principles it seems the metadata should be small.

Re: Cyphernetes: A Query Language for Kubernetes

#40
post #30

Earlier quoted context omitted.

the thing is you'd need 3 k8s queries, one for pods, one for deployments, one for services, then link all of them, and filter... jq helps with the filtering, kubectl can query, but you still need to join the 3 resources to answer the query...

Right, so doable just a bit more effort to do 3 queries to pipes or tmp files

This is Dropbox comment all over again. Lots of things are doable with more manual effort.
Post reply on HN