Clusterverwaltung auf PLCnext?

In der IT seit Jahren Standard, hat es sich in der Industrie noch nicht durchgesetzt. Oft werden solche Technologien als angesehen
zu kompliziert und unnötig. Die Frage, die sich stellt, ist, bringen sie uns Vorteile?

Eine Vision für PLCnext am Beispiel von Kubernetes.

Kubernetes

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

Klassischerweise würden Anwendungen auf Geräten verteilt und gepflegt. Es ist bekannt, auf welchem ​​Rechner die Anwendung läuft. Soll eine Anwendung auf einem anderen Rechner laufen, muss dies von einer Person durchgeführt werden. Fällt einer der Rechner aus, stehen alle Anwendungen des Rechners nicht mehr zur Verfügung.

Bei Kubernetes erhält der Master eine Zustandsbeschreibung der Anwendung und der Master kümmert sich um den Rest. Es stellt sicher, dass der angeforderte Zustand jederzeit beibehalten wird. Es ist jedoch nicht bekannt, auf welchem ​​Knoten die Anwendung gerade läuft, aber sie ist prinzipiell erreichbar.

Fragen und Antworten

Was bedauert Zustandsbeschreibung

• Die Zustandsbeschreibung ist Grundlage jeder Bewerbung. Darin ist beispielsweise enthalten, welcher Container in welcher Version verwendet wird oder ob eine Anwendung zum Load-Balancing mehrfach gestartet werden soll. Er ist komplett in Textform als json geschrieben oder yaml  Datei. Es ist daher voll versionierbar (z. B. Git oder SVN).

So installieren Sie den Cluster

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

So führen Sie Aktualisierungen von Anwendungen durch

• Ein Update ersetzt einfach die Zustandsbeschreibung einer Anwendung durch eine neue. Das Update erfolgt on-the-fly, dh die neue Anwendung wird zuerst installiert und gestartet und im letzten Moment die alte Anwendung heruntergefahren. Schlägt ein Update fehl, kann ein Rollback durchgeführt und der alte Zustand einfach wiederhergestellt werden. Der Orchestrator behält alle alten Zustände bei. Außerdem besteht die Möglichkeit der beschriebenen Versionierung des Standes.
• Hier ergeben sich neue Möglichkeiten von Update-Szenarien. Läuft eine Anwendung beispielsweise häufig in einem Cluster, kann zunächst nur ein Teil der Anwendungen aktualisiert werden. Wenn nach einigen Testtagen oder -wochen keine Fehler in der Anwendung auftreten, kann der Rest aktualisiert werden.

Was passiert, wenn ein Knoten ausfällt

• Wenn zu irgendeinem Zeitpunkt ein Knoten ausfällt, werden alle Anwendungen einfach auf einem anderen Knoten verfügbar gemacht. Die Erreichbarkeit bleibt gleich. Solange genügend Rechenleistung zur Verfügung steht, können alle Anwendungen weiterlaufen. Es wird viel über einen MQTT-Server diskutiert, der als zentrale Komponente bei einem Ausfall viele Probleme verursacht, in einem Cluster aber kein Problem darstellt.

Was passiert, wenn der Master ausfällt

• Master können auch redundant betrieben werden, wenn einer ausfällt, kann ein anderer Knoten den Job übernehmen.

Bestimmte Anwendungen müssen auf bestimmten Knoten ausgeführt werden, da Zugriff auf die Hardware erforderlich ist.

• Dies kann in die Zustandsbeschreibungen aufgenommen werden. Zustände können auch basierend auf Tags zugewiesen werden, die zu Geräten gehören. Beispielsweise muss auf jedem AXCF2152 eine bestimmte Anwendung ausgeführt werden. Um das MQTT-Beispiel noch einmal aufzugreifen, es gibt einen MQTT-Server, der in der Föderation läuft, außerdem kann jeder Knoten mit einem MQTT-Client ausgestattet werden, um eine Kommunikation zum MQTT-Server aufzubauen. Der Master existiert nur einmal, der Client läuft auf jedem Knoten.

Beispiel

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

Bereitstellung:

• Definiert alle notwendigen Einstellungen für die Container.

Dienst:

• Schafft zentral im Cluster eine Schnittstelle zur Anwendung. Die Schnittstelle ist immer gültig, egal auf welchem ​​Knoten die Bereitstellung ausgeführt wird.

Eindringen:

• Verbindet die Schnittstelle über einen DNS-Eintrag mit dem Frontend. Das Frontend ist also immer auf einer Domain erreichbar.
• Proxy http://MyApp.MyDomain.de/ zum Frontend-Dienst (Port 80)
• Proxy http://MyApp.MyDomain.de/api zum Backend-Dienst (Port 3000)

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

## Container specs
    spec:
      containers:

## Container spec for Frontend
## Name for the Container
      - name: MyContainer-frontend

## Container Image to use      
        image: MyApplicationImage_frontend

## Ports for the frontend, http        
        ports:
        - containerPort: 80

## Container spec for Backend      
      - name: MyContainerName-backend
        image: MyApplicationImage_backend
        ports:
        - containerPort: 3000

## Container spec for mongodb          
      - name: MyContainerName-mongo
        image: mongo:3.4

## Startup commands for Mongo DB
        command:
        - "mongod"
        - "--bind_ip"
        - "0.0.0.0"
        ports:
        - containerPort: 27017    
---
## Service declaration, expose Ports to the kubernetes api (only internal rechable)

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 declaration, bind proxy to fronted and backend

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

## Bind ingress to traefik service proxy

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

## Ingress class for frontend, map dns ingress to service port 80 
spec:
  rules:
  - host: MyApp.Mydomain.de
    http:
      paths:
      - path: /
        backend:
          serviceName:MyApplicationName
          servicePort: frontend

## Ingress class for backend, map dns ingress to service port 3000          
  - host: MyApplicationName.MyDomain.de
    http:
      paths:
      - path: /api
        backend:
          serviceName:MyApplicationName
          servicePort: backend

Schauen Sie sich das an

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/
https://github.com/k3s-io/k3s
https://github.com/rancher/k3d
https://github.com/inercia/k3x