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.
Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe: What containerized applications are running (and on which nodes)
In the Kubernetes world, there are two types of resources: Compute resources, such as CPU (units) and memory (bytes), which can be measured. API resources, such as pods, services, etc., which are simply K8s objects.
A Kubernetes cluster has two main components—the control plane and data plane, machines used as compute resources. The control plane hosts the components used to manage the Kubernetes cluster. Worker nodes can be virtual machines (VMs) or physical machines. A node hosts pods, which run one or more containers.
These fields are called required fields, and they include the following: apiversion: This contains the instruction as to which version of the Kubernetes API should be used to create your object from the manifest. kind: As noted above, there are two categories of objects—basic and high-level objects.
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>/status
Distinct 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"
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With