WO2021037379A1

WO2021037379A1 - Method for operating a cluster, cluster work node, cluster, network, computer program and computer-readable medium

Info

Publication number: WO2021037379A1
Application number: PCT/EP2019/073229
Authority: WO
Inventors: Harald Albrecht; Stephan Höme; Thomas Talanis
Original assignee: Siemens Aktiengesellschaft
Priority date: 2019-08-30
Filing date: 2019-08-30
Publication date: 2021-03-04

Abstract

The invention relates to a method for operating a cluster (2) connected to an industrial network of an installation or machine, wherein work nodes (1) of the cluster (2) have resources of the installation or of the machine, installation resources (3), wherein – a resource marker (11) has been or is assigned to each of the nodes having installation resources (3), – at least one description element (10) is available or provided, in which workloads (4) are indicated that need to be set up on nodes (1) that have installation resources (3) indicated in the or the respective description element (10), suitable nodes (1), – a control module (9) evaluates firstly the at least one description element (10) and secondly resource markers (11) assigned to the nodes (1) of the cluster (2) and ascertains whether at least one suitable node (1) is present, – the control module (9), on this being the case, creates at least one workload element (15) for setting up workloads (4) on the at least one suitable node (1). The invention further relates to a cluster work node (1), a cluster (2), a network, a computer program and a computer-readable medium.

Description

description

Method for operating a cluster, cluster work node, cluster, network, computer program and computer-readable medium

The invention relates to a method for operating a cluster that is connected to an industrial network of a plant or machine. In addition, the invention relates to a cluster work node, a cluster, a network, a computer program and a computer-readable medium.

In the area of general IT, what is known as container technology has proven its worth. Application containers are usually "encapsulated" units that can run independently of one another, no matter where they are. Similar to virtual machines, containers are a kind of container for applications in which they can run. While virtual machines map an entire computer environment, however, the containers usually only contain the important data that are required for the execution of the respective application or applications.

The container technologies and containerization make it possible in particular to pack software or application in a container that includes everything it needs to run, for example program code, runtime, system tools and / or system libraries. The container technologies and containerization allow functions to be packaged, transported and finally rolled out in the operative area simply and conveniently. Classic areas of use for containers are, for example, to conveniently package applications such as a database or a web front-end.

Examples of software for container virtualization / containerization are for example "Docker" or "rkt" (pronounced "rocket", see for example https://coreos.com/rkt/ and https://www.docker.com or EP 3267 351 Al on Docker). An example of an orchestration system / tool or orchestration software for containers is given by "Kubernetes" (see for example https://kubernetes.io/ and https: //de.wikipedia .org / wiki / Kubernetes)

Today, general IT provides a number of mechanisms to distribute the workloads required for applications in a cluster of work computers (= work nodes), in particular in the form of containers, to the existing nodes. (Container) orchestration systems, such as Kubernetes, for clusters of work nodes are known.

With orchestration systems such as Kubernetes, so-called "pods", in particular, can be orchestrated, which represent the smallest unit that can be used. A pod contains at least one container are used synonymously) run.

The cluster with its work nodes is usually controlled by one or more controllers or masters, in the case of Kubernetes via one or more so-called "Kubernetes masters", which are also (in each case) given or ( each) can be implemented on one of the working nodes The working nodes of a cluster can be arranged spatially distributed.

Kubernetes knows so-called "deployments" on the one hand, and "daemon sets" on the other hand for different types of workloads.

Deployments define how many identical copies (containers) of a certain service are required, which are then automatically distributed to the work nodes. In this case, it is unimportant in a first approximation which specific ar- beitsknoten cope with the individual workloads as long as the required number of containers - wherever - is provided. In contrast to this, DaemonSets describe that a service is provided on all working nodes. It is not the absolute number of containers that is important here, but the locations where the services must be provided. Such services are therefore (work) node-specific. It can only be specified in general whether one, two, ... containers of the same service have to be processed on each relevant node. Individual node-specific deviations are not provided.

A transfer of these IT mechanisms for managing services (containers) to clusters in the industrial environment, so-called "industrial clusters", is very promising from the applicant's point of view. Industrial clusters are usually in this case through a mixture of industrial edge devices industrial plants as well as other unspecific work nodes (possibly in a data center).

The use of IT mechanisms can on the one hand avoid unnecessary duplicate developments in competition with IT and on the other hand help automation technology to benefit quickly and efficiently from IT innovations in the area of cluster / cloud technologies. In industrial clusters with industrial edges, however, besides the models for workloads known from IT, there are also other use cases in which, for example, the specific workload is closely related to individual system components or equipment. These can be, for example, OPC UA servers for system sensors and actuators with special hardware connections or virtual network functions (VNFs), such as a large number of local NAT64 converters from the IPv6 company network distributed in a system to IPv4 automation devices.

