What is the difference between Objects and Resouces in Kubernetes world?
I couldn't find it from https://kubernetes.io/docs/concepts/ . I wonder they make no distinction about them but seems they see objects as a high-level concept of resources.
I also found API Convention of Kubernetes. https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#types-kinds
A representation of a specific group+version+kind is an object. For example, a v1 Pod, or an apps/v1 Deployment. Those definitions can exist in manifest files, or be obtained from the apiserver.
A specific URL used to obtain the object is a resource. For example, a list of v1 Pod objects can be obtained from the /api/v1/pods resource. A specific v1 Pod object can be obtained from the /api/v1/namespaces/<namespace-name>/pods/<pod-name> resource.
API discovery documents (like the one published at /api/v1) can be used to determine the resources that correspond to each object type.
Often, the same object can be retrieved from and submitted to multiple resources. For example, v1 Pod objects can be submitted to the following resource URLs:
/api/v1/namespaces/<namespace-name>/pods/<pod-name>/api/v1/namespaces/<namespace-name>/pods/<pod-name>/statusDistinct resources allow for different server-side behavior and access control. The first URL only allows updating parts of the pod spec and metadata. The second URL only allows updating the pod status, and access is typically only given to kubelets.
Authorization rules are based on the resources for particular requests.
Kubernetes Objects - are something like order in the restaurant. You define a state of the cluster you want to get finally, just like an order to a waiter. kubectl defines your order and delivers it to a cook, just like a waiter. And the API Server prepares your order just like a cook. You define objects in .yaml or .json files.
So, resources are something like menu items. Imagine the Pod is a meat. Meat could be cooked different ways: fried or boiled, for example, but finally it will be a meat in both cases. The similar with the Kubernetes resources. StatefulSet will create Pods with fixed names from 0 to N, while Deployment won't. DaemonSet will create Pods on the each of you nodes, while Deployment or StatefulSet will create as many Pods, as you point in replicas. But finally it will be the Pods, no matter what you chose. You might want to order fried meat, but medium-rare with mustard. What the restaurant will do with your order if it was not in item list? You are Welcome to Kubernetes CRD or CustomResourceDefinition.
P.S: it's a very abstract description and actually StatefulSet/DaemonSets/Deployments or Ingress are also the objects, but they are often referred to as the "resources"
As we tried to explain in our blog post, resources are representations of a system entity sent or retrieved as JSON via HTTP and objects are the respective in-memory Golang structs along with functions and methods defined on them.
Note that, in general and informally we're using the terms resources and objects interchangeably and that's totally fine. Unless you're a Go developer, extending Kubernetes, you probably don't need to bother at all.