¿Gestión de clústeres en PLCnext?

Un estándar en TI durante años, aún no ha tenido mucho impacto en la industria. A menudo, estas tecnologías se consideran
demasiado complejo e innecesario. La pregunta que surge es, ¿nos reportan ventajas?

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

Kubernetes

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

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

Con Kubernetes, el maestro recibe una descripción del estado de la aplicación y el maestro se encarga del resto. Garantiza 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 en principio es accesible.

Preguntas y respuestas

Lo que deplora la descripción de la condición

• La descripción del 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 varias veces para equilibrar la carga. Está escrito completamente en forma de texto como json o yaml  expediente. Por lo tanto, es completamente versionable (por ejemplo, Git o SVN).

Cómo instalar el clúster

• Los participantes (maestro y nodos) deben contar con dos componentes de software (tiempo de ejecución del contenedor y Kubernetes). Después de eso, solo se necesita un inicio de sesión mediante token para el maestro. El resto lo hace el maestro.

Cómo realizar actualizaciones de aplicaciones

• Una actualización simplemente reemplaza la descripción de estado de una aplicación por una nueva. La actualización se realiza sobre la marcha, lo que significa que primero se instala e inicia la nueva aplicación y, en el último momento, se cierra la aplicación anterior. Si falla una actualización, se puede ejecutar una reversión y simplemente se puede restaurar el estado anterior. El orquestador mantiene todos los estados antiguos. Además existe la posibilidad del versionado descrito de las condiciones.
• Aquí surgen nuevas posibilidades de escenarios de actualización. Si una aplicación se ejecuta con frecuencia en un clúster, por ejemplo, solo algunas de las aplicaciones se pueden actualizar al principio. Si no se producen errores en la aplicación después de unos días o semanas de pruebas, el resto se puede actualizar.

Qué sucede si falla un nodo

• Si en algún momento falla un nodo, todas las aplicaciones simplemente están disponibles en otro nodo. La accesibilidad sigue siendo la misma. Siempre que haya suficiente potencia informática 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 falla, pero en un clúster no es un problema.

¿Qué sucede si falla el maestro?

• Los maestros también se pueden ejecutar de forma redundante, una vez que uno falla, otro nodo puede hacerse cargo del trabajo.

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

• Esto se puede incluir en las descripciones de los estados. Los estados también se pueden asignar en función de las etiquetas que pertenecen a los dispositivos. Como ejemplo, cada AXCF2152 debe ejecutar una determinada aplicación. Para retomar el ejemplo de MQTT nuevamente, 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 con el 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 consta de tres contenedores (frontend, backend, base de datos).

Despliegue:

• Define todas las configuraciones necesarias para los contenedores.

Servicio:

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

Ingreso:

• Vincula la interfaz al frontend mediante una entrada DNS. Por lo tanto, siempre se puede acceder a la interfaz en un dominio.
• Proxy http://MyApp.MyDomain.de/ al servicio frontend (Puerto 80)
• Proxy http://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 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

Echa un vistazo

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