Clusterbeheer op PLCnext: Kubernetes Benutten voor Industriële Automatisering

Een standaard in IT al jaren, het heeft nog niet veel impact gemaakt in de industrie. Vaak worden dergelijke technologieën gezien als te complex en onnodig. De vraag die rijst is: leveren ze ons voordelen?

Een visie voor PLCnext met het voorbeeld van Kubernetes.

Kubernetes

Kubernetes is een orchestrator (beheersysteem, master) die onder andere containers gebruikt en zo een netwerk vormt via verschillende apparaten. Het systeem wordt gebruikt om applicaties op een iets andere manier aan te bieden.

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

Met Kubernetes krijgt de master een toestandsbeschrijving van de applicatie, en de master zorgt voor de rest. Het zorgt ervoor dat de gevraagde toestand te allen tijde wordt gehandhaafd. Echter, het is niet bekend op welke node de applicatie momenteel draait, maar het is in principe bereikbaar.

Vragen en Antwoorden

Wat is een toestandsbeschrijving?

• De toestandsbeschrijving is de basis van elke applicatie. Het bevat bijvoorbeeld welke container in welke versie wordt gebruikt of of een applicatie meerdere keren moet worden gestart voor load balancing. Het is volledig in tekstform geschreven als json of yaml bestand. Het is daarom volledig versioneerbaar (bijv. Git of SVN).

Hoe de cluster te installeren?

• De deelnemers (master en nodes) moeten voorzien worden van twee softwarecomponenten (container runtime en Kubernetes). Daarna is slechts één inlog via token naar de master nodig. De rest wordt door de master gedaan.

Hoe applicatie-updates uit te voeren?

• Een update is simpelweg het vervangen van de toestandsbeschrijving van een applicatie door een nieuwe. De update wordt on-the-fly uitgevoerd, wat betekent 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 uitgevoerd worden en de oude toestand eenvoudig hersteld. De orchestrator bewaart alle oude toestanden. Daarnaast bestaat de mogelijkheid van de beschreven versionering van de toestanden.
• Nieuwe mogelijkheden van updatescenario's ontstaan hier. Als een applicatie frequenty in een cluster draait, kunnen bijvoorbeeld eerst slechts een deel van de applicaties worden geüpdatet. Als na een paar dagen of weken testen geen fouten optreden in de applicatie, kan de rest worden geüpdatet.

Wat gebeurt er als een node faalt?

• Als op een gegeven moment een node faalt, worden alle applicaties simpelweg beschikbaar gemaakt op een andere node. De bereikbaarheid blijft hetzelfde. Zolang er voldoende rekenkracht beschikbaar is, kunnen alle applicaties doordraaien. Er is veel discussie over een MQTT-server, die als centraal component veel problemen veroorzaakt bij een storing, maar in een cluster is dit geen probleem.

Wat gebeurt er als de master faalt?

• Masters kunnen ook redundant draaien, zodra er een faalt kan een andere node de taak overnemen.

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

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

Voorbeeld

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

Deployment:

• Definieert alle benodigde instellingen voor de containers.

Service:

• Creëert een interface naar de applicatie centraal in de cluster. De interface is altijd geldig, ongeacht op welke node de deployment draait.

Ingress:

• Koppelt de interface aan de frontend met een DNS-invoering. Dus de frontend is altijd bereikbaar op één domein.
• Proxy https://MyApp.MyDomain.de/ naar de frontend-service (poort 80)
• Proxy https://MyApp.MyDomain.de/api naar de backend-service (poort 3000)

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

## Container specificaties
  spec:
    containers:

## Container spec voor Frontend
## Naam voor de Container
    - name: MyContainer-frontend

## Container Image om te gebruiken
      image: MyApplicationImage_frontend

## Poorten voor de frontend, http
      ports:
      - containerPort: 80

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

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

## Opstartcommando's voor Mongo DB
      command:
      - "mongod"
      - "--bind_ip"
      - "0.0.0.0"
      ports:
      - containerPort: 27017
---
## Service declaratie, poorten blootleggen aan de kubernetes api (alleen intern bereikbaar)

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 declaratie, proxy koppelen aan frontend en backend

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

## Ingress binden aan traefik service proxy

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

## Ingress klasse voor frontend, map dns ingress naar service poort 80
spec:
  rules:
  - host: MyApp.Mydomain.de
    http:
      paths:
      - path: /
        backend:
          serviceName: MyApplicationName
          servicePort: frontend

## Ingress klasse voor backend, map dns ingress naar service poort 3000
  - host: MyApplicationName.MyDomain.de
    http:
      paths:
      - path: /api
        backend:
          serviceName: MyApplicationName
          servicePort: backend

Bekijk Ook

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