kubectl: describe vs get -o <format>

Question

In kubectl, both describe and get -o <format> can be used to get the details of a resource, I'm wondering what's the difference between the two? why does describe even exist if get can do the same thing and more?

Answer 1

• kubectl get shows tables by default. (You can view/visualize large no of objects easily)

• kubectl describe shows the detailed description. (Better for a single object)

• kubectl describe is more flattened, has lesser data and easier to read than the full object data given by kubectl get -o yaml

Help output for reference.

kubectl describe -h

Show details of a specific resource or group of resources

 Print a detailed description of the selected resources, including related resources such as events or controllers. You
may select a single object by name, all objects of that type, provide a name prefix, or label selector. For example:

  $ kubectl describe TYPE NAME_PREFIX

 will first check for an exact match on TYPE and NAME_PREFIX. If no such resource exists, it will output details for
every resource that has a name prefixed with NAME_PREFIX.

Use "kubectl api-resources" for a complete list of supported resources.

kubectl get -h

Display one or many resources

 Prints a table of the most important information about the specified resources. You can filter the list using a label
selector and the --selector flag. If the desired resource type is namespaced you will only see results in your current
namespace unless you pass --all-namespaces.

 Uninitialized objects are not shown unless --include-uninitialized is passed.

 By specifying the output as 'template' and providing a Go template as the value of the --template flag, you can filter
the attributes of the fetched resources.

Use "kubectl api-resources" for a complete list of supported resources.

Answer 2

A simple explanation could be:

kubectl describe .. == Filterred kubectl get .. -o <format> + relevant events

---

For debugging purposes it can be useful to look at both describe and get -o <format> since each one has relevant information that is not shown in the other.

Note that events can also be shown by running kubectl get events (for default namespace), or kubectl get event --all-namespaces (for all namespaces).

---

Some digging:

Running kubectl describe with extended logging --v=8 shows that it calls the events API (the third call) with involvedObject.name%3Dsome-pod.

$ kubectl --v=8 describe pod some-pod 2>&1 | grep GET
I1216 17:09:00.453529    6918 round_trippers.go:416] GET https://100.190.50.200/api/v1/namespaces/default/pods/some-pod
I1216 17:09:01.098053    6918 round_trippers.go:416] GET https://100.190.50.200/api/v1/namespaces/default/pods/some-pod
I1216 17:09:01.265924    6918 round_trippers.go:416] GET https://100.190.50.200/api/v1/namespaces/default/events?fieldSelector=involvedObject.name%3Dsome-pod%2CinvolvedObject.namespace%3Ddefault%2CinvolvedObject.uid%3Dbf664be1-1cde-11ea-bce6-42010af00267

kubectl get pod some-pod -o yaml only calls the pods API.

kubectl --v=8 get pod some-pod -o yaml 2>&1 | grep GET
I1216 17:13:21.084386   28256 round_trippers.go:416] GET https://100.190.50.200/api/v1/namespaces/default/pods/some-pod

Answer 3

According to kubernetes documentation:

kubectl -n <NAMESPACE> get <NAME_OF_RESOURCE>

Prints a table of the most important information about the specified resources. You can filter the list using a label selector and the --selector flag. If the desired resource type is namespaced you will only see results in your current namespace unless you pass --all-namespaces. Source: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get

kubectl -n <NAMESPACE> describe <NAME_OF_RESOURCE>

Print a detailed description of the selected resources, including related resources such as events or controllers. You may select a single object by name, all objects of that type, provide a name prefix, or label selector. Source: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#describe

kubectl describe is supposed to give you more information .Even if, I agree with you, some resources have quiete the same informations with kubectl get or kubectl describe.