It is true that some industrial applications could be fundamentally implemented with the mechanisms known so far from general IT. additionally map. However, this creates a high installation and maintenance effort under certain circumstances. Simplified and at least partially automatic set-up and adaptation to the actual system configuration would be desirable.

It is therefore an object of the present invention to provide a way to create a reasonable cost Arbeitslas a particular industrial cluster th to distribute to the working node, so in cases where specific workloads usammenhängen closely with individual system components or Ge councils outfits _Z.

This object is achieved by a method for operating a cluster that is connected to an industrial network of a plant or machine, with working nodes of the cluster having resources of the plant or the machine, plant resources, in which

- a resource marker is or is assigned to each of the nodes that have system resources, with the respective resource marker indicating or being able to be derived from the respective resource marker which system resources the respective node has at its disposal,

- At least one descriptive element is broad or is made available, in which workloads are specified that are to be set up on nodes that have system resources specified in the respective descriptive element, suitable accounts, the respective descriptive element comprising a template,

- A control module, on the one hand, evaluates the at least one description element and, on the other hand, the resource marker assigned to the node of the cluster and determines whether at least one matching node is available,

the control module for the case that this is the case creates at least one workload element for setting up workloads on the at least one matching node, the control module for this purpose using the template contained in the at least one description element is used and inserts at least part of the resource marker assigned to the at least one matching node into this.

In other words, the invention enables the automatic scheduling of workloads (for example in the form of pods / containers) on the basis of system resources. For this purpose, the invention provides the use of one or more descriptive elements, the use of resource markers and a control module.

Of course, it is possible that several descriptive elements are available or are made available, in each of which workloads are specified that are directed to nodes that have system resources specified in the respective descriptive element, in other words, on appropriate accounts. It then also preferably comprises the respective descriptive element a template.

In the event that several description elements are available or are provided, each of the description elements relates or describes a different type of workload or specifies a different type of workload. In other words, the description elements can be present more than once, especially in the configuration of the cluster system, in which case, however, an individual description element always describes only one type of workload or similar workloads.

The or - in the case of several - the respective descriptive element, which can be a textual descriptive element, for example a text file, preferably links system resources and workloads with one another. The respective descriptive element describes in particular the workloads to be set up or installed that are to be set up or installed precisely on those nodes that have the system resources also specified or named in the respective descriptive element. In one embodiment, the description element or elements can also be referred to or understood as so-called “Plant Resource Deployment Resources” or RDRs for short. In the Kubernetes world there are the so-called "Deployments" (= "Deployment Resources") mentioned above. Based on and at the same time as a distinction to the "Deployments" (and "Daemon Sets") already defined today, the specializing addition the "Plant Resource" can be used. In this way it can be made clear that the deployment of "plant resources" can be targeted.

A part of the or the respective descriptive element is preferably a template or template, in particular a template or template for the workloads to be generated. Another part appropriately describes or specifies the required or associated system resources.

The system resources are preferably specified in the respective descriptive element in the form of expected resource marks or in the form of expected parts of resource marks.

The control module, which can also be referred to as the Resource Deployment Controller or RDC for short, can automatically evaluate both the description element or elements as well as existing resource markers. For this purpose, the control module has access to the at least one description element and resource markers assigned to the work node. The control module can preferably record and evaluate the at least one descriptive element and resource marker repeatedly, for example cyclically. Furthermore, the control module preferably uses the at least one description element or elements stored in the cluster configuration to determine whether and which suitable working nodes are available, in particular in the form of node resources and preferably in the cluster configuration that have the desired resource markers own or are provided with these and thus have the associated system resources. The control module automatically generates workload elements for the appropriate node or nodes, for example in the form of pod resources (English: pod resources, PRs for short) or deployments.

Using the workload element (s), in particular PRs or deployments, an orchestration system, for example Kubernetes, can then automatically set up workloads, in particular in the form of pods and / or containers, on the respective node. The workload element or elements can in particular be Kubernetes Pod Resources or Kubernetes Deployments.

In the event that the evaluation of the control module shows that there are several matching nodes, the control module preferably creates at least one workload element for each of the matching nodes.

More than one workload element is particularly preferably created by the control module for a suitable node in the event that a system resource is present several times at the suitable node. Purely by way of example, it should be mentioned here that a node has two or more network interfaces or has access to two or more subnetworks, for example cell networks.

Particularly preferably, the at least one workload element created by the control module relates to at least one workload in the form of a container and / or pod. In particular, in this case, workloads in the form of containers can be set up on the at least one matching node.

In a further advantageous embodiment, at least one workload is specified in the at least one description element in the form of a virtual network function. In an analogous way, this applies to at least one of the control module provided workload element preferably at least one workload in the form of a virtual network function. One example is a (virtual) NAT64 function.

The cluster is connected to the industrial network of a plant or machine or takes part in it.

