Kubernetes objects are exactly that: they are logical persistent objects or abstractions that will represent the state of your cluster. You are the one in charge of telling Kubernetes what your desired state of that object is so that it can work to maintain it and make sure that the object exists.
To create an object, there are two things that it needs to have: a status and its spec. The status is provided by Kubernetes, and it is the current state of the object. Kubernetes will manage and update that status as needed to be in accordance to your desired state. The spec field, on the other hand, is what you provide to Kubernetes, and is what you tell it to describe the object you desire, for example, the image that you want the container to be running, the number of containers of that image that you want to run, and so on. Each object has specific spec fields for the type of task that they perform, and you will be providing these specifications on a YAML file that is sent to the kube-apiserver with kubectl, which that transforms it into JSON and sends it as an API request. We will dive deeper into each object and its spec fields later in this chapter.
Here is an example of a YAML that was sent to kubectl:
cat << EOF | kubectl create -f -
kind: Service
apiVersion: v1
metadata:
Name: frontend-service
spec:
selector:
web: frontend
ports:
- protocol: TCP
port: 80
targetPort: 9256
EOF
The basic fields of the object definition are the very first ones, and these ones will not vary from object to object and are very self-explanatory. Let's take a quick look at them:
- kind: The kind field tells Kubernetes what type of object you are defining: a pod, a service, a deployment, and so on
- apiVersion: Because Kubernetes supports multiple API versions, we need to specify a REST API path that we want to send our definition to
- metadata: This is a nested field, which means that you have several more subfields to metadata, where you will write basic definitions such as the name of your object, assigning it to a specific namespace, and also tag a label to it to relate your object to other Kubernetes objects
So, we have now been through the most-used fields and their contents; you can learn more about the Kuberntes API conventions at the following GitHub page:
https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md.
Some of the fields of the object can later be modified after the object has been created, but that will depend on the object and the field that you want to modify.
The following is a short list of the various Kubernetes objects that you can create:
- Pod
- Volume
- Service
- Deployment
- Ingress
- Secret
- ConfigMap
And there are many more.
Let's take a closer look at each one of these items.