Управление кластерами на PLCnext: Использование Kubernetes для промышленной автоматизации

Стандарт в IT уже годами, но в промышленности он еще не произвел большого воздействия. Часто такие технологии считаются слишком сложными и ненужными. Вопрос, который возникает: приносят ли они нам преимущества?

Видение для PLCnext на примере Kubernetes.

Kubernetes

Kubernetes — это оркестратор (система управления, мастер), который использует, среди прочего, контейнеры и таким образом формирует сеть через различные устройства. Система используется для предоставления приложений немного иначе.

Классически приложения распределялись и поддерживались на устройствах. Известно, на каком компьютере запущено приложение. Если приложение должно запуститься на другом компьютере, это должен сделать человек. Если один из компьютеров выходит из строя, все приложения этого компьютера больше недоступны.

С Kubernetes мастеру дается описание состояния приложения, и мастер заботится обо всем остальном. Он обеспечивает поддержку запрошенного состояния постоянно. Однако неизвестно, на какой ноде приложение сейчас запущено, но оно в принципе доступно.

Вопросы и ответы

Что описывает описание состояния

• Описание состояния — основа каждого приложения. Оно содержит, например, какой контейнер используется в какой версии или должно ли приложение запускаться несколько раз для балансировки нагрузки. Оно написано полностью в текстовом виде как json или yaml файл. Поэтому оно полностью версионируемо (например, Git или SVN).

Как установить кластер

• Участники (мастер и ноды) должны быть снабжены двумя программными компонентами (container runtime и Kubernetes). После этого нужен только один вход через токен к мастеру. Остальное делает мастер.

Как выполнять обновления приложений

• Обновление — это просто замена описания состояния приложения на новое. Обновление выполняется на лету (on the fly), то есть новое приложение сначала устанавливается и запускается, и в последний момент старое приложение выключается. Если обновление проваливается, можно выполнить откат (rollback) и старое состояние просто восстанавливается. Оркестратор хранит все старые состояния. Кроме того, существует возможность описанного версионирования состояний.
• Здесь возникают новые возможности сценариев обновления. Если приложение часто запускается в кластере, например, можно сначала обновить только некоторые из приложений. Если через несколько дней или недель тестов в приложении не возникает ошибок, остальные можно обновить.

Что происходит, если нода выходит из строя

• Если в любой момент нода выходит из строя, все приложения просто делаются доступными на другой ноде. Доступность остается той же. Пока достаточно вычислительной мощности, все приложения могут продолжать работать. Много обсуждается про MQTT-сервер, который как центральный компонент вызывает много проблем в случае отказа, но в кластере это не проблема.

Что происходит, если мастер выходит из строя

• Мастера также могут запускаться избыточно, если один выходит из строя, другая нода может взять работу на себя.

Определенные приложения должны запускаться на определенных нодах, потому что нужен доступ к железу.

• Это можно включить в описания состояний. Состояния также могут назначаться на основе тегов, принадлежащих устройствам. Например, каждый AXCF2152 должен запускать определенное приложение. Вернемся к примеру MQTT: есть MQTT-сервер, запущенный в федерации, кроме того, каждая нода может быть оснащена MQTT-клиентом для установки коммуникации с MQTT-сервером. Мастер существует только один, клиент запускается на каждой ноде.

Пример

Пример описания состояния приложения, состоящего из трех контейнеров (frontend, backend, database).

Deployment:

• Определяет все необходимые настройки для контейнеров.

Service:

• Создает интерфейс к приложению централизованно в кластере. Интерфейс всегда действителен, независимо от того, на какой ноде запущен deployment.

Ingress:

• Связывает интерфейс с frontend используя DNS-запись. Так frontend всегда доступен на одном домене.
• Proxy https://MyApp.MyDomain.de/ к frontend service (Port 80)
• Proxy https://MyApp.MyDomain.de/api к 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 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

Посмотрите

• Kubernetes kubeadm cluster creation
• k3s
• k3d
• k3x