Gestion de cluster sur PLCnext : exploiter Kubernetes pour l'automatisation industrielle

Standard dans l'IT depuis des années, Kubernetes n'a pas encore beaucoup impacté l'industrie. Souvent jugé trop complexe et inutile. La question : apporte-t-il des avantages ?

Une vision pour PLCnext à travers l'exemple de Kubernetes.

Kubernetes

Kubernetes est un orchestrateur (système de gestion, maître) qui utilise, entre autres, des conteneurs et forme un réseau via divers périphériques. Le système fournit les applications différemment.

Classiquement, les applications sont distribuées et maintenues sur des périphériques. On sait sur quel ordinateur l'application tourne. Pour la déplacer, une intervention humaine est nécessaire. Si un ordinateur tombe, toutes ses applications deviennent indisponibles.

Avec Kubernetes, le maître reçoit une description d'état de l'application et s'occupe du reste. Il garantit que l'état demandé est maintenu en permanence. On ne sait pas sur quel nœud l'application tourne actuellement, mais elle reste accessible.

Questions et réponses

Qu'est-ce qu'une description d'état ?

• Base de toute application. Contient par exemple quel conteneur en quelle version, si l'application doit être démarrée plusieurs fois pour load balancing. Écrite entièrement en texte sous forme json ou yaml. Donc entièrement versionnable (Git, SVN).

Comment installer le cluster ?

• Les participants (maître et nœuds) doivent recevoir deux composants logiciels (container runtime et Kubernetes). Ensuite, une seule connexion via token au maître suffit. Le reste est géré par le maître.

Comment mettre à jour les applications ?

• Une mise à jour = remplacer la description d'état par une nouvelle. Mise à jour à la volée : la nouvelle application est d'abord installée et démarrée, puis l'ancienne est arrêtée au dernier moment. Si échec, rollback possible, l'ancien état restauré. L'orchestrateur garde tous les anciens états. Versioning des descriptions possible.
• Nouveaux scénarios de mise à jour : si une application tourne fréquemment dans un cluster, on peut mettre à jour seulement une partie. Si pas d'erreurs après jours/semaines de test, mettre à jour le reste.

Que se passe-t-il si un nœud tombe ?

• Toutes les applications sont simplement rendues disponibles sur un autre nœud. Accessibilité maintenue. Tant que la puissance de calcul suffit, tout continue. Discussion fréquente sur serveur MQTT comme point central de défaillance, mais en cluster ce n'est plus un problème.

Que se passe-t-il si le maître tombe ?

• Les maîtres peuvent être redondants, un autre nœud prend le relais.

Certaines applications doivent tourner sur certains nœuds pour accéder au matériel.

• Inclus dans les descriptions d'état. États assignables via tags des périphériques. Exemple : chaque AXCF2152 doit faire tourner une certaine application. Pour reprendre l'exemple MQTT : un serveur MQTT dans la fédération, chaque nœud avec un client MQTT pour communiquer avec le serveur. Le maître est unique, le client tourne sur chaque nœud.

Exemple

Description d'état d'une application à trois conteneurs (frontend, backend, base de données).

Deployment : définit tous les réglages nécessaires pour les conteneurs.

Service : crée une interface vers l'application centralement dans le cluster. Interface toujours valide quel que soit le nœud hébergeant le deployment.

Ingress : lie l'interface au frontend via une entrée DNS. Frontend toujours accessible sur un domaine.
Proxy https://MyApp.MyDomain.de/ vers service frontend (port 80)
Proxy https://MyApp.MyDomain.de/api vers service backend (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 reachable)

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 frontend 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

À consulter

• Créer un cluster avec kubeadm
• k3s
• k3d
• k3x