PLCnext 上的集群管理？
多年来，它一直是 IT 行业的标准，但尚未对行业产生太大影响。这些技术通常被视为
太复杂和不必要。随之而来的问题是，它们能给我们带来优势吗？
以 Kubernetes 为例对 PLCnext 的愿景。
Kubernetes
Kubernetes 是一个编排器（管理系统，主控系统），它使用容器等，从而通过各种设备形成网络。该系统用于以稍微不同的方式提供应用程序。
经典应用程序将在设备上分发和维护。知道应用程序在哪台计算机上运行。如果应用程序应该在另一台计算机上运行，则必须由人来完成。如果其中一台计算机出现故障，则该计算机的所有应用程序都将不再可用。
在 Kubernetes 中，master 获得了应用程序的状态描述，master 负责其余的工作。它确保始终保持请求的状态。不过目前不知道应用在哪个节点上运行，但原则上是可以访问的。
问答
什么痛惜条件描述
- 状态描述是每个应用程序的基础。例如，它包含在哪个版本中使用哪个容器，或者是否应该多次启动应用程序以进行负载平衡。它完全以文本形式编写为
json或yaml文件。因此它是完全版本化的（例如 Git 或 SVN）。
如何安装集群
- 必须为参与者（主节点和节点）提供两个软件组件（容器运行时和 Kubernetes）。之后，只需要通过令牌登录到主服务器。其余的由主人完成。
如何执行应用程序的更新
- 更新只是将应用的状态描述替换为新的。更新是即时完成的，这意味着首先安装并启动新应用程序，最后关闭旧应用程序。如果更新失败，可以执行回滚并且可以简单地恢复旧状态。编排器保留所有旧状态。此外，还存在所描述的条件版本控制的可能性。
- 这里出现了更新场景的新可能性。例如，如果一个应用程序在集群中运行频繁，那么一开始只能更新部分应用程序。如果经过几天或几周的测试后应用程序没有出现错误，则可以更新其余部分。
如果一个节点发生故障会发生什么
- 如果任何时候某个节点出现故障，所有应用程序都可以简单地在另一个节点上可用。可访问性保持不变。只要有足够的计算能力，所有应用程序都可以继续运行。有很多关于 MQTT 服务器的讨论，它作为一个中心组件在发生故障时会导致很多问题，但在集群中它不是问题。
如果 master 失败了会发生什么
- 主节点也可以冗余运行，一旦一个节点出现故障，另一个节点可以接管这项工作。
某些应用程序需要在某些节点上运行，因为需要访问硬件。
- 这可以包含在状态描述中。状态也可以基于属于设备的标签来分配。例如，每个 AXCF2152 都必须运行特定的应用程序。再回到 MQTT 的例子，有一个 MQTT 服务器运行在联邦中，而且每个节点都可以配备一个 MQTT 客户端来建立与 MQTT 服务器的通信。主节点只存在一次，客户端运行在每个节点上。
示例
由三个容器（前端、后端、数据库）组成的应用程序状态描述示例。
部署：
- 定义容器的所有必要设置。
服务：
- 在集群中集中创建一个到应用程序的接口。无论部署在哪个节点上运行，该接口始终有效。
入口：
- 使用 DNS 条目将接口链接到前端。因此，前端始终可以在一个域上访问。
- 代理 http://MyApp.MyDomain.de/ 到前端服务（端口 80）
- 代理 http://MyApp.MyDomain.de/api 到后端服务（端口 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
看看
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
工业技术