Gerenciamento de Cluster no PLCnext: Aproveitando Kubernetes para Automação Industrial

Padrão em TI há anos, ainda não causou grande impacto na indústria. Frequentemente tais tecnologias são vistas como complexas e desnecessárias. A questão: trazem vantagens?

Visão para PLCnext usando Kubernetes como exemplo.

Kubernetes

Kubernetes é orquestrador (sistema de gestão, master) que usa containers e forma rede via vários dispositivos. Sistema usado para prover aplicações de forma diferente.

Classicamente, aplicações seriam distribuídas e mantidas em dispositivos. Sabe-se em qual computador a aplicação roda. Se deve rodar em outro, pessoa deve fazer. Se computador falha, todas aplicações ficam indisponíveis.

Com Kubernetes, o master recebe descrição de estado da aplicação, e cuida do resto. Garante que estado solicitado seja mantido sempre. Não se sabe em qual nó a aplicação roda, mas é acessível em princípio.

Perguntas e respostas

O que é descrição de estado

• Base de toda aplicação. Contém ex: qual container em qual versão, se aplicação deve rodar múltiplas vezes para load balancing. Escrita totalmente em texto como json ou yaml. Totalmente versionável (ex: Git ou SVN).

Como instalar cluster

• Participantes (master e nodes) devem receber dois componentes (container runtime e Kubernetes). Depois, apenas login via token no master. O resto o master faz.

Como atualizar aplicações

• Atualização é simplesmente substituir descrição de estado por nova. Feita on-the-fly: nova aplicação instalada e iniciada, no último momento antiga desligada. Se falhar, rollback restaura estado antigo. Orquestrador mantém todos estados antigos. Além da versionagem descrita.
• Novos cenários de update: se aplicação roda frequentemente no cluster, pode atualizar apenas algumas primeiro. Se sem erros após dias/semanas, atualiza o resto.

O que acontece se node falha

• Se node falha, todas aplicações ficam disponíveis em outro node. Acessibilidade mantida. Enquanto houver poder computacional, todas rodam. Discute-se sobre servidor MQTT como componente central causador de problemas se falha, mas em cluster não é problema.

O que acontece se master falha

• Masters também podem rodar redundantemente; se um falha, outro node assume.

Certas aplicações precisam rodar em certos nodes por acesso a hardware

• Incluído nas descrições de estado. Estados também atribuídos baseados em tags dos dispositivos. Ex: cada AXCF2152 deve rodar certa aplicação. Retomando MQTT: servidor MQTT roda na federação, cada node equipado com cliente MQTT para comunicação. Master existe uma vez, cliente roda em cada node.

Exemplo

Exemplo de descrição de estado de aplicação com três containers (frontend, backend, database).

Deployment: Define configurações necessárias para containers.

Service: Cria interface para aplicação centralmente no cluster. Interface sempre válida independentemente do node do deployment.

Ingress: Liga interface ao frontend via entrada DNS. Frontend sempre alcançável no mesmo domínio.

• Proxy https://MyApp.MyDomain.de/ para frontend service (Port 80)
• Proxy https://MyApp.MyDomain.de/api para 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 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

Veja também

• Create cluster kubeadm
• k3s
• k3d
• k3x