Services running on the master

Let's dig a little bit deeper into our new cluster and its core services. By default, machines are named with the kubernetes- prefix. We can modify this using $KUBE_GCE_INSTANCE_PREFIX before a cluster is spun up. For the cluster we just started, the master should be named kubernetes-master. We can use the gcloud command-line utility to SSH into the machine. The following command will start an SSH session with the master node. Be sure to substitute your project ID and zone to match your environment. Also, note that you can launch SSH from the Google Cloud console using the following syntax:

$ gcloud compute ssh --zone "<your gce zone>" "kubernetes-master"

Once we are logged in, we should get a standard shell prompt. Let's run the docker command that filters for Image and Status:

$ sudo docker ps --format 'table {{.Image}}t{{.Status}}' 

Even though we have not deployed any applications on Kubernetes yet, we note that there are several containers already running. The following is a brief description of each container:

• fluentd-gcp: This container collects and sends the cluster logs file to the Google Cloud Logging service.
• node-problem-detector: This container is a daemon that runs on every node and currently detects issues at the hardware and kernel layer.
• rescheduler: This is another add-on container that makes sure critical components are always running. In cases of low resources availability, it may even remove less critical pods to make room.
• glbc: This is another Kubernetes add-on container that provides Google Cloud Layer 7 load balancing using the new Ingress capability.
• kube-addon-manager: This component is core to the extension of Kubernetes through various add-ons. It also periodically applies any changes to  the /etc/kubernetes/addons directory.
• etcd-empty-dir-cleanup: A utility to cleanup empty keys in etcd.
• kube-controller-manager: This is a controller manager that controls a variety of cluster functions, ensuring accurate and up-to-date replication is one of its vital roles. Additionally, it monitors, manages, and discovers new nodes. Finally, it manages and updates service endpoints.
• kube-apiserver: This container runs the API server. As we explored in the Swagger interface, this RESTful API allows us to create, query, update, and remove various components of our Kubernetes cluster.
• kube-scheduler: This scheduler takes unscheduled pods and binds them to nodes based on the current scheduling algorithm.
• etcd: This runs the etcd software built by CoreOS, and it is a distributed and consistent key-value store. This is where the Kubernetes cluster state is stored, updated, and retrieved by various components of K8s.
• pause: This container is often referred to as the pod infrastructure container and is used to set up and hold the networking namespace and resource limits for each pod.

To exit the SSH session, simply type exit at the prompt.