12 Kubernetes Pod: Eine grundlegende Einheit

Ein Pod in Kubernetes repräsentiert die kleinste “deployable” Einheit innerhalb eines Clusters und ist ein zentraler Baustein, um Anwendungen auf der Plattform zu betreiben. Jeder Pod kann einen oder mehrere Container hosten, die zusammen als eine Einheit orchestriert werden. Hier sind die Kernkonzepte und Funktionen von Pods in Kubernetes:

Lifecycle

12.0.1 Beispiel

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80
    volumeMounts:
    - name: nginx-storage
      mountPath: /usr/share/nginx/html
  volumes:
  - name: nginx-storage
    persistentVolumeClaim:
      claimName: nginx-pvc
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nginx-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

In diesem Beispiel-Manifest wird ein Pod erstellt, der einen Container hostet, welcher das neueste nginx-Image verwendet. Der Container öffnet Port 80 und montiert ein Persistent Volume an /usr/share/nginx/html. Ein PersistentVolumeClaim namens nginx-pvc wird ebenfalls erstellt, um eine dauerhafte Speicheranforderung von 1 GiB zu stellen.

12.0.2 Anmerkung

Ein gründliches Verständnis von Pods und ihrer Funktionsweise ist entscheidend für die effektive Nutzung von Kubernetes für die Orchestrierung von Container-basierten Anwendungen. Pods bilden die Grundlage für die Erstellung, Verwaltung und Skalierung von Anwendungen in einer Kubernetes-Umgebung.

12.1 kubectl Befehle für Pod-Management in Kubernetes

Pod Aktionen und entsprechende kubectl Befehle:

Aktion Kommando Beispiel
Pod erstellen kubectl apply -f pod.yaml kubectl apply -f pod.yaml
Pod auflisten kubectl get pods kubectl get pods
Pod-Details kubectl describe pod <pod-name> kubectl describe pod mypod
Pod löschen kubectl delete pod <pod-name> kubectl delete pod mypod
Pod-Logs anzeigen kubectl logs <pod-name> kubectl logs mypod
Pods in Namespace kubectl get pods --namespace=<name> kubectl get pods --namespace=development
Interaktive Shell kubectl exec -it <pod-name> -- /bin/sh kubectl exec -it mypod -- /bin/sh
Label hinzufügen kubectl label pods <pod-name> key=value kubectl label pods mypod environment=production

Erweiterte Pod-Management Befehle:

Aktion Kommando
Pod mit run kubectl run <pod-name> --image=<image>
Pod-Informationen kubectl get pods <pod-name> -o wide
Pod bearbeiten kubectl edit pods <pod-name>
Pod löschen (Datei) kubectl delete -f [fileName].yaml
Ressourcenverbrauch kubectl top pods --sort-by cpu

12.2 command

In einer Kubernetes-Pod-Spezifikation werden ENTRYPOINT und CMD aus einem Dockerfile

# Verwenden eines Basisimages
FROM ubuntu:latest

# Setzen des Arbeitsverzeichnisses im Container
WORKDIR /app

# Kopieren des Start-Skripts in das Arbeitsverzeichnis
COPY start.sh /app/start.sh

# Bereitstellen des Start-Skripts als ausführbare Datei
RUN chmod +x /app/start.sh

# Setzen des ENTRYPOINT auf das Start-Skript
ENTRYPOINT ["/app/start.sh"]

# Definieren des default CMD
CMD ["-a", "option1"]

wie folgt übersetzt

12.3 ENTRYPOINT

ENTRYPOINT wird durch das Feld command in der Pod-Spezifikation ersetzt.

Beispiel in Kubernetes YAML:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    command: ["/app/start.sh"]

12.4 CMD

CMD wird durch das Feld args in der Pod-Spezifikation ersetzt.

Beispiel in Kubernetes YAML:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    args: ["-a", "option1"]

12.5 Kombination von command und args

Wenn sowohl command als auch args in der Kubernetes-Pod-Spezifikation definiert sind, werden sie zusammen verwendet, ähnlich wie ENTRYPOINT und CMD in einem Dockerfile.

Beispiel in Kubernetes YAML:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    command: ["/app/start.sh"]
    args: ["-a", "option1"]

In diesem Fall wird der Container mit dem Befehl /app/start.sh -a option1 gestartet.

args kann in der Kubernetes-Pod-Spezifikation als Liste von Strings definiert werden. Jeder String in der Liste wird als separates Argument an den Befehl übergeben, der im command-Feld definiert ist.

Beispiel in Kubernetes YAML:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    command: ["/app/start.sh"]
    args:
    - "-a"
    - "option1"
    - "--flag"
    - "value"

In diesem Fall wird der Container mit dem Befehl /app/start.sh -a option1 --flag value gestartet.

12.5.1 pod erzeugen

kubectl run nginx --image=nginx --restart=Never
kubectl get pod nginx                          

NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          25h

12.5.2 Enter pod

kubectl exec -it nginx -- /bin/bash

12.5.3 Install tools inside pod

apt update
apt install psmisc psutils

12.5.4 See processes

pstree -p

nginx(1)-+-nginx(29)
         |-nginx(30)
         |-nginx(31)
         |-nginx(32)
         |-nginx(33)
         `-nginx(34)

12.6 POD Manifest

Die Konfiguration eines Pods in Kubernetes wird durch ein Manifest in Form einer YAML-Datei dargestellt. Dieses Manifest definiert nicht nur die grundlegenden Eigenschaften wie den Namen und das Image des Pods, sondern auch detaillierte Spezifikationen und Verhaltensweisen der enthaltenen Container

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80

12.6.1 Erklärung

12.7 Manifest per cli erzeugen

kubectl run –dry-run option

Diese verschiedenen Modi bieten Flexibilität bei der Verwendung von kubectl und ermöglichen es Ihnen, je nach Bedarf eine Trockenlaufüberprüfung auf Client- oder Server-Seite durchzuführen oder direkt Änderungen am Cluster vorzunehmen.

12.8 Clientseitiger dry-run

kubectl run nginx-pod --image=nginx --port=8080 --dry-run=client -o yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx-pod
  name: nginx-pod
spec:
  containers:
  - image: nginx
    name: nginx-pod
    ports:
    - containerPort: 8080
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

12.9 Cluster seitiger dry-run

run nginx-pod --image=nginx --port=8080 --dry-run=server -o yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2023-10-30T10:06:32Z"
  labels:
    run: nginx-pod
  name: nginx-pod
  namespace: default
  uid: aae8ce68-ff5b-411b-9881-dda7013cbc41
spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: nginx-pod
    ports:
    - containerPort: 8080
      protocol: TCP
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-wqdqx
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: kube-api-access-wqdqx
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace
status:
  phase: Pending
  qosClass: BestEffort