---
title: Kubernetes
description: Betreiben Sie Human Plugin auf Kubernetes mit einem Deployment, einem ClusterIP-Service, einem Secret für die Einstellungen und einem Pull-Secret für die Registry von Unico.
canonical: https://developer.unico.io/de/human-plugin/self-hosting/kubernetes
locale: de
generated_by: markdown-export
---

# Kubernetes

Zwei oder mehr Replikas hinter einem ClusterIP-Service, nur von Ihrem Back-End erreichbar.

## Voraussetzungen

- Ein Kubernetes-Cluster und `kubectl`-Zugriff darauf.
- Eine PostgreSQL-Datenbank, die ausschließlich Human Plugin vorbehalten und vom Cluster aus erreichbar ist. Siehe [Voraussetzungen und Zugang](/de/human-plugin/get-started/prerequisites).
- Die Registry-Zugangsdaten und der Zugriffsschlüssel von Unico.

Alles Folgende gehört in einen eigenen Namespace:

```bash
kubectl create namespace human-plugin
```

## 1. Registry-Pull-Secret

```bash
kubectl -n human-plugin create secret docker-registry unico-registry \
  --docker-server=pkg.unico.run \
  --docker-username="<username>" \
  --docker-password="<token>"
```

## 2. Secret für die Einstellungen

```bash
kubectl -n human-plugin create secret generic human-plugin \
  --from-literal=HUMAN_API_ACCESS_KEY='<your access key>' \
  --from-literal=POSTGRES_ADDRESS_HOST='<database host>' \
  --from-literal=POSTGRES_USER='human_plugin' \
  --from-literal=POSTGRES_PASSWORD='<database password>'
```

Fügen Sie `POSTGRES_ADDRESS_PORT`, `POSTGRES_DATABASE` oder `POSTGRES_SSL_MODE` nur hinzu, wenn Ihre Datenbank von den Standardwerten in [Konfiguration](/de/human-plugin/self-hosting/configuration) abweicht. Wenn Sie Secrets mit einem anderen Werkzeug verwalten (External Secrets, Sealed Secrets, ein Vault), erstellen Sie dieselben Schlüssel damit. Committen Sie niemals ein Secret-Manifest mit Werten.

## 3. Deployment und Service

```yaml title="human-plugin.yaml"
apiVersion: apps/v1
kind: Deployment
metadata:
  name: human-plugin
  namespace: human-plugin
spec:
  replicas: 2
  selector:
    matchLabels: { app: human-plugin }
  template:
    metadata:
      labels: { app: human-plugin }
    spec:
      terminationGracePeriodSeconds: 60
      imagePullSecrets:
        - name: unico-registry
      containers:
        - name: human-plugin
          image: pkg.unico.run/human-plugin-api:latest
          imagePullPolicy: Always
          ports:
            - { name: http, containerPort: 8080 }
          envFrom:
            - secretRef: { name: human-plugin }
          resources:
            requests: { cpu: "1", memory: 1Gi }
            limits: { cpu: "1", memory: 1Gi }
          readinessProbe:
            httpGet: { path: /health/ready, port: http }
            timeoutSeconds: 5
          livenessProbe:
            httpGet: { path: /health/live, port: http }
            periodSeconds: 30
---
apiVersion: v1
kind: Service
metadata:
  name: human-plugin
  namespace: human-plugin
spec:
  selector: { app: human-plugin }
  ports:
    - { name: http, port: 8080, targetPort: http }
```

```bash
kubectl apply -f human-plugin.yaml
```

```bash
kubectl -n human-plugin rollout status deployment/human-plugin
```

- **`replicas: 2`:** Die Replikas teilen sich die Datenbank, Sie können also so viele betreiben, wie Sie benötigen. Zwei halten Human Plugin verfügbar, während eines neu startet.
- **`terminationGracePeriodSeconds: 60`:** Human Plugin wartet beim Stoppen bis zu 55 Sekunden auf laufende Anfragen. Der Kubernetes-Standard von 30 Sekunden kann ein create abbrechen.
- **`imagePullPolicy: Always`:** Mit dem Tag `latest` lädt jeder neue Pod das aktuellste Release.
- **Probes:** Readiness hält Datenverkehr von einem Replikat fern, bis seine Datenbank antwortet, und `timeoutSeconds: 5` lässt sie fehlschlagen, wenn die Datenbank nicht mehr antwortet. Siehe [Health und Monitoring](/de/human-plugin/self-hosting/health-and-monitoring).
- **Ressourcen:** Die obigen Werte sind das Minimum pro Replikat. Siehe [Hardwareanforderungen](/de/human-plugin/self-hosting/overview#hardware-requirements).

## 4. Zugriff einschränken

Ihr Back-End erreicht Human Plugin unter `http://human-plugin.human-plugin.svc:8080`. Human Plugin hat keine eigene Authentifizierung, daher gilt:

- Stellen Sie den Service nicht über einen Ingress, einen `LoadBalancer` oder einen `NodePort` bereit;
- erlauben Sie mit einer NetworkPolicy nur den Namespace Ihres Back-Ends.

```yaml title="network-policy.yaml"
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: human-plugin-allow-backend
  namespace: human-plugin
spec:
  podSelector:
    matchLabels: { app: human-plugin }
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: <your back-end namespace> }
      ports:
        - { port: 8080 }
```

Human Plugin selbst benötigt ausgehendes HTTPS zu Unico und Zugriff auf Ihre Datenbank. Siehe [Netzwerk und Sicherheit](/de/human-plugin/self-hosting/networking-and-security).

## 5. Validieren

```bash
kubectl -n human-plugin port-forward svc/human-plugin 8080:8080
```

Prüfen Sie in einem anderen Terminal die Readiness und führen Sie die create-Anfrage aus dem [Quickstart](/de/human-plugin/get-started/quickstart#3-create-a-process) gegen `http://127.0.0.1:8080` aus:

```bash
curl --fail http://127.0.0.1:8080/health/ready
```

## Logs

```bash
kubectl -n human-plugin logs deploy/human-plugin --since=10m
```

## Aktualisieren

```bash
kubectl -n human-plugin rollout restart deployment/human-plugin
```

Die neuen Pods laden das neueste Image und ersetzen die alten nacheinander, sobald sie bereit sind. Siehe [Betrieb](/de/human-plugin/self-hosting/operations).