Gestion de cluster sur PLCnext ?

Un standard dans l'informatique depuis des années, il n'a pas encore eu beaucoup d'impact dans l'industrie. Ces technologies sont souvent considérées comme
trop complexe et inutile. La question qui se pose est, nous apportent-ils des avantages ?

Une vision pour PLCnext en utilisant l'exemple de Kubernetes.

Kubernetes

Kubernete est un orchestrateur (système de gestion, maître) qui utilise, entre autres, des conteneurs et forme ainsi un réseau via divers appareils. Le système est utilisé pour fournir des applications d'une manière légèrement différente.

Classiquement, les applications seraient distribuées et maintenues sur des appareils. On sait sur quel ordinateur l'application s'exécute. Si une application doit s'exécuter sur un autre ordinateur, cela doit être fait par une personne. Si l'un des ordinateurs tombe en panne, toutes les applications de l'ordinateur ne sont plus disponibles.

Avec Kubernetes, le maître reçoit une description de l'état de l'application et le maître s'occupe du reste. Il garantit que l'état demandé est maintenu à tout moment. Cependant, on ne sait pas sur quel nœud l'application s'exécute actuellement, mais elle est accessible en principe.

Questions et réponses

Ce qui déplore la description de l'état

• La description de l'état est la base de chaque application. Il contient par exemple quel conteneur est utilisé dans quelle version ou si une application doit être démarrée plusieurs fois pour l'équilibrage de charge. Il est entièrement écrit sous forme de texte sous la forme json ou yaml  dossier. Il est donc entièrement versionnable (par exemple Git ou SVN).

Comment installer le cluster

• Les participants (maître et nœuds) doivent disposer de deux composants logiciels (container runtime et Kubernetes). Après cela, une seule connexion via un jeton au maître est nécessaire. Le reste est fait par le maître.

Comment effectuer les mises à jour des applications

• Une mise à jour remplace simplement la description de l'état d'une application par une nouvelle. La mise à jour se fait à la volée, cela signifie que la nouvelle application est d'abord installée et démarrée et qu'au dernier moment l'ancienne application est fermée. Si une mise à jour échoue, une restauration peut être exécutée et l'ancien état peut simplement être restauré. L'orchestrateur conserve tous les anciens états. En outre, la possibilité de la version décrite des conditions existe.
• De nouvelles possibilités de scénarios de mise à jour apparaissent ici. Si une application s'exécute fréquemment dans un cluster, par exemple, seules certaines des applications peuvent être mises à jour dans un premier temps. Si aucune erreur ne se produit dans l'application après quelques jours ou semaines de tests, le reste peut être mis à jour.

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

• Si à tout moment un nœud tombe en panne, toutes les applications sont simplement mises à disposition sur un autre nœud. L'accessibilité reste la même. Tant qu'une puissance de calcul suffisante est disponible, toutes les applications peuvent continuer à fonctionner. Il y a beaucoup de discussions sur un serveur MQTT, qui, en tant que composant central, cause beaucoup de problèmes en cas de panne, mais dans un cluster, ce n'est pas un problème.

Que se passe-t-il si le maître échoue

• Les maîtres peuvent également être exécutés de manière redondante, une fois qu'un échoue, un autre nœud peut prendre le relais.

Certaines applications doivent s'exécuter sur certains nœuds car l'accès au matériel est nécessaire.

• Cela peut être inclus dans les descriptions d'état. Les états peuvent également être attribués en fonction des balises appartenant aux appareils. Par exemple, chaque AXCF2152 doit exécuter une certaine application. Pour reprendre l'exemple MQTT, il y a un serveur MQTT qui s'exécute dans la fédération, de plus chaque nœud peut être équipé d'un client MQTT pour établir une communication avec le serveur MQTT. Le maître n'existe qu'une seule fois, le client s'exécute sur chaque nœud.

Exemple

Exemple de description d'état d'une application composée de trois conteneurs (frontend, backend, base de données).

Déploiement :

• Définit tous les paramètres nécessaires pour les conteneurs.

Service :

• Crée une interface vers l'application de manière centralisée dans le cluster. L'interface est toujours valide, quel que soit le nœud sur lequel le déploiement s'exécute.

Entrée :

• Lie l'interface à l'interface à l'aide d'une entrée DNS. Ainsi, l'interface est toujours accessible sur un domaine.
• Proxy http://MyApp.MyDomain.de/ au service frontal (port 80)
• Proxy http://MyApp.MyDomain.de/api au 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 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

Jetez un œil

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