{"id":782,"date":"2024-03-08T01:09:00","date_gmt":"2024-03-08T01:09:00","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=782"},"modified":"2024-03-08T01:09:00","modified_gmt":"2024-03-08T01:09:00","slug":"kubernetes-objects-resources","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=782","title":{"rendered":"Kubernetes Objects Vs Resources Vs Custom Resource"},"content":{"rendered":"

In this blog you will learn about Kubernetes objects, resources, custom resources and their differences in detail.<\/p>\n

While learning Kubernetes, you will quite often come across the names “Kubernetes Object <\/strong>, “Kubernetes resources<\/strong>” and “Custom Resources<\/strong>“. These are fundamental concepts in Kubernetes that are crucial to understand<\/p>\n

Let’s understand what they really mean.<\/p>\n

What is Kubernetes Object?<\/h2>\n

In Kubernetes, anything a user creates and retains is referred to as an “Object<\/strong>.” These can include various items such as namespaces, pods<\/a>, deployments<\/a>, DaemonSet<\/a>, volumes, or secrets.<\/p>\n

If you look at the Kubernetes architecture<\/a>, the etcd component plays an important role in persisting cluster objects amongst other things. Any object you create, gets stored in etcd.<\/p>\n

etcd<\/a> stores all objects under the key named \/registry<\/code><\/strong> directory. For instance, details regarding a pod called Nginx in the default namespace can be retrieved by searching for \/registry\/pods\/default\/nginx<\/code><\/strong>. The following image shows the registry paths where different objects are stored.<\/p>\n

\"Kubernetes
Click to view in HD<\/span><\/figcaption><\/figure>\n

To create these objects, you describe what you want (desired state) in a file using either YAML or JSON. It is called a Object Specification.<\/p>\n

Here is an example of a Pod Object Specification (highlighted in bold) where we describe the desired stated of the pod.<\/p>\n

# Pod spec\napiVersion: v1\nkind: Pod\nmetadata:\n  name: webserver-pod\nspec:\n  containers:\n  - name: webserver\n    image: nginx:latest\n    ports:\n    - containerPort: 80<\/code><\/pre>\n
Once you’ve created an object, you can ask Kubernetes for information about it using Kubectl or API calls to the API server.<\/p>\n
The following table shows the important native Kubernetes object types organized in categories.<\/p>\n
<\/p>\n\n\n\n\n\n\n\n\n\n\n
Category<\/th>\nKubernetes Objects<\/th>\n<\/tr>\n<\/thead>\n
Workload<\/strong><\/td>\n1. Pods 
2. ReplicaSets 
3. Deployments 
4. StatefulSets 
5. DaemonSets 
6. Jobs 
7. CronJobs
8. Horizontal Pod Autoscaler
9. Vertical Pod Autoscaler<\/td>\n<\/tr>\n
Service & Networking<\/strong><\/td>\n1. Services 
2. Ingress 
3. IngressClasses
4. Network Policies 
5. Endpoints
6. EndpointSlices<\/td>\n<\/tr>\n
Storage<\/strong><\/td>\n1. PersistentVolumes 
2. PersistentVolumeClaims 
3. StorageClasses<\/td>\n<\/tr>\n
Configuration & Management<\/strong><\/td>\n1. ConfigMaps 
2. Namespaces 
3. ResourceQuotas 
4. LimitRanges
5. Pod Disruption Budgets (PDB)
6. Pod Priority and Preemption<\/td>\n<\/tr>\n
Security<\/strong><\/td>\n1. Secrets 
2. ServiceAccounts (sa)
3. Roles 
4. RoleBindings 
5. ClusterRoles 
6. ClusterRoleBindings<\/td>\n<\/tr>\n
Metadata<\/strong><\/td>\n1. Labels and Selectors 
2. Annotations
3. Finalizers<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
<\/p>\n
Common Object Parameters<\/h2>\n
There are many object types in Kubernetes, however, there are common parameters for every object.<\/p>\n
Following are the common set of parameters shared by Kubernetes objects<\/p>\n
<\/p>\n\n\n\n\n\n\n\n\n
Parameter<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
apiVersion<\/strong><\/td>\nThe Kubernetes API version for the object.
– Alpha
– Beta
– Stable<\/td>\n<\/tr>\n
kind<\/strong><\/td>\nThe type of object being defined 
– Pod
– Deployment
– Service
– Configmap, etc.<\/td>\n<\/tr>\n
metadata<\/strong><\/td>\nmetadata is used to uniquely identify and describe a Kubernetes object. Here are some of the common key metadata that can be added to an object
– labels 
– name 
– namespace 
– annotations
– finalizers etc<\/td>\n<\/tr>\n
spec<\/strong><\/td>\nUnder the ‘spec’ section of a Kubernetes object definition, we declare the desired state and characteristics of the object that we want to create.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
<\/p>\n
Object UID<\/h2>\n
Every object created by Kubernetes has a unique id associated with it. Universally Unique Identifier (UUID) or UID.<\/p>\n
You cant have two object with same name. Meaning, you cant have two pods with same name webserver<\/code><\/strong>. However, you can have a pod named webserver<\/code><\/strong> and a Deployment named webserver<\/code><\/strong>.<\/p>\n
You can find this UID by describing the pod. It will be present under the metadata section.<\/p>\n
\"Kubernetes
Click to view in HD<\/span><\/figcaption><\/figure>\n
If you want a non-unique identified for your object, you can use labels<\/code><\/strong> and annotations<\/code><\/strong>.<\/p>\n
What are Kubernetes Resources?<\/h2>\n
In Kubernetes, everything is accessed through APIs.<\/p>\n
To create different types of objects such as pods, namespaces, configmaps etc, Kubernetes API server provides API endpoints.<\/p>\n
These object-specific endpoints are called API resources or resources<\/strong>. For example, the API endpoint used to create a pod is referred to as a Pod resource<\/strong>.<\/p>\n
In simpler terms, a resource is a specific API URL<\/strong> used to access an object, and they can be accessed through HTTP verbs such as GET, POST, and DELETE.<\/p>\n
For instance, the \/api\/v1\/pods<\/code><\/strong> resource can be used to retrieve a list of Pod objects, and an individual Pod object can be obtained from the \/api\/v1\/namespaces\/pods\/<\/code><\/strong> resource.<\/p>\n
Here are some examples of API resource endpoints in Kubernetes:<\/p>\n
    \n
  1. \/api\/v1\/namespaces<\/code>: This API resource retrieves a list of all namespaces in the cluster.<\/li>\n
  2. \/api\/v1\/pods<\/code>: This API resource retrieves a list of all pods in the cluster.<\/li>\n
  3. \/api\/v1\/pods\/{pod-name}<\/code>: This API resource retrieves information about a specific pod, where {pod-name}<\/code> is the name of the pod.<\/li>\n
  4. \/api\/v1\/namespaces\/{namespace-name}\/pods<\/code>: This API resource retrieves a list of all pods in a specific namespace, where {namespace-name}<\/code> is the name of the namespace.<\/li>\n
  5. \/api\/v1\/namespaces\/{namespace-name}\/pods\/{pod-name}<\/code>: This API resource retrieves information about a specific pod in a specific namespace.<\/li>\n<\/ol>\n
    These endpoints are just a few examples of the many API resources available.<\/p>\n
    When creating a Kubernetes object using kubectl, the YAML specification is converted to JSON format<\/strong> and sent to the Pod resource (Pod API endpoint).<\/p>\n
    It’s important to note that the terms pods, volumes, and other similar terms are referred to as generic “resources,” not API resources, so it’s important not to confuse the two.<\/p>\n
    The following image shows how a Kubernetes object spec is send to the API servers pod API resource via kubectl to be persisted in etcd.<\/p>\n
    \"Kubernetes<\/figure>\n
    Also, when using Kubernetes RBAC, you will comes across objects concepts.<\/p>\n
    What are Kubernetes Custom Resources?<\/h2>\n
    Kubernetes comes with a native list of API resources such as pods, deployments, secrets, configmaps, and more.<\/p>\n
    For example, if you deploy a pod object, it creates a pod with specified containers.<\/p>\n
    But what if you want to create your own API resource?<\/strong><\/p>\n
    Let’s say you need a resource named “backup<\/strong>”  and if you deploy the backup object, it should  perform a etcd backup and uploads it to S3.<\/p>\n
    Luckily, Kubernetes is highly extensible<\/strong> and allows users to create their own resources and integrate them with core Kubernetes APIs. If you develop your own custom API in Kubernetes to perform a specific action, you can call it a custom resource<\/strong>.<\/p>\n
    \n
    Note<\/strong><\/b>: To create a custom resources, you need to implement a controller that handles the custom resource.<\/div>\n<\/div>\n
    Here is how a custom object specification for backup would look like. When you deploy this object, the custom controller the user developed performs the desired action at the backend.<\/p>\n
    apiVersion: devopscube.com\/v1\nkind: Backup\nmetadata:\n  name: my-backup\nspec:\n  etcdEndpoint: http:\/\/etcd:2379\n  s3Bucket: my-bucket\n  s3Region: us-west-2\n<\/code><\/pre>\n
    Kubenetes Manifests<\/h2>\n
    Normally we call Kubernetes YAML <\/a>files as manifests. It includes specifications for one or more Kubernetes objects, such as Deployments, Services, ConfigMaps,  Secrets etc.<\/p>\n
    The following image shows an example of a Kubernetes manifest file where we have a Pod and Sevice object defined. If you run this manifest it will create both the pod and service object.<\/p>\n
    \"\"<\/figure>\n
    Is there a maximum limit for the number of objects in a manifest file?<\/p>\n
    No, but there is a default size limit of 1MB. However, it is recommended to keep the number of objects per file to a manageable level for ease of maintenance and readability if you choose to use manifest files.<\/p>\n
    Conclusion<\/h2>\n
    In this blog, we looked at Kubernetes object, resources, custom resource’s and its differences. If you want to master Kubernetes, these basics are very much important.<\/p>\n
    If you are learning Kubernetes, you can checkout the 40+ comprehensive Kubernetes tutorials.<\/a><\/p>\n
    \n
    Ngu\u1ed3n:<\/strong> Kubernetes Objects Vs Resources Vs Custom Resource \u2014 DevOpsCube<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
    Source: https:\/\/devopscube.com\/kubernetes-objects-resources\/<\/p>\n","protected":false},"author":1,"featured_media":783,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-782","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/782","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=782"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/782\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/783"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=782"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=782"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=782"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}