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.
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
yamlfile. 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 of a state description of an application that consists of three containers (frontend, backend, database).
- Defines all the necessary settings for the containers.
- Creates an interface to the application centrally in the cluster. The interface is always valid no matter which node the deployment is running on.
- 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
## Container specs
## Container spec for Frontend
## Name for the Container
- name: MyContainer-frontend
## Container Image to use
## Ports for the frontend, http
- containerPort: 80
## Container spec for Backend
- name: MyContainerName-backend
- containerPort: 3000
## Container spec for mongodb
- name: MyContainerName-mongo
## Startup commands for Mongo DB
- containerPort: 27017
## Service declaration, expose Ports to the kubernetes api (only internal rechable)
- name: frontend
- name: backend
## Ingress declaration, bind proxy to fronted and backend
## Bind ingress to traefik service proxy
## Ingress class for frontend, map dns ingress to service port 80
- host: MyApp.Mydomain.de
- path: /
## Ingress class for backend, map dns ingress to service port 3000
- host: MyApplicationName.MyDomain.de
- path: /api
Take a look
Leave a Reply
You must be logged in to post a comment.