level. However, if you still need a way to indicate that some independent services belong to an application,  labels  can be used. Let’s imagine that we have split one mon‐ olithic application into three microservices, and another application into two micro‐ services. We now have five Pod definitions (and maybe many more Pod instances) that are independent of the development and runtime points of view. However, we may still need to indicate that the first three Pods represent an application and the other two Pods represent another application. Even the Pods may be independent, to provide a business value, but they may depend on each other. For example, one Pod may con‐ tain the containers responsible for the frontend, and the other two Pods are responsi‐ ble for providing the backend functionality. If either of these Pods is down, the application is useless from a business point of view. Using label selectors gives us the ability to query and identify a set of Pods and manage it as one logical unit. Figure 1-3 shows how you can use labels to group the parts of a distributed applica‐ tion into specific subsystems. Figure 1-3. Labels used as an application identity for Pods Here are a few examples where labels can be useful: • Labels are used by the ReplicaSets to keep some instances of a specific Pod run‐ ning. That means every Pod definition needs to have a unique combination of labels used for scheduling. • Labels are also used heavily by the scheduler. The scheduler uses labels for co- locating or spreading Pods to place Pods on the nodes that satisfy the Pods’ requirements. 8  |  Chapter 1: Introduction