Practice Test - PODs

Take me to Practice Test

Here are the solutions to the practice test

How many pods exist on the system?
```
kubectl get pods
```
Count the number of pods (if any)
Create a new pod with the nginx image.
```
kubectl run nginx --image=nginx
```
How many pods are created now?
```
kubectl get pods
```
Count the number of pods (if any)

To get the system to tell you you can also do this
```
kubectl get pods --no-headers | wc -l
```
- --no-headers should be obvious - output only the details.
- wc is the word count program. -l tells it to count lines instead, and it will count the lines emitted by kubectl
What is the image used to create the new pods?

kubectl describe outputs lots of information. The following will describe all pods whose name starts with newpods, and then we filter with grep to get what we are looking for.
```
kubectl describe pod newpods | grep image
```
We see that all three are pulling the same image.
Which nodes are these pods placed on?
```
kubectl get pods -o wide
```
Note the node column for each of the 3 newpods pods
How many containers are part of the pod webapp?
```
kubectl describe pod webapp
```
Look under the Containers section. Note there is nginx and agentx
What images are used in the new webapp pod?

Examine the output from Q6. For each of the identified containers, look at Image:
What is the state of the container agentx in the pod webapp?
```
kubectl describe pod webapp
```
Examine the State: field for the agentx container.
Why do you think the container agentx in pod webapp is in error?

Examine the output from Q8 and look in the Events: section at the end. Look at the event that says failed to pull and unpack image ...
What does the READY column in the output of the kubectl get pods command indicate?
```
kubectl get pods
```
Look at the webapp pod which we know has two containers and one is in error. You can deduce which of the answers is correct from this.
Delete the webapp Pod.
```
kubectl delete pod webapp
```
To delete the pod without any delay and confirmation, we can add --force flag. Note that in a real production system, forcing is a last resort as it can leave behind containers that haven’t been cleaned up properly. Some may have important cleanup jobs to run when they are requested to terminate, which wouldn’t get run.

You can however use --force in the exam as it will gain you time. No exam pods rely on any of the above.
Create a new pod with the name redis and with the image redis123.
Use a pod-definition YAML file.

To create the pod definition YAML file:

--dry-run=client tells kubectl to test without actually doing anything. -o yaml says “Output what you would send to API server to the console”, which we then redirect into the named file.
```
kubectl run redis --image=redis123 --dry-run=client -o yaml > redis.yaml
```
And now use the YAML you created to deploy the pod.
```
kubectl create -f redis.yaml
```
Now change the image on this pod to redis.
Once done, the pod should be in a running state.

There are three ways this can be done!
1. Method 1
  Edit your manifest file created in last question
```
vi redis.yaml
```
  Fix the image name in the redis.yaml to redis, save and exit.
  
  Apply the edited yaml
```
kubectl apply -f redis.yaml
```
2. Method 2
  Edit the running pod directly (note not all fields can be edited this way)
```
kubectl edit pod redis
```
  This will bring the pod YAML up in vi. Edit it as per method 1. When you eixt vi the change will be immediately applied. If you make a mistake, you will be dropped back into vi
3. Method 3
  Patch the image directly. For this you need to know the name of the container in the pod, as we assign the new image to that name, as in container_image_name=new_image
```
kubectl set image pod/redis redis=redis
```