The kubectl events command lists all the events for the entire namespace. If you are interested in just a pod, you can use the following command:

kubectl describe pods

The preceding command lists all the information about all pods.

If you want information on a particular pod, you can type the following:

kubeclt describe pod/<pod-name>

You will get an output similar to the one here:

Name:               frontend-5785f8455c-2trpg
Namespace:          default
...
Node:               aks-agentpool-26533852-0/10.240.0.4
Start Time:         Sun, 10 Feb 2019 05:40:55 +0000
Labels:             app=guestbook
                    pod-template-hash=1341940117
                    tier=frontend
Annotations:        <none>
Status:             Running
IP:                 10.244.0.87
Controlled By:      ReplicaSet/frontend-5785f8455c
Containers:
  php-redis:
...
    Image:          gcr.io/google-samples/gb-frontend:v3
    ...
    Port:           80/TCP
    Host Port:      0/TCP
...
    Environment:
      GET_HOSTS_FROM:                dns
    
Events:
  Type    Reason     Age   From                               Message
  ----    ------     ----  ----                               -------
  Normal  Scheduled  26m   default-scheduler                  Successfully assigned default/frontend-5785f8455c-2trpg to aks-agentpool-26533852-0
  Normal  Pulled     26m   kubelet, aks-agentpool-26533852-0  Container image "gcr.io/google-samples/gb-frontend:v3" already present on machine
  Normal  Created    26m   kubelet, aks-agentpool-26533852-0  Created container
  Normal  Started    26m   kubelet, aks-agentpool-26533852-0  Started container

From the description, you can get the node on which the pod is running, how long it was running, its internal IP address, docker image name, ports exposed, env variables, and the events (within the past hour).

In the preceding example, the pod name is frontend-5785f8455c-2trpg. Note that it has the <replicaset name>-<random 5 chars> format. The replicaset name itself is randomly generated from the deployment name frontend.

The namespace under which the pod runs is default. So far we have been just using the default namespace, appropriately named default. In the next chapters, we will see how namespaces help us to isolate pods.

The next section that is important from the preceding output is the node section.

Node: aks-agentpool-26533852-0/10.240.0.4

The node section lets us know which physical node/VM that the pod is actually running on. If the pod is repeatedly starting or having issues running and everything else seems OK, there might be an issue with the node. Having this information is essential to perform advanced debugging.

The following is the time the pod was initially scheduled:

Start Time: Sun, 10 Feb 2019 05:40:55 +0000

It doesn't mean that the pod has been running from that time. So, the time can be misleading in that sense. The actual uptime of the pod would be dependent on whether it was moved from a node to another, or the node it was on went down.

Connections between resources are made using Labels as shown here:

Labels:            app=guestbook
                    pod-template-hash=1341940117
                    tier=frontend

This is how connections such as Service->Deployment->ReplicaSet->Pod are made. If you see that traffic is not being routed to a pod from a service, this is the first thing you should check. If the labels don't match, the resources won't attach.

The following shows the internal IP of the pod and its status:

Status:         Running
IP:                 10.244.0.87

When a service directs its traffic or another container wants to talk to the containers in this pod, this is the IP that they will see. This IP is very useful when resolving application issues. Let's say you want to know why the frontend is not able to reach the server, you could find the server pod IP and try pinging it from the frontend container.

The containers running in the pod and the ports that are exposed are listed in the following block:

Containers:
  php-redis:
...
    Image:          gcr.io/google-samples/gb-frontend:v3
    ...
    Port:           80/TCP
    Host Port:      0/TCP
...
    Environment:
      GET_HOSTS_FROM:                dns

In this case, we are getting the gb-frontend container with the v3 tag from the gcr.io container registry, and the repository name is google-samples.

Port 80 is exposed for outside traffic. Since each pod has its own IP, the same port can be exposed for multiple containers of the same pod running even on the same host. This is a huge management advantage as we don't have to worry about port collisions. The port that needs to be configured is also fixed so that scripts can be written simply without the logic of figuring out which port actually got allocated for the pod.

Any events that occurred in the previous hour show up here:

Events: