Clusterbeheer op PLCnext?

Het is al jaren een standaard in IT, maar heeft nog niet veel impact gehad in de industrie. Vaak worden dergelijke technologieën gezien als:
te ingewikkeld en onnodig. De vraag die rijst is, brengen ze ons voordelen?

Een visie voor PLCnext aan de hand van het voorbeeld van Kubernetes.

Kubernetes

Kubernete is een orchestrator (managementsysteem, master) die onder andere gebruik maakt van containers en zo via verschillende devices een netwerk vormt. Het systeem wordt gebruikt om applicaties op een iets andere manier aan te bieden.

Klassiek zouden applicaties op apparaten worden gedistribueerd en onderhouden. Het is bekend op welke computer de applicatie draait. Als een applicatie op een andere computer moet draaien, moet dit door een persoon worden gedaan. Als een van de computers uitvalt, zijn alle applicaties van de computer niet meer beschikbaar.

Bij Kubernetes krijgt de master een statusbeschrijving van de applicatie en doet de master de rest. Het zorgt ervoor dat de aangezochte staat te allen tijde wordt gehandhaafd. Het is echter niet bekend op welke node de applicatie momenteel draait, maar is in principe wel toegankelijk.

Vragen en antwoorden

Wat betreurt de beschrijving van de toestand

• De staatsbeschrijving is de basis van elke aanvraag. Hierin staat bijvoorbeeld welke container in welke versie wordt gebruikt of of een applicatie meerdere keren gestart moet worden voor load balancing. Het is volledig in tekstvorm geschreven als json of yaml  het dossier. Het is daarom volledig versiebeheerbaar (bijv. Git of SVN).

Hoe het cluster te installeren

• De deelnemers (master en nodes) dienen te worden voorzien van twee softwarecomponenten (container runtime en Kubernetes). Daarna is slechts één login via token bij de master nodig. De rest wordt gedaan door de meester.

Hoe updates van applicaties uit te voeren

• Een update vervangt simpelweg de statusbeschrijving van een applicatie door een nieuwe. De update gebeurt on the fly, dat wil zeggen dat de nieuwe applicatie eerst wordt geïnstalleerd en gestart en op het laatste moment de oude applicatie wordt afgesloten. Als een update mislukt, kan een rollback worden uitgevoerd en kan de oude status eenvoudig worden hersteld. De orkestrator behoudt alle oude toestanden. Daarnaast bestaat de mogelijkheid van de beschreven versiebeheer van de voorwaarden.
• Hier ontstaan ​​nieuwe mogelijkheden voor updatescenario's. Als een applicatie bijvoorbeeld vaak in een cluster draait, kunnen in eerste instantie slechts enkele applicaties worden bijgewerkt. Als er na een paar dagen of weken testen geen fouten in de applicatie optreden, kan de rest worden bijgewerkt.

Wat gebeurt er als een node uitvalt

• Als een node op enig moment uitvalt, worden alle applicaties gewoon beschikbaar gemaakt op een andere node. De bereikbaarheid blijft hetzelfde. Zolang er voldoende rekenkracht beschikbaar is, kunnen alle applicaties blijven draaien. Er is veel discussie over een MQTT-server, die als centraal onderdeel voor veel problemen zorgt bij een storing, maar in een cluster is dat geen probleem.

Wat gebeurt er als de master faalt

• Masters kunnen ook redundant worden uitgevoerd, als er één faalt, kan een ander knooppunt de taak overnemen.

Bepaalde applicaties moeten op bepaalde nodes draaien omdat toegang tot de hardware nodig is.

• Dit kan worden opgenomen in de staatsbeschrijvingen. Statussen kunnen ook worden toegewezen op basis van tags die bij apparaten horen. Elke AXCF2152 moet bijvoorbeeld een bepaalde applicatie draaien. Om het MQTT-voorbeeld weer op te pakken, er is een MQTT-server die in de federatie draait, verder kan elk knooppunt worden uitgerust met een MQTT-client om een ​​communicatie met de MQTT-server tot stand te brengen. De master bestaat maar één keer, de client draait op elk knooppunt.

Voorbeeld

Voorbeeld van een statusbeschrijving van een applicatie die uit drie containers bestaat (frontend, backend, database).

Implementatie:

• Definieert alle benodigde instellingen voor de containers.

Dienst:

• Maakt een interface naar de applicatie centraal in het cluster. De interface is altijd geldig, ongeacht op welk knooppunt de implementatie wordt uitgevoerd.

Inkomend:

• Koppelt de interface aan de frontend met behulp van een DNS-vermelding. De frontend is dus altijd bereikbaar op één domein.
• Proxy http://MyApp.MyDomain.de/ naar de frontend-service (poort 80)
• Proxy http://MyApp.MyDomain.de/api naar de backend-service (poort 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

Kijk eens

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