There are no big problems, there are just a lot of little problems.
In the previous chapter we covered containers in some detail, and explained how containers are composed to form Pods. There are a few other interesting aspects of Pods, which we’ll turn to in this chapter, including labels, guiding Pod scheduling using node affinities, barring Pods from running on certain nodes with taints and tolerations, keeping Pods together or apart using Pod affinities, and orchestrating applications using Pod controllers such as DaemonSets and StatefulSets.
We’ll also cover some advanced networking options including Ingress resources, Istio, and Envoy.
You know that Pods (and other Kubernetes resources) can have labels attached to them, and that these play an important role in connecting related resources (for example, sending requests from a Service to the appropriate backends). Let’s take a closer look at labels and selectors in this section.
Labels are key/value pairs that are attached to objects, such as pods. Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system.
The Kubernetes documentation
In other words, labels exist to tag resources with information that’s meaningful to us, but they don’t mean anything to Kubernetes. For example, it’s common to label Pods with the application they belong to: