10 Manifest in Kubernetes

Manifeste sind die Grundlage für die deklarative Verwaltung der Konfiguration in Kubernetes. Sie dienen der Festlegung des gewünschten Zustands für Ressourcen im Cluster. Die Definition dieser Konfigurationsdateien erfolgt üblicherweise im YAML-Format, wobei auch JSON unterstützt wird.

10.1 Funktionen und Einsatzbereiche

• Ressourcen-Definition: Festlegen von Parametern und Konfigurationen für die Bereitstellung von Ressourcen im Cluster.
• Deployment: Durchführung der Bereitstellung und Aktualisierung von Ressourcen mittels der im Manifest beschriebenen Konfigurationen.
• Versionskontrolle: Speicherung der Manifeste in Versionsverwaltungssystemen ermöglicht Nachverfolgung von Änderungen und Verwaltung unterschiedlicher Konfigurationsstände.
• Wiederverwendbarkeit: Manifeste können über verschiedene Umgebungen und Projekte hinweg wiederverwendet werden, um konsistente Konfigurationen zu gewährleisten.
• Automatisierung: Integration der Manifeste in CI/CD-Pipelines automatisiert den Prozess der Ressourcenbereitstellung.

Ein Kubernetes-Manifest ermöglicht die Deklaration von gewünschten Eigenschaften und Beziehungen von Clusterressourcen in einem formatierten, menschenlesbaren Textdokument. Kubernetes strebt anschließend danach, den tatsächlichen Zustand des Clusters an diesen gewünschten Zustand anzupassen.

10.2 Manifeststruktur

Jedes Kubernetes-Manifest beinhaltet die folgenden Schlüsselelemente:

• apiVersion: Gibt die Version der Kubernetes API an, die für die Ressourcenerstellung verwendet wird.
• kind: Bestimmt die Art der Ressource (z.B. Pod, Service, Deployment).
• metadata: Beinhaltet Metadaten der Ressource, wie den Namen und Namensraum.
• spec: Spezifiziert die Charakteristiken und das gewünschte Verhalten der Ressource.

Ein exemplarisches Manifest in YAML-Struktur sieht wie folgt aus:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  labels:
    purpose: demonstrate-manifest
spec:
  containers:
  - name: example-container
    image: nginx:1.14.2
    ports:
    - containerPort: 80

Dieses Format standardisiert die Cluster-Konfiguration und erleichtert sowohl die manuelle als auch maschinelle Bearbeitung.

10.3 apiVersion in Kubernetes Spec

Die apiVersion in einer Kubernetes-Spezifikation ist entscheidend, da sie die Version der Kubernetes-API angibt, mit der das Objekt erstellt wird. Diese Information ist notwendig, um die Kompatibilität zwischen den Objekten und dem Cluster zu gewährleisten.

10.3.1 Zweck der apiVersion

Die apiVersion stellt die Kompatibilität sicher und definiert, welche Version der Kubernetes-API für das Erstellen des Objekts verwendet wird.

10.3.2 Struktur der apiVersion

Die apiVersion wird in zwei Teile unterteilt: apiGroup und version.

10.3.3 Beispiele

10.3.4 Wie man die richtige apiVersion findet

Um die richtige apiVersion für eine Ressource zu finden, kann man den Befehl

kubectl api-versions

verwenden, um eine Liste aller auf dem Cluster verfügbaren API-Versionen zu erhalten

10.3.5 Neue apiVersion bei API-Änderungen

Wenn Kubernetes eine Veröffentlichung hat, die das, was für die Verwendung verfügbar ist, aktualisiert oder etwas in seiner API ändert, wird eine neue apiVersion erstellt

Die Wahl der richtigen apiVersion ist entscheidend, da sie beeinflusst, welche Eigenschaften und Methoden in den Objektspezifikationen verwendet werden können.

kubectl api-versions

acme.cert-manager.io/v1
admissionregistration.k8s.io/v1
apiextensions.k8s.io/v1
apiregistration.k8s.io/v1
apps/v1
authentication.k8s.io/v1
authorization.k8s.io/v1
.
.
.
traefik.containo.us/v1alpha1
v1

10.4 kind in Kubernetes Spec

Das Feld kind in der Spezifikation eines Kubernetes-Objekts definiert den Typ des Objekts, das erstellt oder manipuliert werden soll. Es ist eines der erforderlichen Felder in jedem Kubernetes-Manifest.

10.4.1 Zweck von kind

Das kind-Feld gibt den Typ der Ressource an, die in dem Manifest definiert ist. Es sagt Kubernetes, welche Art von Objekt Sie erstellen oder anderweitig manipulieren möchten.

10.4.2 Häufige Werte für kind

10.4.3 Beispiele

10.4.3.1 Pod

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: nginx

10.4.3.2 Service

apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376

10.4.3.3 Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mydeployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: mycontainer
        image: nginx

10.4.4 Wo wird kind verwendet

Das kind-Feld wird in allen Kubernetes-Manifesten verwendet und ist erforderlich, um den Typ des Objekts anzugeben, das erstellt oder manipuliert werden soll. Das ermöglicht es Kubernetes, die notwendige Logik anzuwenden, um die gewünschte Ressource korrekt zu behandeln.

Um alle verfügbaren kinds in einem Kubernetes-Cluster aufzulisten, können Sie den folgenden Befehl verwenden:

kubectl api-resources --verbs=list -o name

Der Befehl kubectl api-resources gibt eine Liste aller Ressourcentypen im Cluster zurück. Die Option --verbs=list filtert die Ausgabe auf Ressourcentypen, die gelistet werden können. Die Option -o name formatiert die Ausgabe, um nur die Namen der Ressourcentypen anzuzeigen.

Durch Ausführen des obigen Befehls erhalten Sie eine Liste aller Ressourcentypen, die im Cluster verfügbar sind, was Ihnen einen Hinweis auf die verschiedenen kinds gibt, die Sie in Ihren Kubernetes-Spezifikationen verwenden können.

Durch das Verständnis des kind-Feldes und seiner Verwendung können Sie effektiv mit verschiedenen Ressourcentypen in Kubernetes arbeiten und verstehen, wie Sie sie in Ihren Manifesten definieren können.

Die vollständige Auflistung der Resourcen sieht in einem k3s Cluster z.B. so aus:

kubectl api-resources --verbs=list

10.5 Metadata in Kubernetes Spec

Die metadata-Sektion in der Spezifikation eines Kubernetes-Objekts enthält Informationen, die zur Identifizierung und Organisation des Objekts verwendet werden.

10.5.1 Zweck der metadata

Die metadata-Sektion ist für die Speicherung von Informationen über die Ressource verantwortlich, wie z.B. Name, Labels, Annotations usw. Diese Informationen sind wichtig für die Erstellung, Aktualisierung und Verwaltung von Objekten in einem Kubernetes-Cluster.

10.5.2 Hauptfelder in metadata

10.5.3 Beispiele

10.5.3.1 Name

Im folgenden Beispiel wird ein Deployment mit dem Namen nginx-deployment erstellt, das im Feld .metadata.name angegeben wird:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
...

10.5.3.2 Labels

Labels können zur Klassifizierung und Auswahl von Objekten verwendet werden. Im folgenden Beispiel wird dem Deployment ein Label app: nginx zugewiesen:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
...

10.5.3.3 Annotations

Annotations können verwendet werden, um nicht identifizierende Informationen zu speichern. Sie können beliebige Daten speichern, die nützlich sind, aber nicht zur Identifizierung des Objekts verwendet werden:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  annotations:
    description: This is a sample pod.
...

10.5.4 Wo wird metadata verwendet

Die metadata-Sektion wird in vielen verschiedenen Arten von Kubernetes-Objekten verwendet, einschließlich Pods, Deployments, Services, ReplicaSets und vielen anderen. Sie ist ein kritischer Teil der Objektdefinition und wird verwendet, um das Objekt im Cluster zu identifizieren und zu organisieren.

Die metadata-Sektion in Kubernetes-Objektspezifikationen ist ein mächtiges Werkzeug zur Verwaltung und Organisation von Ressourcen im Cluster.

10.6 spec in Kubernetes Spec

Die spec-Sektion ist ein wesentlicher Bestandteil der Spezifikation eines Kubernetes-Objekts, in dem die gewünschten Zustände und Eigenschaften der Ressource definiert werden.

10.6.1 Zweck der spec

• Die spec-Sektion enthält die Konfiguration und die gewünschten Zustände für die Ressource, die Sie erstellen oder aktualisieren möchten. Die genaue Struktur und die verfügbaren Felder in der spec-Sektion können je nach Art des Objekts variieren.

10.6.2 Häufig verwendete Felder in spec

10.6.3 Beispiele

10.6.3.1 Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

10.6.3.2 Service

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

10.6.3.3 Pod

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: nginx

10.6.4 Wo wird spec verwendet

Die spec-Sektion wird in vielen verschiedenen Arten von Kubernetes-Objekten verwendet, einschließlich Pods, Deployments, Services, ReplicaSets, und vielen anderen. Sie ist ein zentraler Bestandteil der Objektdefinition und wird verwendet, um die gewünschten Zustände und Eigenschaften der Ressource anzugeben.

Die spec-Sektion ist entscheidend für die Definition des gewünschten Zustands einer Ressource in Kubernetes und bietet eine flexible und umfangreiche Konfiguration, um die Betriebsanforderungen zu erfüllen.