In a Kubernetes cluster, the status of your cluster is an important piece of information. The status describes "how the cluster should look", for example which version of a container image should be used or how much resources a Pod should have. Kubernetes objects are often used to describe the desired status of a Kubernetes cluster.
A Kubernetes cluster typically uses multiple objects to describe the status of a cluster. Each object describes the configuration of a resource. The available options to describe an object can be found per resource in the Kubernetes API documentation.
Kubernetes objects (almost always) use .yaml files to pass JSON data to the Kubernetes API, for example via Kubectl. This JSON data describes:
- Which containerized applications are running, for example an Apache container and on which nodes they run.
- The resources available for these applications.
- The policies that determine how these applications behave, for example with regard to restarts, upgrades, and fault tolerance.
By creating a Kubernetes object, you tell Kubernetes what the workload of your cluster should look like, or in other words, what is the desired status of your cluster?
To create, modify, or delete Kubernetes objects, you use the Kubernetes API, which you can address with Kubectl, for example, to create a Deployment:
kubectl apply -f https://k8s.io/examples/application/deployment.yaml
Spec and status
Kubernetes objects describe an object spec and object status. The object spec is simply a description of how you want the object (for example a Deployment) to look. The object status determines how your object looks right now. For example, you can determine that your application should run three replicas. If one of those replicas fails, the object status changes. Your cluster determines that the status deviates from the spec, and Kubernetes will then spawn a new replica to ensure that the spec and status match again.
The format of a Kubernetes object
Kubernetes objects use .yaml files to pass JSON data to the Kubernetes API. Such a .yaml file must contain at least the following fields:
- apiVersion: Which version of Kubernetes are you using to create this object?
- kind: What kind of object are you creating, usually a Deployment or Pod.
- metadata: Data with which you can easily identify your object, such as the name, UID, labels, etc.
- spec: The desired status of your object. This is different for each Kubernetes object and contains layered (nested) fields specific to that object. Under 'spec', for example, you specify the technical specifications of the container, the number of replicas, etc.
An example of a .yaml file that contains the required fields of the object spec for an Nginx Kubernetes Deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2 # tells deployment to run 2 pods matching the template
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80This is an example from the official Kubernetes organisation which can be found on https://k8s.io/examples/application/deployment.yaml. As we saw earlier in this article, we can use kubectl to easily create a deployment based on this .yaml-file:
kubectl apply -f https://k8s.io/examples/application/deployment.yamlThis concludes our article on what Kubernetes objects are. Would you like to know more about the structure of a Kubernetes object and how you can create one yourself? Take a look at our tutorial 'Creating Kubernetes (yaml) objects'.