[solatic]

I dunno, Kubernetes has a query language, it's called jq. As in, kubectl get pods -A -ojson | jq -r '.items[] | ...'. Cyphernetes seems simpler perhaps but it's not the 10x improvement I need to switch and introduce a new dependency.

[philsnow]

I guess they would say that you have to send the output of that to be inputs of another kubectl command like

  $ kubectl logs -n foo $(kubectl get pod -n foo | awk '/Running/{print $1}')

because one of their selling points is "no nested kubectl queries".

I don't see how their queries can be more efficient than hitting the kube-apiserver multiple times, unless they have something that lives clusterside observing lifecycle events for all CRDs and answering queries with only one round-trip instead of multiple.

Or maybe they're selling "no nested kubectl queries" as an experience feature, saying that a query language is more ergonomic than bash command redirection. My brain has been warped into the shape of the shell, for better or for worse, so it's not a selling point for me.

[Thaxll]

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

[mdaniel]

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

[wwader]

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.