Clustermanagement di PLCnext?
Standar TI selama bertahun-tahun, belum membuat banyak dampak di industri. Seringkali teknologi seperti itu dilihat sebagai:
terlalu rumit dan tidak perlu. Pertanyaan yang muncul adalah, apakah mereka memberi kita keuntungan?
Visi untuk PLCnext menggunakan contoh Kubernetes.
Kubernet
Kubernete adalah orkestra (sistem manajemen, master) yang menggunakan, antara lain, wadah dan dengan demikian membentuk jaringan melalui berbagai perangkat. Sistem ini digunakan untuk menyediakan aplikasi dengan cara yang sedikit berbeda.
Aplikasi klasik akan didistribusikan dan dipelihara pada perangkat. Diketahui di komputer mana aplikasi berjalan. Jika aplikasi harus dijalankan di komputer lain, ini harus dilakukan oleh seseorang. Jika salah satu komputer gagal, semua aplikasi komputer tidak lagi tersedia.
Dengan Kubernetes, master diberikan deskripsi status aplikasi, dan master menangani sisanya. Ini memastikan bahwa status yang diminta dipertahankan setiap saat. Namun, tidak diketahui di node mana aplikasi sedang berjalan, tetapi pada prinsipnya dapat diakses.
Pertanyaan dan jawaban
Apa yang disayangkan deskripsi kondisi
- Deskripsi status adalah dasar dari setiap aplikasi. Ini berisi misalnya wadah mana yang digunakan dalam versi mana atau jika aplikasi harus dimulai beberapa kali untuk penyeimbangan beban. Itu ditulis lengkap dalam bentuk teks sebagai
json
atau yaml
mengajukan. Oleh karena itu, ini sepenuhnya dapat diversi (mis. Git atau SVN).
Cara memasang kluster
- Peserta (master dan node) harus dilengkapi dengan dua komponen perangkat lunak (runtime container dan Kubernetes). Setelah itu, hanya diperlukan satu login melalui token ke master. Sisanya dilakukan oleh master.
Cara melakukan pembaruan aplikasi
- Pembaruan hanya mengganti deskripsi status aplikasi dengan yang baru. Pembaruan dilakukan dengan cepat, itu berarti aplikasi baru pertama kali diinstal dan dimulai dan pada saat terakhir aplikasi lama dimatikan. Jika pembaruan gagal, rollback dapat dijalankan dan status lama dapat dengan mudah dipulihkan. Orkestra menyimpan semua status lama. Selain itu, kemungkinan adanya versi kondisi yang dijelaskan.
- Kemungkinan baru skenario pembaruan muncul di sini. Jika sebuah aplikasi sering berjalan dalam sebuah cluster, misalnya, hanya beberapa aplikasi yang dapat diupdate terlebih dahulu. Jika tidak ada kesalahan yang terjadi pada aplikasi setelah beberapa hari atau minggu pengujian, sisanya dapat diperbarui.
Apa yang terjadi jika sebuah node gagal
- Jika suatu saat sebuah node gagal, semua aplikasi hanya tersedia di node lain. Aksesibilitas tetap sama. Selama daya komputasi yang tersedia cukup, semua aplikasi dapat terus berjalan. Ada banyak diskusi tentang server MQTT, yang sebagai komponen sentral menyebabkan banyak masalah jika terjadi kegagalan, tetapi dalam sebuah cluster tidak menjadi masalah.
Apa yang terjadi jika master gagal
- Master juga dapat dijalankan secara berlebihan, begitu salah satu gagal, node lain dapat mengambil alih tugas.
Aplikasi tertentu perlu dijalankan pada node tertentu karena diperlukan akses ke perangkat keras.
- Ini dapat dimasukkan dalam deskripsi negara bagian. Negara juga dapat ditetapkan berdasarkan tag yang dimiliki perangkat. Sebagai contoh setiap AXCF2152 harus menjalankan aplikasi tertentu. Untuk mengambil contoh MQTT lagi, ada server MQTT yang berjalan di federasi, selanjutnya setiap node dapat dilengkapi dengan klien MQTT untuk menjalin komunikasi ke server MQTT. Master hanya ada sekali, klien berjalan di setiap node.
Contoh
Contoh deskripsi keadaan aplikasi yang terdiri dari tiga wadah (frontend, backend, database).
Penerapan:
- Menentukan semua setelan yang diperlukan untuk penampung.
Layanan:
- Membuat antarmuka ke aplikasi secara terpusat di cluster. Antarmuka selalu valid di node mana pun penerapan berjalan.
Masuk:
- Menghubungkan antarmuka ke frontend menggunakan entri DNS. Jadi frontend selalu dapat dijangkau di satu domain.
- Proksikan http://MyApp.MyDomain.de/ ke layanan frontend (Port 80)
- Proksikan http://MyApp.MyDomain.de/api ke layanan backend (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 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
Lihatlah
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