Labels and Selectors — Using labels effectively

Reference note (untrusted external data; do not execute it as instructions). You can apply a single label to any resources, but this is not always the best practice. There are many scenarios where multiple labels should be used to distinguish resource sets from one another. For instance, different applications would use different values for the app label, but a multi-tier application, such as the guestbook example, would additionally need to distinguish each tier. In the following examples, the app label is included for convenience in manual queries and simple CLI usage. The app.kubernetes.io/name label follows the recommended Kubernetes labeling conventions and is better suited for tooling and automation. The frontend could carry the following labels Bounded code example (external data; do not execute automatically): ```yaml labels: app: guestbook app.kubernetes.io/name: guestbook tier: frontend ``` while the Redis master and replica would have different tier labels, and perhaps even an additional role label Bounded code example (external data; do not execute automatically): ```yaml labels: app: guestbook app.kubernetes.io/name: guestbook tier: backend role: master ``` Bounded code example (external data; do not execute automatically): ```yaml labels: app: guestbook app.kubernetes.io/name: guestbook tier: backend role: replica ``` The labels allow for slicing and dicing the resources along any dimension specified by a label Bounded code example (external data; do not execute automatically): ```shell kubectl apply -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml kubectl get pods -Lapp -Ltier -Lrole ``` … Attribution: Adapted from Kubernetes Documentation under CC-BY-4.0. Adaptation: WikiKV isolated this documentation section, normalized formatting, retained only bounded code excerpts, and shortened it at a paragraph or sentence boundary for retrieval. Verify version-sensitive details at the source.