One of the main tasks of the control module is in particular to replace parts of the (respective) template with specific information about individual system resources in order to obtain the final workload elements, in particular PRs or deployments. This information preferably comes from the resource markers on the work nodes or on their representatives in the cluster configuration.

It should be noted that not all nodes of the cluster have to be connected to the system or machine network, but that this can only apply to some of the nodes (in the borderline case only to one node). In this case, resource markers can only be provided for those nodes that take part in the plant or machine network, since these in particular have plant resources.

The resource markers are, in particular, markings.

In the case of a cluster node given as an industrial edge with two cell networks, for example, the resource markers can, for example, list the specific names of the hardware network interfaces "ens33p0" and "ens42p66". The control module would then generate two PRs from this, with one of the PRs containing the specific information about the network interface "ens33p0", while the other PR indicates "ens42p66" instead.

The inventive use of a template for the workloads to be set up on matching nodes is thereby a particularly efficient process is guaranteed. The template can be adapted or "filled" by the control module on the basis of the system resources of a suitable work node.

An example of a description element can be: kind: di.Siemens.com/ResourceDeployment metadata: name: nat64 spec: matchResource: di.Siemens.com/cellnets template:

# pod template for plant (equipment) resource containers:

- name: nat64 args: ["/ bin / nat64", "-i", "{di.Siemens.com/cellnets:i}"]

In this purely exemplary description element, the "i th" element in the list of matching plant resources (Plant / Equipment Resources) is. These are here under "matchResource:" of the type "di.siemens.com/cellnets" , whereby there can be 0..n values for each. ": i" inserts these concrete values one after the other. According to the example continued below, "ens33p0" and "ens42p66" one after the other.

According to this purely exemplary description element, (virtual) NAT64 routers are to be set up on all those cluster work nodes (for example in the form of industrial edges) that have cell networks as plant resources or to which such are assigned. The workloads to be set up in this example are virtual network functions, specifically virtual NAT64 router functions. The part beginning with "template" in the previous example is the template for workloads to be set up.

An example of a workload telement given by a deployment is: kind: Deployment metadata: name: nat64-grmpf-12 template: metadata:

# ... spec: template: nodeName: indedge-42 Containers:

- name: nat64 args: ["/ bin / nat64", "-i", "ens42p66"]

The control module preferably carries out its activity permanently. The evaluation of the description element (s) and the resource marker (s) can be carried out cyclically, for example.

In a further preferred embodiment, the control module not only ensures that new workloads are set up for newly added system resources, but also removes again those workloads whose (associated) system resources have been removed. In a further development it is therefore provided that in the event that system resources are lost at at least one work node, at least one workload set up for the at least one affected node is removed again from the control module. In other words, this embodiment offers a kind of "clean-up mechanism" For example, a target status of the required workloads can be provided and / or determined and the current actual status of the relevant workloads can be provided and / or determined and the target status can then be compared with the current actual status. If (sic?) A workload is now contained in the actual state, but not in the target state, then it is terminated preferentially (in a controlled manner). For this purpose, it is sufficient, for example, for the control module to delete the relevant individual deployment resource, which is technically only a preregistration for deletion. From here, the mechanisms already known today can take effect, in the sense that, for example, a node kubelet recognizes the reservation for deletion and then causes the container flow system to delete the workload, in particular the pod / container.

Examples of adding or removing system resources include adding or removing a hardware network interface, or a local configuration action by a user at an industrial edge, with which he assigns device resources for the cluster or removes them again.

The procedure according to the invention enables the complexity when orchestrating workloads that have to be distributed accordingly by system resources to be significantly reduced. The invention enables a particularly efficient integration into the control plane (control plane) of the industrial cluster. Efficient is to be understood in the sense of the least complex engineering / configuration of the workloads. The workloads that are directly linked to plant resources.

The scheduling of the workloads does not take place at the node level, but at the level of the system resources that are assigned to the (respective) node. Furthermore, the monitoring resources required on the individual working nodes for monitoring system resources can be minimized because the control module takes this over centrally.

Plant resources are in particular resources that belong to the plant or machine or that are assigned to the plant or machine. There are, for example, resources that are each formed by one or more devices, in particular automation devices, and / or one or more other components, in particular other automation components, and / or one or more areas, such as cell networks or the like, of the system or machine or which have one or more devices, in particular automation devices, and / or one or more other components, in particular other automation components, and / or one or more areas of the system or machine. Plant resources can also be present, for example, in the form of plant or device equipment - including software-based equipment.

The fact that a work node has system resources, in particular specific system resources, can in particular mean that it has access to, in particular, specific system resources. Resources assigned to the system or machine, that is to say system resources, can be located directly at the respective node, for example by means of equipment-specific or machine-specific equipment, for example in the form of at least one particular or component assigned to the system or machine or a component thereof related hardware or software elements of the respective node itself are present, and / or also with or on devices / modules / elements / system parts separate from the respective node.

