Clustermangement no PLCnext?

Um padrão em TI há anos, ainda não causou muito impacto na indústria. Muitas vezes, essas tecnologias são vistas como
demasiado complexo e desnecessário. A pergunta que se coloca é, eles nos trazem vantagens?

Uma visão para o PLCnext usando o exemplo do Kubernetes.

Kubernetes

Kubernete é um orquestrador (sistema de gestão, master) que utiliza, entre outras coisas, containers e assim forma uma rede através de diversos dispositivos. O sistema é usado para fornecer aplicativos de uma maneira ligeiramente diferente.

Classicamente, os aplicativos seriam distribuídos e mantidos em dispositivos. Sabe-se em qual computador o aplicativo é executado. Se um aplicativo deve ser executado em outro computador, isso deve ser feito por uma pessoa. Se um dos computadores falhar, todos os aplicativos do computador não estarão mais disponíveis.

Com o Kubernetes, o mestre recebe uma descrição do estado do aplicativo e o mestre cuida do resto. Ele garante que o estado solicitado seja mantido em todos os momentos. No entanto, não se sabe em qual nó o aplicativo está sendo executado no momento, mas é acessível em princípio.

Perguntas e respostas

O que deplora a descrição da condição

• A descrição do estado é a base de todas as aplicações. Ele contém, por exemplo, qual contêiner é usado em qual versão ou se um aplicativo deve ser iniciado várias vezes para balanceamento de carga. Está escrito completamente em forma de texto como json ou yaml  Arquivo. Portanto, é totalmente versionável (por exemplo, Git ou SVN).

Como instalar o cluster

• Os participantes (mestre e nós) devem receber dois componentes de software (container runtime e Kubernetes). Depois disso, é necessário apenas um login via token para o mestre. O resto é feito pelo mestre.

Como realizar atualizações de aplicativos

• Uma atualização é simplesmente substituir a descrição do estado de um aplicativo por um novo. A atualização é feita em tempo real, o que significa que o novo aplicativo é instalado e iniciado e, no último momento, o aplicativo antigo é encerrado. Se uma atualização falhar, uma reversão pode ser executada e o estado antigo pode simplesmente ser restaurado. O orquestrador mantém todos os estados antigos. Além disso, existe a possibilidade do versionamento descrito das condições.
• Novas possibilidades de cenários de atualização surgem aqui. Se um aplicativo for executado com frequência em um cluster, por exemplo, apenas alguns dos aplicativos poderão ser atualizados primeiro. Se nenhum erro ocorrer no aplicativo após alguns dias ou semanas de testes, o restante poderá ser atualizado.

O que acontece se um nó falhar

• Se a qualquer momento um nó falhar, todos os aplicativos serão disponibilizados em outro nó. A acessibilidade continua a mesma. Enquanto houver poder de computação suficiente, todos os aplicativos podem continuar em execução. Há muita discussão sobre um servidor MQTT, que como componente central causa muitos problemas em caso de falha, mas em um cluster não é um problema.

O que acontece se o mestre falhar

• Os mestres também podem ser executados de forma redundante, uma vez que um nó falhe, outro nó pode assumir o trabalho.

Certos aplicativos precisam ser executados em determinados nós porque o acesso ao hardware é necessário.

• Isso pode ser incluído nas descrições de estado. Os estados também podem ser atribuídos com base em tags que pertencem aos dispositivos. Por exemplo, cada AXCF2152 deve estar executando um determinado aplicativo. Para pegar o exemplo MQTT novamente, existe um servidor MQTT que é executado na federação, além disso, cada nó pode ser equipado com um cliente MQTT para estabelecer uma comunicação com o servidor MQTT. O mestre existe apenas uma vez, o cliente é executado em cada nó.

Exemplo

Exemplo de descrição de estado de uma aplicação que consiste em três containers (frontend, backend, database).

Implantação:

• Define todas as configurações necessárias para os contêineres.

Serviço:

• Cria uma interface para o aplicativo centralmente no cluster. A interface é sempre válida, independentemente do nó em que a implantação está sendo executada.

Entrada:

• Vincula a interface ao front-end usando uma entrada DNS. Assim, o front-end está sempre acessível em um domínio.
• Proxy http://MyApp.MyDomain.de/ para o serviço de front-end (Porta 80)
• Proxy http://MyApp.MyDomain.de/api para o serviço de back-end (porta 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

Dê uma olhada

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