As organizations move more workloads to containers, a container orchestration system is required to enable automation. Kubernetes has received widespread adoption from both small and large organizations across a wide range of industries.
In this blog, we'll look at how Kubernetes objects are represented in the Kubernetes API and how to express them in yaml format.
Kubernetes objects describe the state of your cluster and are represented in JSON or YAML files. Specifically, they can describe:
- What containerized applications are being used? (and on which nodes)
- The resources available to those applications
- Policies governing how those applications should behave, such as restart policies, upgrades, and fault-tolerance
You can create these objects, and Kubernetes will ensure that they remain in the desired state. For example, when you create a deployment in Kubernetes, it ensures that it continues to run even if the cluster restarts after a crash. That is the beauty of Kubernetes.
There are two categories of objects in Kubernetes
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 must use Kubernetes API to work with Kubernetes objects. When you use the kubectl command-line interface, for example, the CLI handles all of the necessary Kubernetes API calls. You can also directly use the Kubernetes API in your own programs by using one of the Client Librarie.
Object Spec and Status
Almost every Kubernetes object has two nested object fields that govern the configuration of the object:
1. Spec -
This section contains information about the object. For example, for a pod, it would include which container image it would run, the ports to expose, labels, and other information.
2. Status -
This contains the current state of your object and is updated in real time by the Kubernetes control plane. When you delete a pod, the status changes to Terminating, and the pod is removed from the list. Each object is automatically assigned a status.
Required Fields
Each YAML configuration for an object must include a specific set of fields in order to be valid. These are referred to as required fields, and they include the following:
1. apiversion - This specifies which version of the Kubernetes API should be used to generate your object from the manifest.
2. kind - As previously stated, there are two types of objects: basic and high-level objects. This field contains information about the object's type; for example, if you want to create a pod in your cluster, the kind would be Pod.
3. Metadata - Metadata is defined as a collection of data that provides information about other data. As a result, this property defines parameters such as name, UID, or namespace that will assist you in identifying your object among other objects of the same kind.
4. spec - As previously stated, this contains the specifications for your object. For example, it would specify which container image the pod would use and which ports the object pod should have access to.
The manifest below contains all of the required fields for a pod object in YAML format -
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx:1.10.2
ports:
- containerPort: 80
Objects in Kubernetes can be managed using either imperative commands or declarative configuration. You can create, update, and destroy Kubernetes objects without using a manifest by using imperative commands with the kubectl command-line tool. This is extremely useful when deploying specific objects, such as a pod. eg.
kubectl delete pod
However, if you need to deploy infrastructure, this method is ineffective because you will need to deploy many objects with numerous commands. In that case, you'd want to create manifests containing the specifications of your objects, and kubectl would deploy them all at once to your cluster. eg.
kubectl apply -f devapp.yaml
Now consider some of the operations you can perform on your objects:
1. Create Objects -
Kubernetes objects, regardless of type, can be created using the following basic syntax -
kubectl apply -f object.yaml
Where -f stands for “file name,” and apply applies the configuration stated in your object.yaml to your cluster.
2. Edit Objects -
To Edit the objects, below syntax can be used
kubectl edit <resource-name> <obj-name>
This command will open the object's raw configuration in YAML format from the Kubernetes API and launch your $EDITOR on the file. When you save changes to your object configuration, you will get a new desired state. For example, you can change the number of replicas in a deployment without having to re-deploy the manifest.
3. Update Objects -
To update the objects from your manifest, you can use the following replace command with kubectl -
kubectl replace -f updatedObject.yaml
4. Delete Objects -
Object deletion is very similar to object editing.
kubectl delete <resource-name> <obj-name>
Object Names and IDs
Kubernetes objects must follow a nomenclature and should not be duplicated within a namespace. You don't want anything deleted that you didn't want deleted. Each object has two unique specifiers:
1. Name - This is the one-of-a-kind name for your object, and it has some constraints.
2. UID - A UID is a unique, system-generated string that is standardized as SO/IEC 9834-8 and ITU-T X.667 for the lifetime of the cluster. It aids in the differentiation of historical occurrences of similar entities and simplifies logs. UIDs are more reliable than names because there may have been an object with the same name in the cluster's history, but the UIDs would be distinct.
You can read more about it here.
Objects are fundamental units in your cluster, and understanding them will come in handy frequently. Now that you've learned about them you can understand the significance of Kubernetes objects.
I hope you find this useful.
Thank you for reading!
*** Explore | Share | Grow ***
Comments