kubernetes: Kubectl describe doesn't support json output

@janetkuo why saying so? Doesn’t make much sense to me that some of the commands support json and other don’t. I might be missing the point and would love to hear your point of view. describe has some additional info if compared to get which people could need to access programmatically automating their infrastructure.

By saying “we should not support” you are forcing them to rely on parsing the output, which is by no mean reliable as any change would break their implementations.

The reason why I’m asking this here and not on the other referenced issue is that I strongly believe they are highly related but still separate

@isubuz you may just say so in the issue. However I don’t think we should support json output in describe. Closing this as a dup of #25355 and we can continue the discussion there.

I run kubectl describe pod <pod-name> to find which node the pod lives on. Having this information outputted as YAML or JSON allows me to get that info easily in an automated manner. Doing so with regular output, I have to deal with grep, awk and splitting hostname from IP, and so on.

It doesn’t matter describe doesn’t return a single object. I’m interested in a JSON/YAML representation of describe output, and that’s it. For example, it lists pod’s labels. Great, let me access that via JSON/YAML too, not just plain text. Event history? Great, have in in JSON/YAML output too.

Please consider reopening @liggitt because the use case is legitimate. Thanks.

If we want a programmatic way to get, say, allocated resources info from a node, we should probably expose that in node status, and thus that information can be retrieved with get -o json.

I don’t think describe ever existed with the intention to make it programatically consumable. Agreed it’s a part of a larger discussion and we should definitely provide programmatic access to all info, I am just not sure how to do it or if a simple -o json flag is the solution.

You can get the json for a single node by specifying its name in kubectl get:

kubectl get node k8s-node-name-here -o=json

Let me know if you’d like to keep this issue as a feature request for the describe command.

If your goal is to get specific information from describe that is not available anywhere else, we should open an issue for making it available elsewhere.

It does if it means we have to invent a new API representation for kubectl to output the stitched-together version of those objects

libxo is a nice way to do it - popular on FreeBSD. Most userland utilities got JSON/YAML output capabilities because of this. It’s like printf but preserves context for other formats.

I run kubectl describe pod <pod-name> to find which node the pod lives on. Having this information outputted as YAML or JSON allows me to get that info easily in an automated manner. Doing so with regular output, I have to deal with grep, awk and splitting hostname from IP, and so on.

kubectl get pod <name> -o json (or -o jsonpath="{.spec.nodeName}") is what you want for getting api content

It doesn’t matter describe doesn’t return a single object.

It does if it means we have to invent a new API representation for kubectl to output the stitched-together version of those objects

I’m interested in a JSON/YAML representation of describe output, and that’s it.

use kubectl get … -o json to get API content. pod labels can be accessed that way, as can event content (kubectl get can filter by label selectors and field selectors)

It’s a human-only tool that enables administrative scripting. For example:

 kubectl get nodes --template '{{ range .items.status.allocatable }}{{

output CSV style data }}’ | tr <cleverness> | <more bash magic>

I think the use case you described is probably achievable through kubectl. The point is Kubectl doesn’t itself add new APIs.

On Wed, Jun 15, 2016 at 4:26 AM, Jacopo Nardiello notifications@github.com wrote:

Note that you need to explicitly ask for json output in get. Its default output is human-friendly.

Either it’s a human-only tool, in which case we are cool, or it’s a mix with machine-friendly features (that people will use, default or not), in which case you need to be consistent across all your interfaces imho. Again, this is out of the scope of our specific needs for which adding the info to the get command would be just fine.

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/kubernetes/kubernetes/issues/25353#issuecomment-226121307, or mute the thread https://github.com/notifications/unsubscribe/ABG_p8TaaxhQOx6Npkduy_Eu3dcEAabzks5qL7cvgaJpZM4IaKVv .