Learn about Kubernetes Objects

If you are following Kubernetes series, you may understand more about Kubernetes and also, we have explained some scenarios, which explains the Kubernetes adoption. As mostly we are adding additional workloads to containers, a container orchestration system is required to automate most of the features/options. In that, Kubernetes, the leading open-source container orchestration system has gained more trust from various organizations.

As per the growth, it is important to understand about Kubernetes objects. If you are just started using Kubernetes, this article may help you to understand the basics.

What Are Kubernetes Objects?

Kubernetes objects are represented in JSON or YAML files and describe the state of your cluster. The state of the cluster defines what workloads should be running in it. You can create these objects, and then Kubernetes makes sure that your desired state is maintained. For example, if you create a deployment in Kubernetes, it makes sure it’s running even if the cluster restarts after a crash. That’s the beauty of Kubernetes.

There are two categories of objects in Kubernetes, which we’ll discuss more later on:

1. basic objects: Pods, Service, Volumes, Namespace, etc., which are independent and don’t require other objects
2. high-level objects (controllers): Deployments, Replication Controllers, ReplicaSets, StatefulSets, Jobs, etc., which are built on top of the basic objects

You can get to a desired state by creating an object and pushing it to the Kubernetes API with client-side tools like kubectl.

Object Spec and Status

In Kubernetes, object representation is stored in a manifest, as discussed above. Each kind of object has two specific properties:

1. spec: This contains the details about the object. For example, for a pod, it would contain which container image it would run, the ports to expose, the labels, and more.
2. status: This contains your object’s current state and is updated in real time by the Kubernetes control plane. If you delete your pod, the status changes to Terminating, and then the pod is no longer listed as it gets deleted. The status is automatically assigned to each object.

Required Fields

Each YAML configuration for an object contains a selected set of fields for it to be valid. These fields are called required fields, and they include the following:

1. apiversion: This contains the instruction as to which version of the Kubernetes API should be used to create your object from the manifest.
2. kind: As noted above, there are two categories of objects — basic and high-level objects. This field contains the details of the type of object; for example, if you want to create a pod in your cluster, the kind would be Pod.
3. metadata: Metadata is defined as a set of data that gives information about other data. So this property defines parameters like name, UID, or namespace that would help you identify your object amid other objects of the same kind. You’ll read more about UID and namespace later in this article.
4. spec: This, as discussed above, contains your object’s specifications. For example, it would contain what container image the pod would run, as well as what ports should be available for the object pod.

The manifest below contains all the required fields for a pod object for your reference in a YAML format.

apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  containers:
  - name: demo
    image: demo/demo
    ports:
    - containerPort: 8080

Kubernetes Object Management

About we have described the objects, now let’s see how to manage it. Kubernetes objects can be managed either by imperative commands or declarative configuration. Using imperative commands with the kubectl command-line tool, you can create, update, and delete Kubernetes objects directly without needing any manifest. This is very helpful when you’re deploying specific objects like a pod.

Here’s an example of some imperative commands:

# kubectl run demo  --generator=run-pod/v1 --image=demo/demo

# kubectl create service nodeport <myservicename>

# kubectl delete pod pod-name

However, this should be used for testing or practice only, as this is not recommended for production use. In production we should use declarative way only, which will help to move towards GitOps also. Here are some examples of declarative commands:

# kubectl apply -f demo.yaml

# kubectl apply -f <directory>/

# kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml

Now let’s take a look at a few operations that you can perform with your objects.

Continue reading on Learn about Kubernetes Objects — Kubernetes Series — FoxuTech