A node can, for example, have system resources (separate from it) because it has access to a device and / or a component and / or an area of the system / machine or with a device and / or a component and / or an area of the system / machine (possibly directly) is connected, which or which or which represents a plant resource or his / her part has plant resources. Examples of system resources that can be present in a system / machine include at least one robot controller and / or at least one memory-programmable controller. A working node can, for example, have access to such components, possibly because the node is directly connected to them. Further examples of system resources include a network card as access, for example, to automation (sub) networks within manufacturing cells or a node-specific service, such as the programming API of a robot controller or the like.

In a particularly preferred embodiment, it is provided that the resource markers that are or will be assigned to the nodes that have system resources each include a first and a second part.

It is further preferred that the first part indicates that the respective node has one or more facilities at its disposal, and the second part lists all the system resources that the respective node has at its disposal. Such a marker structure in particular enables other components or modules of a cluster configuration or orchestration system or tools, such as Kubernetes, for example a resource deployment controller, with the least possible load for the system or Tool to make the system resources from resourceful.

The first part can, for example, be in the form of a “label”, in particular a Kubernetes label, or include one. The first part signals that a certain system resource is available one or more times at a node. In this way, the configuration system of the cluster can decide very efficiently whether and how the control module is to be notified of the presence or absence. The configuration system can do this filter very efficiently on the first part, in particular a label and its (restricted) values, without having to work or have to work with value lists (arrays).

Such a label can be, for example, "cellnetworks" with the empty value ""; the existence of the label is sufficient, but the value is irrelevant because the first part does not (yet) list the specific individual system resources.

The first part makes it possible, in particular, to use a cluster configuration system that does not allow any jokers in the names of Labein, as is usually the case with the previously known systems.

The second part of the (respective) resource marker can, for example, be in the form of an “annotation”, in particular Kubernes annotation, or contain such. The second part of the resource marker preferably lists all system resources, especially since the aforementioned restrictions of known cluster configuration systems do not apply here.

For example, the second part can have the same name as the first, but with a value. In keeping with the aforementioned example of "cellnetworks" with the empty value "" as the first part (label), the second part can also include the name "cellnetworks", for example with the value "ens33p0, ens42p66".

In a further particularly advantageous embodiment, the (respective) resource marker accordingly comprises at least one label, in particular Kubernetes label, and / or at least one annotation, in particular Kubernetes annotation.

A resource marker with a first part in the form of a (Kubernetes) label and a second part in the form of a (Kubernetes) annotation can then read, for example: kind: Node metadata: labels: di.siemens.com/cellnets: "" annotations: di.Siemens.com/cellnets: "ens33p0, ens42p66"

This purely exemplary resource marker could in particular be provided for cluster work nodes which have cell networks as system resources or to which cell networks ("cell nets") are assigned as system resources. Cell networks are to be understood, in a manner previously known from the field of automation technology, in particular for individual production cells or networks / networks of individual production cells, of which an automation system or machine can comprise several.

For one or more other types of system resources, resource markers in particular can then be provided or used which have other designations (belonging to the other resource types) in the first part, in particular labels. Resource markers, which differ in their first parts, in particular in the labels, are preferably used for various types of system resources.

Furthermore, preference was or is assigned to the (respective) resource marker to the nodes having system resources, in that the (respective) resource marker is a proxy element that exists in a cluster configuration for the respective node, in particular a mirror or . Node resource that is or has been allocated. A mirror or node resource can also be referred to as a node resource.

The resource markers can be stored on the representative elements, in particular node resources, for example manually as part of the cluster configuration. be done. Of course, it is also possible for resource markers to be automatically assigned to substitute elements, and resource markers, in particular, to be automatically stored on substitute elements, for example node resources.

An orchestration system, such as Kubernetes, is expediently used to set up the workloads on the at least one suitable node or nodes. The workloads are then preferably set up by the orchestration system in the form of pods and / or containers.

The control module is then preferably in communicative connection with the orchestration system or is part of the orchestration system. The orchestration system can, in particular, based on the at least one workload element generated by the control module, set up associated workloads on the respective at least one matching node. In particular, the workload elements generated by the control module can be automatically recognized by the orchestration system and the necessary workloads, in particular pods and / or containers, can be generated by the orchestration system on the basis of or using the Workload items can be set up on the corresponding nodes.

The control module can be implemented in software or hardware or a combination of software and hardware. For example, at least one control module, in particular in software, can be implemented on at least one of the work nodes.

In a preferred embodiment, the steps of the method according to the invention can be carried out by one or even more, in particular, any working nodes of the cluster. In particular, one or more so- named master nodes, which are preferably purely responsible for cluster orchestration, are in question.

The invention also relates to a cluster work node which is designed and / or set up to carry out the method according to the invention. The cluster work node preferably comprises a control module which is designed and / or set up for this purpose

