Objects, Resources and Controllers in Kubernetes

Question

I recently started learning kubernetes. Many blog posts use the terms objects and resources kind of interchangably(I cannot make out the difference from the context).

Also, the controllers are described to manage some specific object(e.g. responding to create/delete/update events corresponding to that object). So, are the controllers just another object intended to manage some other object or a completely different construct?

Any Explanation is appreciated. Thanks :)

Answer 1

I agree that many people using object and resources interchangeably.

Kubernetes Resources

If you are talking about Kubernetes resources you are talking about general collection of everything you can use/create inside Kubernetes (Services, Pods, Deployments, events, quotas, etc). You can type in your cluster to check list of resources using in Kubernetes:

$ kubectl api-resources
NAME                              SHORTNAMES   APIGROUP                       NAMESPACED   KIND
bindings                                                                      true         Binding
componentstatuses                 cs                                          false        ComponentStatus
configmaps                        cm                                          true         ConfigMap
endpoints                         ep                                          true         Endpoints
events                            ev                                          true         Event
limitranges                       limits                                      true         LimitRange
namespaces                        ns                                          false        Namespace
nodes                             no                                          false        Node
persistentvolumeclaims            pvc                                         true         PersistentVolumeClaim
...

and much more, but there is no point to post them all.

Each Kubernetes object need proper specification. More details can be found here.

This specification is usualy created in YAML or JSON format. Kubernetes object must have sepcified apiVersion, Kind, metadata and spec. You should also keep in mind that YAML and JSON have their own Syntax. If all requirements are met, Kubernetes will create object.

Kubernetes Object is Kubernetes resource but with special spec and status. Please check this docs

Every Kubernetes object includes two nested object fields that govern the object’s configuration: the object spec and the object status. The spec, which you must provide, describes your desired state for the object–the characteristics that you want the object to have. The status describes the actual state of the object, and is supplied and updated by the Kubernetes system. At any given time, the Kubernetes Control Plane actively manages an object’s actual state to match the desired state you supplied.

If you will have for example 3 deployments.

$ kubectl get deploy
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
httpd        1/1     1            1           114s
nginx-test   1/1     1            1           90s
ngxin        1/1     1            1           3m46s

nginx is an one object as it have defined object spec and object status. nginx-test is also object but with different spec and status. It will be more visible if you will check deployment in yaml format.

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: "2020-01-28T15:21:18Z"
  generation: 1
  labels:
    run: ngxin
  name: ngxin
  namespace: default
  resourceVersion: "11169617"
  selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/ngxin
  uid: d51d4dd8-41e1-11ea-bfb3-42010aa40078
spec:                                                    ########### Here you have spec of this deployment - first requirement
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      run: ngxin
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        run: ngxin
    spec:                                                 #### this is container spec, its specific for deployment 
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: ngxin
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:                                                      ########### Status of deployment - second requirement
  availableReplicas: 1
  conditions:
  - lastTransitionTime: "2020-01-28T15:21:20Z"
    lastUpdateTime: "2020-01-28T15:21:20Z"
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  - lastTransitionTime: "2020-01-28T15:21:18Z"
    lastUpdateTime: "2020-01-28T15:21:20Z"
    message: ReplicaSet "ngxin-6b9746db7f" has successfully progressed.
    reason: NewReplicaSetAvailable
    status: "True"
    type: Progressing
  observedGeneration: 1
  readyReplicas: 1
  replicas: 1
  updatedReplicas: 1

In short, Kubernetes resource is collection of everything that can be created/use in Cluster. Kubernetes object is Kubernetes resource but with special specification and status which allows to determine/distinguish from other resources.

Kubernetes controller

As per docs

In Kubernetes, controllers are control loops that watch the state of your cluster, then make or request changes where needed. Each controller tries to move the current cluster state closer to the desired state.

As you mentioned, controllers monitoring specific resource. For example form this artice.

Deployment Controller

A deployment defines a desired state for logical group of pods and replica sets. It creates new resources or replaces the existing resources, if necessary. A deployment can be updated, rolled out, or rolled back. A practical use case for a deployment is to bring up a replica set and pods, then update the deployment to re-create the pods (for example, to use a new image). Later, the deployment can be rolled back to an earlier revision if the current deployment is not stable.

Hope it will help.