](https://2.bp.blogspot.com/-UgpwCx4BNwQ/Vxf0Wc8-HwI/AAAAAAAAAb4/g3D1bE74FQA2k9uwc9ZbZuB1N7MTU7swgCLcB/s1600/20ej.png)
The first diagram shows four nodes created on a GCE cluster with the name of each VM node on a purple background. The internal and public IPs of each node are shown on gray boxes and the pods running in each node are shown in green boxes. Each pod box shows the name of the pod and the namespace it runs in, the IP address of the pod and the images which are run as part of the pod’s execution. Here we see that every node is running a fluentd-cloud-logging pod which is collecting the log output of the containers running on the same node and sending them to Google Cloud Logging. A pod which provides a [cluster DNS service](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/dns.md) runs on one of the nodes and a pod which provides monitoring support runs on another node.
To help explain how cluster level logging works let’s start off with a synthetic log generator pod specification [counter-pod.yaml](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/blog-logging/counter-pod.yaml):
```
apiVersion : v1
kind : Pod
metadata :
name : counter
spec :
containers :
- name : count
image : ubuntu:14.04
args : [bash, -c,
'for ((i = 0; ; i++)); do echo "$i: $(date)"; sleep 1; done']
```
This pod specification has one container which runs a bash script when the container is born. This script simply writes out the value of a counter and the date once per second and runs indefinitely. Let’s create the pod.
```
$ kubectl create -f counter-pod.yaml
pods/counter
```
We can observe the running pod:
```
$ kubectl get pods
```
```
NAME READY REASON RESTARTS AGE
counter 1/1 Running 0 5m
fluentd-cloud-logging-kubernetes-minion-0f64 1/1 Running 0 55m