At least one description element in which workloads are specified that are to be set up on cluster work nodes that have system resources specified in the respective description element, matching accounts, with the respective description element comprising a template, and Evaluate resource markers assigned to cluster nodes and determine whether at least one matching node is available,

- In the event that this is so, to create at least one work load element for setting up workloads on the at least one matching node, where the control module uses the template contained in the at least one description element and in this at least part of the dem inserts at least one resource marker associated with a matching node.

A cluster work node can, for example, be a (separate) device or a (separate) hardware component. Of course, it is also possible for a working node to be present as a "software working node", for example in the form of a computer program or a computer program collection, which is installed on a device designed to execute it, such as a PC or other computing device or any other device.

A working node according to the invention can comprise or be given by at least one virtual machine (VM) be. A work node can, for example, also be integrated into an automation component, such as a controller, or into another device, both in the form of hardware and software. It is also possible that a working node according to the invention is assigned to at least one automation component. A cluster work node can also be provided by or comprise an appropriately set up industrial computer or PC.

The working node is particularly preferably an edge device, in particular an industrial edge device. An edge device is to be understood in particular as a device that performs the or at least one function of edge computing (for edge computing, see e.g. https://de.wikipedia.org/wiki/Edge_Computing). An industrial edge device can be given, for example, by an industrial computer that performs an edge computing function.

The working node according to the invention is designed and / or set up in an advantageous embodiment in order to implement one or more of the preferred features described above. Insofar as the features described above relate to the control module, it applies that the control module is preferably designed and / or set up accordingly. In particular, the cluster work node specified here can also be further developed in accordance with the dependent method claims and vice versa.

Another subject matter of the invention is a cluster comprising one or more working nodes, the cluster being designed and / or set up to carry out the method according to the invention.

The invention also relates, in particular, to an industrial network which comprises at least one cluster working node according to the invention. Another subject matter of the present invention is a computer program comprising program code means which, when the program is executed on at least one computer, cause the at least one computer to carry out the steps of the method according to the invention.

In addition, the invention relates to a computer-readable medium which comprises instructions which, when they are executed on at least one computer, cause the at least one computer to carry out the steps of the method according to the invention.

The computer-readable medium can be, for example, a CD-ROM or DVD or a USB or flash memory. It should be noted that a computer-readable medium should not be understood exclusively as a physical medium, but rather such a medium can also be present, for example, in the form of a data stream and / or a signal that represents a data stream.

Further features and advantages of the present invention who based on the following description of embodiments of the invention with reference to the accompanying drawing voltage clearly. In it is

FIG. 1 shows a purely schematic partial representation of an industrial network with a cluster with several cluster working nodes;

FIG. 2 shows a schematic representation of the sequence of an exemplary embodiment of the method according to the invention; and

FIG. 3 shows a purely schematic partial representation of an industrial network with a cluster with several work accounts, which is operated in the manner according to the invention. FIG. 1 shows a purely schematic partial representation of an industrial network in which several working nodes 1 of a cluster 2 participate. In the present case, the nodes 1 are provided by industrial edge devices, specifically industrial PCs that take on an edge computing function. Alternatively, nodes 1 can also be provided by virtual machines (VMs) that are implemented on a powerful industrial PC with several CPUs or on a blade PC, especially together with other elements and, for example, in an air-conditioned data center, etc.

It should be noted that in the partial illustration only two of the working nodes 1 of the cluster 2 are shown by way of example, and this cluster can have 1 or has further working nodes. In addition, other components can also participate in the industrial network in a manner known per se, or take part in a manner known per se, such as automation components in the form of controls such as PLCs, IO devices, HMI panels and so on.

Each of the two working nodes 1 shown is connected to one or more cell networks 3.

On the node 1, work loads are to be set up for each of the cell networks 3, specifically in the form of containers 4, which in the illustrated embodiment relate to virtual network functions or to implement virtual network functions.

This can in principle be mapped with the mechanisms known from general IT. However, according to the applicant, this results in a comparatively high installation and maintenance effort. Specifically, for each of the workloads to be set up that differ (slightly) from one another, a separate detailed configuration is required in the present case, in particular for each container 4 on the cluster control level 5, a workload element 6, for example in the form of a deployment, based on which a Orchestration system 7, like like Kubernetes, which can set up workloads 4 on node 1. The (slight) difference can, for example, be due to the fact that two different network interfaces are affected.

In FIG. 1, the individual workload elements are shown schematically in the form of Kubernetes deployments 6 next to a container repository 8. Such a repository 8 is, in particular, a set of images of the same name with different tags, mostly versions. Images are, in particular, memory dumps of a container. An image is usually portable, can be saved in repositories 8 and shared with other users. Several containers can always be started from one image. For images and repositories, see, for example, https: //de.wikipedia .org / wiki / Docker_ (software)). It should be noted that in FIG. 1 (exactly as in FIG. 3) the cluster control plane is shown above the solid line.

A simplified and at least partially automatic set-up and adaptation to the actual system configuration can be made possible via the procedure according to the invention.

For this purpose, a control module 9 and one or more description elements 10 are used, which are only shown in FIG. 1 and there purely schematically. The nodes 1 are also provided with resource markers 11.

In the exemplary embodiment shown, the control module 9 is implemented on one of the nodes of the cluster 2, specifically on a master node 12 (see FIG. 2) of the cluster 2. In the present case, the master node 12 is solely responsible for cluster orchestration. The orchestration system 7 or possibly a part, in particular in software, can also be implemented on this. It should be noted that the orchestration system 7 is generally distributed over several (possibly all) nodes 1, both to master nodes and to arrangement beitsknoten 1. As a rule, not all functions of the orchestration system 7 are available on all nodes.

Even if the orchestration system 7 is implemented on several nodes, specifically distributed over several nodes, the purely schematic FIG. 1 shows a single block element as a representative for this.

It should also be noted that the control module 9 can be part of the orchestration system 7, but does not have to be. It can also be ready for the orchestration system 7, but then it is expediently in communicative connection with it.

In the one or in the case of several in the respective descriptive element 10, workloads 4 are specified that are to be set up on nodes 1 that have system resources 3 specified in the respective descriptive element 10 (matching accounts 1). The respective description element 10 comprises a template 13 for the workloads 4 to be prepared.

It should be emphasized that even if only one descriptive element 10 is shown by way of example in FIG. 2, several descriptive elements 10 can of course also be provided. In the event that several description elements 10 are provided, each of the description elements 10 appropriately relates to or describes a different type of workload 4. Examples of different types of workloads 4 are a software PLC, a software robot controller Called software IT router.

The description element or elements 10 can also be referred to or understood as so-called “Plant Resource Deployment Resources” or RDRs for short. The description element or elements 10 are or will be provided in particular in the cluster configuration on the cluster control level. The control module can also be referred to as a resource deployment controller or RDC for short. A part of the respective descriptive element 10 is given by the template 13 or template for the workloads 4 to be generated. Another part expediently describes or specifies the required or associated system resources. In the present case, the system resources are given in the (respective) description element 10 in the form of expected resource markers 11 or in the form of expected parts of resource markers 11.

An example of a description element (RDRs) 10 is: kind: di.Siemens.com/ResourceDeployment metadata: name: nat64 spec: matchResource: di.Siemens.com/cellnets template:

# pod template for plant (equipment) resource containers:

- name: nat64 args: ["/ bin / nat64", "-i", "{di.Siemens.com/cellnets:i}"]

According to this, (virtual) NAT64 routers can be set up on all those cluster working nodes 1 that have cell networks 3 as system resources or to which such resources are assigned. The workloads 4 to be set up in this example are virtual network functions, specifically virtual NAT64 router functions in the form of containers 4.

The part beginning with “template” in the above example is the template 13 for the workloads 4 to be set up. With regard to the matching, it applies that in the event that a resource for a working node 1 fits into the grid if it has the label (s) listed below. Then the template 13 is "executed" one after the other with all the values of the annotation assigned to the label, that is to say the corresponding deployments are generated.

The resource markers 11 are presently provided in the cluster configuration or are stored in this. Specifically, the (respective) resource marker 11 is or was assigned to the node 1 having system resources 3, by the (respective) resource marker 11 in a proxy element 14 present in the cluster configuration for the respective node 1 Form of a node resource (English: node resource) is or has been assigned. The resource markers 11 can be assigned manually or automatically.

In FIG. 2, the cluster control level with elements of the cluster configuration shown schematically is shown above the dashed line. The master node 12 and two further nodes 1 of the cluster 2 are shown by way of example below the dashed line. As a rule, there is such a substitute element in the form of a node or node resource 14 for each of the nodes 1 of the cluster 2. In FIG. 2, only one node resource 14 is shown by way of example, which represents a substitute for the in Figure 2 forms node 1 shown in the center below. A dashed double arrow between the node resource 14 shown as an example and the central node 1 shows this relationship by way of example. It should be noted that the arrows with solid lines in FIG. 2 symbolize a flow of data in contrast to a mere relationship.

The resource markers 11, which are or will be assigned to the node 1 having system resources 3, specifically their representatives 14, each include a first and a second part 11a, 11b in the present case. The first part 11a of the respective resource marker 11 indicates that the respective node 1 has a specific system resource 3 one or more times, and the second part 11b lists all the system resources 3 that the respective node 1 actually has, on.

In the example shown, the first part 11a is in the form of a “label”, specifically a Kubernetes label 11a. Since the first part 11a signals that a certain system resource 3 is available one or more times at a node 1, the orchestration system 7 of the cluster 2 (can also be referred to as a configuration system) can decide very efficiently whether and how the control module is 9 is to be notified of the presence or absence. The orchestration system 7 can here very efficiently filter on the first part, in the present case the label and its (restricted) values, without it having to work or have to work with lists of values (arrays).

Such a label 11a can be, for example, “cellnetworks” with the empty value “”; the existence of the label 11a is sufficient here, but the value is irrelevant since the specific individual system resources 3 are not (yet) listed with the first part 11a.

The first part 11a makes it possible, in particular, to use a cluster orchestration system 7 which does not allow any Jo ker in the name of Labein, as is usually the case with the systems 7 known above.

The second part 11b of the (respective) resource marker 11 is given in the present case by an “annotation”, specifically Kubernetes annotation. The second part 11b of the resource marker 11 lists all the system resources 3, in particular since the aforementioned restrictions of known cluster configuration systems do not apply here. In the example shown, the second part 11b has the same name as the first, but with a value. Matching the aforementioned example of “cellnetworks” with the empty value “” as the first part 11a (label), the second part 11b can also include the name “cellnetworks”, for example with the value “ens33p0, ens42p66”.

A resource marker 11 with a first part 11a in the form of a (Kubernetes) label and a second part 11b in the form of a (Kubernetes) annotation can read, for example: kind: Node metadata: labels: di.siemens.com/cellnets: "" annotations: di.Siemens.com/cellnets: "ens33p0, ens42p66"

This resource marker 11 is provided for cluster work nodes 1 which have cell networks 3 as system resources or to which cell networks 3 (“cellnets”) are assigned as system resources. Cell networks are to be understood as meaning, in a manner previously known from automation technology, in particular individual production cells or networks / networks of individual production cells, of which an automation system or machine can comprise several

The control module 9 is designed and / or set up to automatically evaluate the at least one provided description element 10 and the resource markers 11 assigned to cluster nodes 1 and to determine whether at least one suitable node is available, and in the event that the so is to create at least one workload element 15 for the establishment of workloads 4 on the at least one matching node 1. For this purpose, the control module 9 uses the template 13, which is contained in the at least one descriptive element 10. It adds at least a part, in this case a value 16, of the resource marker 11 of the (respective) matching node 1 in the template 13 to get the load element 15 work. In the present case, workload elements in the form of so-called pod resources 15, PRs for short, are generated for the matching node or nodes 1.

In other words, an essential task of the control module 9 is to replace parts of the (respective) template 13 with specific information about individual system resources 3 in order to obtain the final workload elements 15, in particular PRs or deployments. This information preferably comes from the resource markers 11 on the work nodes 1 or on their representatives 14 in the cluster configura tion.

The workload element (s) 15 generated by the control module 9 can then be automatically recognized by the orchestration system 7 and the necessary workloads 4 in the form of pods or containers can be provided by the orchestration system 7 on the basis of or using the or the Arbeitslastele elements 15 are set up on the corresponding node 1. In FIG. 2, this process is indicated schematically by the dashed double arrows which each connect a pod resource 15 to a container 4 set up on node 1.

The control module 9 preferably carries out its activity permanently. The evaluation of the description element (s) 10 and the resource marker (s) 11 can, for example, take place cyclically.

In the present case, the control module 9 not only ensures that new workloads 4 are set up for newly added system resources 3, but also removes again those workloads 4 whose (associated) system resources 3 have been removed. In other words, it implements a kind of "clean-up mechanism". Examples of adding or removing system resources include adding or removing a hardware network interface, or a local configuration action by a user on an industrial edge, with which he assigns device resources for cluster 2 or removes them again.

The described procedure according to the invention enables the automatic scheduling of workloads (for example in the form of pods / containers) on the basis of system resources. The complexity when orchestrating workloads 4, which must be distributed accordingly by system resources 3, can be significantly reduced. A particularly efficient integration into the control plane of industrial cluster 2 is made possible. The scheduling of the workloads 4 does not take place at the node level, but rather at the level of the system resources 3 that are assigned to the node 1 (in each case). The monitoring resources required on the individual work nodes 1 for monitoring system resources 3 can be minimized.

The previous many individual detailed configurations for many slightly different workloads 4 are omitted and can be replaced by a common configuration in the form of the description element 10. According to the prior art, as shown purely schematically in FIG. 1, many individual deployment resources 6 (corresponding to pod resources, since there is a 1: 1 assignment between deployments and pods) individually. If the system resources change, the deployment resources 6 previously had to be updated manually.

The invention simplifies the many deployment resources 6, ideally into a single description element 10, for example a single installation resource deployment resource, which is now very easy to maintain. When adding (matching / matching) system resources, the control module tracks the individual workload elements 15, in particular pods / deployments, which are derived from the one, unchanged system resource deployment resource. This is shown purely schematically in FIG. It should be noted that the master node 12 comprising the control module 9 is an exemplary embodiment of a cluster work node according to the invention, which is designed and / or set up to carry out the method according to the invention. The control module 9 can be implemented on this in software.

The cluster 2 comprising the master node 12 and the further nodes 1 is also an exemplary embodiment of a cluster 2 according to the invention, which is designed and / or set up to carry out the method according to the invention.

The industrial network shown is an exemplary embodiment of a network according to the invention.

Although the invention has been illustrated and described in more detail by the preferred exemplary embodiment, the invention is not restricted by the examples disclosed and other variations can be derived therefrom by the person skilled in the art without departing from the scope of protection of the invention.

Claims

1. A method for operating a cluster (2) which is connected to an industrial network of a plant or machine, with working nodes (1) of the cluster (2) having resources of the plant or the machine, plant resources (3), available at the

- A resource marker (11) is or is assigned to each node having system resources (3), the respective resource marker (11) indicating or being able to be derived from the respective resource marker (11) via which system resources (3) the respective node (1) has,

- At least one descriptive element (10) is available or is provided, in which workloads (4) are given that are to be set up on nodes (1) that have system resources (3) specified in the respective descriptive element (10) Accounts (1), wherein the or each descriptive element (10) comprises a template (13),

- A control module (9), on the one hand, evaluates the at least one description element (10) and, on the other hand, the resource marker (11) assigned to the node (1) of the cluster (2) and determines whether at least one matching node (1) is present,

- The control module (9) in the event that this is the case, at least one workload element (15) for setting up workloads (4) on the at least one pas send node (1), the control module (9) for this purpose is used in the at least one description element (10) contained template (13) and inserts at least part of the resource marker (11) assigned to the at least one matching node (1) into it.

2. The method according to claim 1, characterized in that a plurality of description elements (10) are available or are made available, in each of which workloads (4) are specified which are to be set up on nodes (1) which are in the respective description element (10) specified system resources (3) have, respectively matching accounts (1), wherein the respective description element (10) comprises a template (13), and each description element (10) relates to a different type of workload (4).

3. The method according to claim 1 or 2, characterized in that an orchestration system (7) is used to set up the work loads (4) on the or the at least one matching node (1), the control module (9 ) is in communicative connection with the orchestration system (7) or is part of the orchestration system (7), and the orchestration system (7) is based on the at least one workload element (15) generated by the control module (9) ) sets up associated workloads (4) on the or at least one matching node (1).

