Gestión de clústeres en PLCnext: Aprovechando Kubernetes para automatización industrial

Un estándar en TI durante años, aún no ha tenido mucho impacto en la industria. A menudo, tales tecnologías se ven como demasiado complejas e innecesarias. La pregunta que surge es: ¿nos aportan ventajas?

Una visión para PLCnext usando el ejemplo de Kubernetes.

Kubernetes

Kubernetes es un orquestador (sistema de gestión, maestro) que usa, entre otras cosas, contenedores y así forma una red a través de varios dispositivos. El sistema se usa para proporcionar aplicaciones de una manera ligeramente diferente.

Clásicamente, las aplicaciones se distribuirían y mantendrían en dispositivos. Se sabe en qué computadora se ejecuta la aplicación. Si una aplicación debe ejecutarse en otra computadora, esto debe ser hecho por una persona. Si una de las computadoras falla, todas las aplicaciones de esa computadora ya no están disponibles.

Con Kubernetes, al maestro se le da una descripción de estado de la aplicación, y el maestro se encarga del resto. Asegura que el estado solicitado se mantenga en todo momento. Sin embargo, no se sabe en qué nodo se está ejecutando actualmente la aplicación, pero es accesible en principio.

Preguntas y respuestas

¿Qué describe la descripción de estado?

• La descripción de estado es la base de cada aplicación. Contiene, por ejemplo, qué contenedor se usa en qué versión o si una aplicación debe iniciarse múltiples veces para balanceo de carga. Está escrita completamente en forma de texto como archivo json o yaml. Por lo tanto, es totalmente versionable (ej. Git o SVN).

¿Cómo instalar el clúster?

• Los participantes (maestro y nodos) deben proveerse con dos componentes de software (runtime de contenedores y Kubernetes). Después de eso, solo se necesita un inicio de sesión vía token al maestro. El resto lo hace el maestro.

¿Cómo realizar actualizaciones de aplicaciones?

• Una actualización es simplemente reemplazar la descripción de estado de una aplicación con una nueva. La actualización se hace sobre la marcha (on the fly), eso significa que la nueva aplicación se instala e inicia primero y en el último momento se apaga la aplicación antigua. Si una actualización falla, se puede ejecutar un rollback y el estado antiguo simplemente se puede restaurar. El orquestador mantiene todos los estados antiguos. Además existe la posibilidad de versionar las descripciones como se describió.
• Surgen nuevas posibilidades de escenarios de actualización. Si una aplicación se ejecuta frecuentemente en un clúster, por ejemplo, solo algunas de las aplicaciones pueden actualizarse primero. Si no ocurren errores en la aplicación después de unos días o semanas de pruebas, el resto puede actualizarse.

¿Qué pasa si un nodo falla?

• Si en cualquier momento falla un nodo, todas las aplicaciones simplemente se ponen disponibles en otro nodo. La accesibilidad permanece igual. Mientras haya suficiente potencia de cómputo disponible, todas las aplicaciones pueden continuar ejecutándose. Hay mucha discusión sobre un servidor MQTT, que como componente central causa muchos problemas en caso de fallo, pero en un clúster no es un problema.

¿Qué pasa si el maestro falla?

• Los maestros también pueden ejecutarse de forma redundante, una vez que uno falla, otro nodo puede tomar el trabajo.

Ciertas aplicaciones necesitan ejecutarse en ciertos nodos porque se necesita acceso al hardware.

• Esto puede incluirse en las descripciones de estado. Los estados también pueden asignarse basándose en etiquetas (tags) que pertenecen a dispositivos. Como ejemplo, cada AXCF2152 debe estar ejecutando una cierta aplicación. Para retomar el ejemplo MQTT, hay un servidor MQTT que se ejecuta en la federación, además cada nodo puede equiparse con un cliente MQTT para establecer una comunicación al servidor MQTT. El maestro existe solo una vez, el cliente se ejecuta en cada nodo.

Ejemplo

Ejemplo de una descripción de estado de una aplicación que consiste en tres contenedores (frontend, backend, base de datos).

Deployment:

• Define toda la configuración necesaria para los contenedores.

Service:

• Crea una interfaz a la aplicación centralmente en el clúster. La interfaz siempre es válida sin importar en qué nodo se esté ejecutando el deployment.

Ingress:

• Vincula la interfaz al frontend usando una entrada DNS. Así el frontend siempre es accesible en un dominio.
• Proxy https://MyApp.MyDomain.de/ al servicio frontend (Puerto 80)
• Proxy https://MyApp.MyDomain.de/api al servicio backend (puerto 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 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

Eche un vistazo

• Crear clúster con kubeadm
• k3s - Kubernetes ligero
• k3d - k3s en Docker
• k3x