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?
Cyphernetes: A Query Language for Kubernetes
31–40 of 69 posts
Re: Cyphernetes: A Query Language for Kubernetes
#32Re: Cyphernetes: A Query Language for Kubernetes
#33Earlier 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.
Re: Cyphernetes: A Query Language for Kubernetes
#34The brew install cyphernetes at the top of the page is an immediate turn-off.
Re: Cyphernetes: A Query Language for Kubernetes
#35Earlier 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.
Re: Cyphernetes: A Query Language for Kubernetes
#36I'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.
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
#37I 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…
Re: Cyphernetes: A Query Language for Kubernetes
#38During 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?
Re: Cyphernetes: A Query Language for Kubernetes
#39Re: Cyphernetes: A Query Language for Kubernetes
#40Earlier 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