eG Monitoring
 

Measures reported by KuberServiceTest

In Kubernetes, a Service is an abstraction which defines a logical set of Pods and a policy by which to access them (sometimes this pattern is called a micro-service). Services enable a loose coupling between dependent Pods.

A Service is required because, Pods are mortal - they are born, and they die. In a deployment therefore, the set of Pods running in one moment in time could be different from the set of Pods running that application a moment later. This leads to a problem: if some set of Pods (call them “backends”) provides functionality to other Pods (call them “frontends”) inside your cluster, how do the frontends find out and keep track of which IP address to connect to, so that the frontend can use the backend part of the workload? This is where Services help! By associating a Service with a set of dependent pods, you can make sure that Kubernetes automatically reconciles changes among pods so that your applications continue to function.

A Service is defined using YAML (preferred) or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a LabelSelector.

Although each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service. In fact, using Services, you can allow your applications to receive traffic from outside the cluster. By default however, a Service is accessible from within the cluster only. You can override this default setting using the ServiceType specification in the service definition. With the help of this specification, you can indicate where the Service should be exposed and what type of traffic (internal or external) it can receive. This means that if a Service is not up and running, then, depending upon the ServiceType, the unavailability of the Service can deny external users access to the application and can even hamper internal application operations. To assure users of continued access to their applications running in the Kubernetes cluster and to ensure peak application performance at all times, administrators should not only be able to promptly detect the non-availability of a Service, but should also be able to rapidly tell what type of Service it is and why it is not up. This is where the Services by Namespace test helps!

This test auto-discovers the Services defined within each namespace, and reports the current state, type, and age of each Service. This way, the test promptly alerts administrators if any Service is not up and running. Detailed diagnostics of the test also reveal the reason why the Service is so. Additionally, the test also reports the number and names of Pods that each Service targets and the LabelSelector used by each Service to identify the Pods. These details help in troubleshooting the abnormal state of a Service.

Outputs of the test: One set of results for each Service in every namespace configured in the Kubernetes cluster being monitored.

First-level Descriptor: Namespace

Second-level Descriptor: Service

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
Status Indicates whether/not the desired state of this deployment is the same as its actual state.   The values that this measure reports and their corresponding numeric values are detailed in the table below:

Numeric Value Measure Value
1 ClusterIP
2 NodePort
3 ExternalName
4 LoadBalancer

Each of these types have been briefly described below:

  • ClusterIP: Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.

  • NodePort: Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using :. Superset of ClusterIP.

  • ExternalName: Exposes the Service using an arbitrary name (specified by externalName in the spec) by returning a CNAME record with the name. No proxy is used. This type requires v1.7 or higher of kube-dns.

  • LoadBalancer: Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.

Note:

By default, this measure reports the Measure Values discussed above to indicate the Service type. In the graph of this measure however, the type is indicated using the numeric equivalents only.
Service_age Indicates how old this Service is.   The value of this measure is expressed in number of days, hours, and minutes.

You can use the detailed diagnosis of this measure to know the Cluster IP on which the Service has been exposed, the LabelSelector using which the Service identifies the Pods, and the internal and external endpoints associated with the Service.
Total_pod Indicates the number of pods that this Service targets. Number Use the detailed diagnosis of this measure to know which Pods are targeted by the Service and which Node each Pod is running on.
Service_state Indicates the current status of this Service.   The values that this measure reports and their corresponding numeric values are detailed in the table below:

Numeric Value Measure Value
1 Running
0 Pending

If the value of this measure is Pending, then you can use the detailed diagnosis of this measure to understand why the Service is in a Pending state.

Note:

By default, this measure reports the Measure Values discussed above to indicate the Service status. In the graph of this measure however, the status is indicated using the numeric equivalents only.