When creating a pod in a Kubernetes cluster, we can use either an imperative or a declarative approach. We have discussed the difference of the two approaches earlier in this book, but to rephrase the important aspect, using a declarative approach signifies that we write a manifest which describes the end state we want to achieve. We leave the details of the how to the orchestrator. The end state that we want to achieve is also called the desired state. In general, the declarative approach is strongly preferred in all of the established orchestrators, and Kubernetes is no exception.
Thus, in this chapter, we will exclusively concentrate on the declarative approach. Manifests or specifications for a pod can be written using either YAML or JSON format. In this chapter, we will concentrate on YAML since it is easier to read for us humans. Let's look at a sample specification. Here is the content of the pod.yaml file that can be found in the ch12 subfolder of our labs folder:
apiVersion: v1
kind: Pod
metadata:
name: web-pod
spec:
containers:
- name: web
image: nginx:alpine
ports:
- containerPort: 80
Each specification in Kubernetes starts with the version information. Pods have been around for quite some time and thus the API version is v1. The second line specifies the type of Kubernetes object or resource we want to define. Obviously, in this case, we want to specify a pod. Next follows a block with metadata. At a bare minimum, we need to give the pod a name. Here, we call it web-pod. The next block that follows is the spec block, which contains the specification of the pod. The most important part (and the only one in this simple sample) is the list of all containers that are part of this pod. We only have one container here, but multiple containers are possible. The name we choose for our container is web and the container image is nginx:alpine. Finally, we define the list of ports the container is exposing.
Once we have authored such a specification, we can apply it to the cluster using the Kubernetes CLI kubectl. In a Terminal, navigate to the ch12 subfolder and execute the following command:
$ kubectl create -f pod.yaml
Which will respond with pod "web-pod" created. We can then list all pods in the cluster with kubectl get pods:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
web-pod 1/1 Running 0 2m
As expected, we have one of one pods in running status. The pod is called web-pod, as defined. We can get more detailed information about the running pod by using the describe command:
Please note the notation pod/web-pod in the previous describe command. Other variants are possible, for example, pods/web-pod or po/web-pod. pod and po are aliases of pods. The kubectl tool defines many aliases to make our lives a bit easier.
The describe command gives us a plethora of valuable information about the pod, not the least of which is the list of events that happened with this pod affected. The list is shown at the end of the output.
The information in the Containers section is very similar to what we find in a docker container inspect output.
We also see a Volumes section with some entry of type Secret. We will discuss Kubernetes secrets in the next chapter. Volumes, on the other hand, are discussed next.