Clustermangement on PLCnext?

A standard in IT for years, it has not yet made much of an impact in industry. Often such technologies are seen as
too complex and unnecessary. The question that arises is, do they bring us advantages?

A vision for PLCnext using the example of Kubernetes.

Kubernetes

Kubernete is an orchestrator (management system, master) which uses, among other things, containers and thus forms a network via various devices. The system is used to provide applications in a slightly different way.

Classically applications would be distributed and maintained on devices. It is known on which computer the application runs. If an application should run on another computer this must be done by a person. If one of the computers fails, all applications of the computer are no longer available.

With Kubernetes, the master is given a state description of the application, and the master takes care of the rest. It ensures that the requested state is maintained at all times. However, it is not known on which node the application is currently running, but it is accessible in principle.

Questions and answers

What deplores condition description

• The state description is the basis of every application. It contains for example which container is used in which version or if an application should be started multiple times for load balancing. It is written completely in text form as json or yaml file. It is therefore fully versionable (e.g. Git or SVN).

How to install the cluster

• The participants (master and nodes) must be provided with two software components (container runtime and Kubernetes). After that, only one login via token to the master is needed. The rest is done by the master.

How to perform updates of applications

• An update is simply replacing the state description of an application with a new one. The update is done on the fly, that means the new application is first installed and started and at the last moment the old application is shut down. If an update fails, a rollback can be executed and the old state can simply be restored. The orchestrator keeps all old states. In addition the possibility of the described versioning of the conditions exists.
• New possibilities of update scenarios arise here. If an application runs frequently in a cluster, for example, only some of the applications can be updated at first. If no errors occur in the application after a few days or weeks of tests, the rest can be updated.

What happens if a node fails

• If at any time a node fails, all applications are simply made available on another node. The accessibility remains the same. As long as enough computing power is available, all applications can continue to run. There is a lot of discussion about a MQTT server, which as a central component causes a lot of problems in case of a failure, but in a cluster it is not a problem.

What happens if the master fails

• Masters can also be run redundantly, once one fails another node can take over the job.

Certain applications need to run on certain nodes because access to the hardware is needed.

• This can be included in the state descriptions. States can also be assigned based on tags that belong to devices. As an example each AXCF2152 must be running a certain application. To pick up the MQTT example again, there is a MQTT server that runs in the federation, furthermore each node can be equipped with a MQTT client to establish a communication to the MQTT server. The master exists only once, the client runs on each node.

Example

Example of a state description of an application that consists of three containers (frontend, backend, database).

Deployment:

• Defines all the necessary settings for the containers.

Service:

• Creates an interface to the application centrally in the cluster. The interface is always valid no matter which node the deployment is running on.

Ingress:

• Links the interface to the frontend using a DNS entry. So the frontend is always reachable on one domain.
• Proxy http://MyApp.MyDomain.de/ to the frontend service (Port 80)
• Proxy http://MyApp.MyDomain.de/api to the backend service (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

Take a look

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