4. The method according to any one of the preceding claims, characterized in that the at least one workload element (15) created by the control module (9) relates to at least one workload (4) in the form of a container and / or pod.

5. The method according to any one of the preceding claims, characterized in that the at least one workload element (15) created by the control module (9) relates to at least one workload (4) in the form of a virtual network function.

6. The method according to any one of the preceding claims, characterized in that in the or the respective description element (10) the system resources (3) in the form of expected resource marks (11) or in the form of expected parts of resource marks (11 ) are specified.

7. The method according to any one of the preceding claims, characterized in that the resource markers (11) which are or will be assigned to the nodes (1) having system resources (3), each Weil a first and a second part (11a, 11b ) include.

8. The method according to claim 7, characterized in that the first part (11a) indicates that the respective node (1) has a certain system resource (3) one or more times, and the second part (11b) all system resources (3 ) that the respective node (1) has at its disposal.

9. The method according to any one of the preceding claims, characterized in that the system resources (3) having the node (1) of the resource marker (11) was or is assigned by the resource marker (11) one in a cluster configuration representative element (14) present for the respective node (1), in particular a node resource, is or has been assigned.

10. The method according to any one of the preceding claims, characterized in that in the event that at least one working node (1) to location resources (3) are omitted, from the control module (9) we at least one for the at least one affected node (1) established workload (4) is removed again.

