PLCnextでのクラスタ管理?
何年もの間 IT の標準でしたが、業界にはまだ大きな影響を与えていません。多くの場合、そのような技術は次のように見られます。
複雑すぎて不必要です。発生する問題は、それらが私たちに利点をもたらすかということです.
Kubernetes の例を使用した PLCnext のビジョン。
Kubernetes
Kubernetes は、特にコンテナーを使用して、さまざまなデバイスを介してネットワークを形成するオーケストレーター (管理システム、マスター) です。このシステムは、少し異なる方法でアプリケーションを提供するために使用されます。
従来、アプリケーションはデバイス上で配布および管理されていました。アプリケーションが実行されているコンピューターはわかっています。アプリケーションを別のコンピューターで実行する必要がある場合、これは人が実行する必要があります。コンピューターの 1 つに障害が発生すると、そのコンピューターのすべてのアプリケーションが使用できなくなります。
Kubernetes では、マスターにアプリケーションの状態の説明が与えられ、残りはマスターが処理します。要求された状態が常に維持されるようにします。ただし、アプリケーションが現在どのノードで実行されているかは不明ですが、原則としてアクセス可能です。
質問と回答
状態の説明を嘆くもの
- 状態の説明は、すべてのアプリケーションの基礎です。たとえば、どのコンテナーがどのバージョンで使用されているか、または負荷分散のためにアプリケーションを複数回起動する必要があるかどうかが含まれます。
jsonのように完全にテキスト形式で書かれています。 またはyamlファイル。したがって、完全にバージョン管理可能です (Git や SVN など)。
クラスターのインストール方法
- 参加者 (マスターとノード) には、2 つのソフトウェア コンポーネント (コンテナー ランタイムと Kubernetes) を提供する必要があります。その後、トークンを介してマスターに 1 回ログインするだけで済みます。残りはマスターによって行われます。
アプリケーションの更新方法
- 更新とは、単にアプリケーションの状態の説明を新しいものに置き換えることです。更新はオンザフライで行われます。つまり、新しいアプリケーションが最初にインストールされて開始され、最後の瞬間に古いアプリケーションがシャットダウンされます。更新が失敗した場合は、ロールバックを実行して古い状態を簡単に復元できます。オーケストレーターはすべての古い状態を保持します。さらに、記述された条件のバージョン管理の可能性が存在します。
- ここで更新シナリオの新しい可能性が生まれます。たとえば、アプリケーションがクラスターで頻繁に実行される場合、最初は一部のアプリケーションしか更新できません。数日または数週間のテストの後、アプリケーションでエラーが発生しない場合は、残りを更新できます。
ノードに障害が発生した場合
- ノードに障害が発生した場合はいつでも、すべてのアプリケーションが別のノードで利用できるようになります。アクセシビリティは同じままです。十分な計算能力が利用可能である限り、すべてのアプリケーションを実行し続けることができます。 MQTT サーバーについては多くの議論があります。中央コンポーネントとして、障害が発生した場合に多くの問題を引き起こしますが、クラスターでは問題になりません。
マスターに障害が発生した場合
- マスターは冗長的に実行することもできます。1 つに障害が発生すると、別のノードがジョブを引き継ぐことができます。
ハードウェアへのアクセスが必要なため、特定のアプリケーションを特定のノードで実行する必要があります。
- これは状態の説明に含めることができます。デバイスに属するタグに基づいて状態を割り当てることもできます。例として、各 AXCF2152 は特定のアプリケーションを実行している必要があります。再び MQTT の例を取り上げると、フェデレーションで実行される MQTT サーバーがあり、さらに各ノードには MQTT サーバーとの通信を確立するための MQTT クライアントを装備できます。マスターは一度だけ存在し、クライアントは各ノードで実行されます。
例
3 つのコンテナー (フロントエンド、バックエンド、データベース) で構成されるアプリケーションの状態記述の例。
導入:
- コンテナに必要なすべての設定を定義します。
サービス:
- アプリケーションへのインターフェースをクラスタ内で一元的に作成します。デプロイが実行されているノードに関係なく、インターフェースは常に有効です。
イングレス:
- DNS エントリを使用してインターフェイスをフロントエンドにリンクします。したがって、フロントエンドは常に 1 つのドメインで到達可能です。
- 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
産業技術