Cluster-Management auf PLCnext: Kubernetes für die industrielle Automatisierung nutzen

Ein Standard in der IT seit Jahren, hat in der Industrie noch nicht viel Einfluss gewonnen. Oft werden solche Technologien als zu komplex und unnötig angesehen. Die Frage ist: Bringen sie uns Vorteile?

Eine Vision für PLCnext am Beispiel von Kubernetes.

Kubernetes

Kubernetes ist ein Orchestrator (Managementsystem, Master), der unter anderem Container nutzt und so ein Netzwerk über verschiedene Geräte bildet. Das System wird verwendet, um Anwendungen auf etwas andere Weise bereitzustellen.

Klassisch würden Anwendungen auf Geräten verteilt und gewartet. Es ist bekannt, auf welchem Computer die Anwendung läuft. Wenn eine Anwendung auf einem anderen Computer laufen soll, muss dies von einer Person erledigt werden. Fällt einer der Computer aus, sind alle Anwendungen dieses Computers nicht mehr verfügbar.

Mit Kubernetes erhält der Master eine Zustandsbeschreibung der Anwendung, und der Master kümmert sich um den Rest. Er stellt sicher, dass der gewünschte Zustand jederzeit aufrechterhalten wird. Es ist jedoch nicht bekannt, auf welchem Node die Anwendung gerade läuft, aber sie ist prinzipiell erreichbar.

Fragen und Antworten

Was beschreibt die Zustandsbeschreibung?

• Die Zustandsbeschreibung ist die Basis jeder Anwendung. Sie enthält beispielsweise, welcher Container in welcher Version verwendet wird oder ob eine Anwendung für Lastverteilung mehrfach gestartet werden soll. Sie ist vollständig in Textform als json oder yaml Datei geschrieben. Sie ist daher vollständig versionierbar (z. B. Git oder SVN).

Wie installiert man den Cluster?

• Die Teilnehmer (Master und Nodes) müssen mit zwei Softwarekomponenten (Container Runtime und Kubernetes) ausgestattet werden. Danach ist nur ein Login via Token zum Master nötig. Den Rest erledigt der Master.

Wie führt man Updates von Anwendungen durch?

• Ein Update ist einfach das Ersetzen der Zustandsbeschreibung einer Anwendung durch eine neue. Das Update erfolgt „on the fly“: Die neue Anwendung wird zuerst installiert und gestartet und im letzten Moment die alte Anwendung heruntergefahren. Schlägt ein Update fehl, kann ein Rollback ausgeführt und der alte Zustand einfach wiederhergestellt werden. Der Orchestrator behält alle alten Zustände. Zusätzlich besteht die beschriebene Versionierung der Zustände.
• Neue Update-Szenarien entstehen. Wenn eine Anwendung häufig in einem Cluster läuft, können zunächst nur einige der Anwendungen aktualisiert werden. Wenn nach einigen Tagen oder Wochen Tests keine Fehler auftreten, kann der Rest aktualisiert werden.

Was passiert, wenn ein Node ausfällt?

• Fällt zu irgendeinem Zeitpunkt ein Node aus, werden alle Anwendungen einfach auf einem anderen Node verfügbar gemacht. Die Erreichbarkeit bleibt gleich. Solange genügend Rechenleistung verfügbar ist, können alle Anwendungen weiterlaufen. Es gibt viel Diskussion über einen MQTT-Server, der als zentrale Komponente bei Ausfall viele Probleme verursacht, aber in einem Cluster ist das kein Problem.

Was passiert, wenn der Master ausfällt?

• Master können auch redundant betrieben werden – fällt einer aus, kann ein anderer Node die Aufgabe übernehmen.

Bestimmte Anwendungen müssen auf bestimmten Nodes laufen, weil Hardwarezugriff nötig ist.

• Dies kann in den Zustandsbeschreibungen enthalten sein. Zustände können auch basierend auf Tags zugewiesen werden, die zu Geräten gehören. Als Beispiel: Jeder AXCF2152 muss eine bestimmte Anwendung ausführen. Um das MQTT-Beispiel wieder aufzugreifen: Es gibt einen MQTT-Server, der im Verbund läuft, ferner kann jeder Node mit einem MQTT-Client ausgestattet werden, um eine Kommunikation zum MQTT-Server herzustellen. Der Master existiert nur einmal, der Client läuft auf jedem Node.

Beispiel

Beispiel einer Zustandsbeschreibung einer Anwendung, die aus drei Containern besteht (Frontend, Backend, Datenbank).

Deployment:

• Definiert alle notwendigen Einstellungen für die Container.

Service:

• Erstellt eine Schnittstelle zur Anwendung zentral im Cluster. Die Schnittstelle ist immer gültig, egal auf welchem Node das Deployment läuft.

Ingress:

• Verknüpft die Schnittstelle mit dem Frontend über einen DNS-Eintrag. So ist das Frontend immer unter einer Domain erreichbar.
• Proxy https://MyApp.MyDomain.de/ an den Frontend-Service (Port 80)
• Proxy https://MyApp.MyDomain.de/api an den Backend-Service (Port 3000)

# Kind des Deployment
kind: Deployment
apiVersion: apps/v1
metadata:
  name: MyApplicationName
  labels:
    app: MyApplication
    MyApplication: MyApplicationName
    namespace: default

## Container-Spezifikationen
spec:
  containers:

## Container-Spezifikation für Frontend
## Name für den Container
  - name: MyContainer-frontend

## Container-Image zu verwenden
    image: MyApplicationImage_frontend

## Ports für das Frontend, http
    ports:
    - containerPort: 80

## Container-Spezifikation für Backend
  - name: MyContainerName-backend
    image: MyApplicationImage_backend
    ports:
    - containerPort: 3000

## Container-Spezifikation für MongoDB
  - name: MyContainerName-mongo
    image: mongo:3.4

## Startbefehle für Mongo DB
    command:
    - "mongod"
    - "--bind_ip"
    - "0.0.0.0"
    ports:
    - containerPort: 27017
---
## Service-Deklaration, Ports für Kubernetes API freigeben (nur intern erreichbar)

apiVersion: v1
kind: Service
metadata:
  name: MyApplicationName
spec:
  ports:
  - name: frontend
    targetPort: 80
    port: 80
  - name: backend
    targetPort: 3000
    port: 3000
  selector:
    app: MyApplication
    task: MyApplicationName

---
## Ingress-Deklaration, Proxy an Frontend und Backend binden

apiVersion: networking.k8s.io/v1beta1
kind: Ingress

## Ingress an traefik Service Proxy binden

metadata:
  name: MyApplicationName
  annotations:
    kubernetes.io/ingress.class: traefik

## Ingress-Klasse für Frontend, DNS-Ingress auf Service-Port 80 mappen
spec:
  rules:
  - host: MyApp.Mydomain.de
    http:
      paths:
      - path: /
        backend:
          serviceName: MyApplicationName
          servicePort: frontend

## Ingress-Klasse für Backend, DNS-Ingress auf Service-Port 3000 mappen
  - host: MyApplicationName.MyDomain.de
    http:
      paths:
      - path: /api
        backend:
          serviceName: MyApplicationName
          servicePort: backend

Einen Blick werfen

• Kubernetes Cluster erstellen mit kubeadm
• k3s
• k3d
• k3x