In Kubernetes, a Pod is the smallest deployable unit of computing that can be created and managed.

In this lab, you will define and deploy your first Kubernetes Pod using the application you built in the Docker labs.

To begin, create a dedicated directory for this lab and switch into it:

cd ~

mkdir random-facts-app-pod && cd random-facts-app-pod

Create a Namespace manifest for your application with the following contents:

apiVersion: v1
kind: Namespace
metadata:
  name: random-facts-app-pod
  labels:
    lab: random-facts-app-pod

Use the kubectl apply command to create your namespace, passing in the filename you used to above to store your Namespace manifest:

kubectl apply -f <YOUR_NAMESPACE_MANIFEST_FILE_NAME>.yaml

Note: -f is a shortcut for --filename. This tells kubectl to attempt to apply any YAML found in the filename(s) provided.

Create the Pod manifest for the application with the following contents:

apiVersion: v1
kind: Pod
metadata:
  name: random-facts-app
  namespace: random-facts-app-pod
  labels:
    lab: random-facts-app
spec:
  containers:
  - name: random-facts-app
    image: us-central1-docker.pkg.dev/<YOUR_PROJECT_ID>/<YOUR_REGISTRY_NAME>/random-facts-app:1.0
    ports:
    - containerPort: 5000

Use the kubectl apply command again to deploy your Pod.

Once deployed, you can view the status of your Pod with the following command:

kubectl get pods --namespace random-facts-app-pod

You will see an output similar to the following:

NAME               READY   STATUS    RESTARTS   AGE
random-facts-app   1/1     Running   0          15s

Pod Details #

In some cases, it may be beneficial to view more than the single-line view of your pod. Kubernetes keeps a large record of information for each object that exists in the cluster. This can be viewed with the kubectl describe command.

Run the kubectl describe command to view the logs of your pod.

In the output, you will see information such as IP address, information about containers running inside the pods, events, etc.

Pod Logs #

If you ever need to debug your pod, it is helpful to view the logs to further understand what is going wrong. This can be viewed with the kubectl logs command.

Run the kubectl logs command to view the logs of your pod.

This will dump pod logs that have come from stdout. In some cases, it may be helpful to stream the logs. See if you can figure out how to stream logs from your pod.

Health Checks #

Kubernetes has a built-in process health check for all containers that are deployed by validating that the main process is running. If the main process fails for whatever reason, Kubernetes will restart the pod.

In most cases, this simple process check is not enough and you will want to introduce more rich health checks for your applications.

Liveness Probes #

Liveness probes further extend health checking by providing application-specific validation tests. In the Docker lab, the application defined a dedicated health endpoint at /healthz which we will use for health checks.

To add a liveness probe to your existing pod, add the following snippet to your Pod manifest under the containers field:

    livenessProbe:
      httpGet:
        path: /health
        port: 5000
      initialDelaySeconds: 10 # wait 5 seconds before starting to test
      periodSeconds: 5 # execute probe every 5 seconds after initial delay
      failureThreshold: 1  # mark the application as failed if test fails 2 times

This probe is an HTTP probe. It is responsible for sending constant HTTP requests to the path specified. In the event it gets subsequent failures defined by the failureThreshold, the pod will be marked unhealthy and will be terminated and recreated.

Once you add the liveness probe to your Pod manifest, delete your current Pod and then redeploy it.

Leveraging watch, check the status of your Pod:

watch kubectl get pods --namespace random-facts-app-pod

Eventually, you will the pod restarting as shown below:

NAME               READY   STATUS    RESTARTS     AGE
random-facts-app   1/1     Running   1 (6s ago)   17s

Determine the root cause of the issue to get your Pod back to a healthy state.

Readiness Probes #

Readiness probes allow you to define when a Pod is ready to serve traffic. If a pod fails a readiness check, it is removed from service load balancers.

To add a readiness probe to your existing pod, add the following snippet to your Pod manifest under the containers field:

    readinessProbe:
      httpGet:
        path: /health
        port: 5000
      initialDelaySeconds: 5 # wait 5 seconds before starting to test
      periodSeconds: 5 # execute probe every 5 seconds after initial delay
      failureThreshold: 2 # mark the application as failed if test fails 2 times

Once you add the readiness probe to your Pod manifest, delete your current Pod and then redeploy it.

Once you validate your pod is healthy, you can move onto the next part of the lab.

Resource Management #

Kubernetes allows you to specify two different resource metrics, requests and limits. A request specifies the minimum amount of resource that is required to run the pod. A limit specifies the maximum amount of resource that the pod is allowed to consume.

Modify your Pod manifest under the containers field to guarantee that the pod is deployed on a Kubernetes node with at least half a CPU free and gets 256 MB of memory allocated to it:

    resources:
      requests:
        cpu: 500m
        memory: 256Mi

Once you add the resources to your Pod manifest, delete your current Pod and then redeploy it.

Validate one last time that the pod is in a running state to complete the lab.