'kubectl: describe vs get -o <format>
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?
Solution 1:[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 bykubectl 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.
Solution 2:[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
Solution 3:[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.
Solution 4:[4]
You can get the summary of a specific resource using:
- kubectl get < resource > < name >
While you can get detailed information with:
- kubectl describe < resource > < name >
Solution 5:[5]
One important difference need to mention: describe
accepts the prefix but get
need the exactly name.
$ kubectl describe TYPE NAME_PREFIX
$ kubectl get TYPE NAME
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
Solution | Source |
---|---|
Solution 1 | |
Solution 2 | Eyal Levin |
Solution 3 | DavidPi |
Solution 4 | Integrator_7 |
Solution 5 | hao |