11. Cluster working node (12) which is designed and / or set up to carry out the method according to one of the preceding claims.

12. Cluster working node (12) according to claim 11, characterized in that the node comprises a control module (9) which is designed and / or set up for this purpose

- At least one descriptive element (10) in which workloads (4) are specified that are to be set up on cluster work nodes (1) that have system resources (3) specified in the respective description element (10), matching accounts ( 1), where the description element (10) comprises a template (13), and cluster nodes (1) to evaluate assigned resource markers (11) and to determine whether there is at least one matching node (1) which is

- In the event that this is the case, at least one work load element (15) for setting up workloads (4) on the at least one matching node (1) to be provided, the control module (9) for this purpose in the at least one The template (13) contained in the description element (10) is used and at least part of the resource marker (11) assigned to the at least one matching node (1) is inserted into it.

13. Cluster (2) comprising one or more working nodes

(1, 12), the cluster (2) being designed and / or set up to carry out the method according to one of claims 1 to 10.

14. Network comprising at least one working node (1, 12) according to one of claims 11 to 13.

15. A computer program comprising program code means which, when the program is executed on at least one computer, cause the at least one computer to carry out the steps of the method according to one of claims 1 to 10.

16. A computer-readable medium comprising instructions which, when executed on at least one computer, cause the at least one computer to perform the steps of the method according to any one of claims 1 to 10.