22 Labels

Labels und Selektoren

22.0.1 Definition

Labels in Kubernetes sind Schlüssel-Wert-Paare, die an Objekte wie Pods, Services oder Deployments angehängt werden, um diese zu organisieren und auszuwählen. Sie sind entscheidend für die Konfiguration der Deployment-Strategien und ermöglichen es, komplexe Abfragen für Objektgruppen zu definieren. Mit Labels kann man spezifizieren, welche Pods von einem Service verwaltet werden oder welche Pods zu einem bestimmten Deployment gehören. Sie sind ein zentrales Konzept für die Vernetzung, Skalierung und Verwaltung in Kubernetes und bilden die Grundlage für Selektoren, mit denen man auf Teilmengen der Objekte im Cluster abzielt.

22.1 Verwendung

• Gruppierung: Ressourcen können nach Labels gruppiert und gefiltert werden.
• Selektion: Labels werden von Controllern wie ReplicaSets und Services für die Auswahl von Pods verwendet.
• Labels können bei der Erzeugung eines Objekts, oder an ein bereits bestehendes Objekt angefügt werden.

22.2 Syntax

Labels bestehen aus Schlüssel-Wert-Paaren und werden in der YAML-Datei unter dem metadata Feld definiert. Sie sind dabei frei definierbar, d.h. sie können von Benutzern angelegt werden, um Objekte nach beliebigen Kriterien zu kennzeichnen und zu organisieren.

metadata:
  labels:
    app: my-app
    stage: production

22.3 Kommandos

22.4 Vererbung

In Kubernetes wird die Vererbung von Selektoren nicht im traditionellen Sinn der “Vererbung” verwendet, wie man es aus der objektorientierten Programmierung kennt. Stattdessen können Selektoren in verschiedenen Ressourcen konfiguriert werden, um dieselben Labels zu matchen, was zu einem vererbungsähnlichen Verhalten führt, bei dem verschiedene Ressourcen dieselben Pods oder Objekte anhand ihrer Labels auswählen können.

Hier ist ein Beispiel für die Verwendung eines Selektors in einem Deployment und einem Service, der dieselben Pods anhand ihrer Labels auswählt:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myapp:1.0

In diesem Deployment wird ein Label app: myapp im Template des Pods gesetzt. Der Selektor im Deployment-Objekt verwendet dieses Label, um zu bestimmen, welche Pods verwaltet werden sollen.

Für einen Service, der diese Pods auswählen soll:

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Der Service verwendet einen Selektor, der nach Pods mit dem Label app: myapp sucht. Dieser Selektor “erbt” im übertragenen Sinn die Selektion von dem Deployment, da er dieselben Pods auswählt.

Dieses Beispiel zeigt, wie ein Label über Deployment und Service hinweg verwendet wird, um eine Gruppe von Pods zu identifizieren und zu verbinden.

22.4.1 Beispiel

Im folgenden Beispiel wird das Deployment-Objekt so konfiguriert, dass es unterschiedliche Labels für Entwicklungsumgebungen (dev) und Produktionsumgebungen (prod) aufweist, indem es den Schlüssel env für die Umgebungsangabe verwendet. Dies ermöglicht eine feinere Steuerung über die Selektoren für verschiedene Umgebungen:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment-dev
  labels:
    tier: backend
    env: dev
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
      env: dev
  template:
    metadata:
      labels:
        app: myapp
        env: dev
        version: v1
    spec:
      containers:
      - name: myapp-container
        image: myapp:dev

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment-prod
  labels:
    tier: backend
    env: prod
spec:
  replicas: 5
  selector:
    matchLabels:
      app: myapp
      env: prod
  template:
    metadata:
      labels:
        app: myapp
        env: prod
        version: v1
    spec:
      containers:
      - name: myapp-container
        image: myapp:1.0

In diesem Beispiel gibt es zwei separate Deployment-Manifeste:

• Das erste für die Entwicklungsumgebung (env: dev), das einen Container mit dem Tag myapp:dev verwendet und zwei Repliken dieses Pods bereitstellt.
• Das zweite für die Produktionsumgebung (env: prod), das einen Container mit dem Tag myapp:1.0 verwendet und fünf Repliken für eine höhere Verfügbarkeit bereitstellt.

Mit dieser Konfiguration kann man spezifische Aktionen auf Basis des env-Labels durchführen, wie z.B. das gezielte Aktualisieren von Pods in nur einer Umgebung oder das Sammeln von Metriken getrennt nach Entwicklung und Produktion.

22.5 Best Practices

• Verwenden Sie aussagekräftige Schlüssel und Werte.
• Halten Sie die Anzahl der Labels überschaubar für einfache Verwaltung.

Labels bieten eine flexible Methode zur Organisation und Verwaltung von Kubernetes-Ressourcen und spielen eine zentrale Rolle in der Pod-Auswahl und -Gruppierung.