Manajemen Klaster pada PLCnext: Memanfaatkan Kubernetes untuk Otomasi Industri
Sebuah standar di IT selama bertahun-tahun, belum memberikan dampak besar di industri. Seringkali teknologi seperti ini dianggap terlalu kompleks dan tidak perlu. Pertanyaannya adalah, apakah mereka memberikan keuntungan bagi kita?
Sebuah visi untuk PLCnext menggunakan contoh Kubernetes.
Kubernetes
Kubernetes adalah orchestrator (sistem manajemen, master) yang menggunakan, di antara hal lain, kontainer dan sehingga membentuk jaringan melalui berbagai perangkat. Sistem ini digunakan untuk menyediakan aplikasi dengan cara yang sedikit berbeda.
Secara klasik aplikasi akan didistribusikan dan dipelihara pada perangkat. Diketahui pada komputer mana aplikasi berjalan. Jika aplikasi harus berjalan pada komputer lain ini harus dilakukan oleh orang. Jika salah satu komputer gagal, semua aplikasi pada komputer tersebut tidak lagi tersedia.
Dengan Kubernetes, master diberikan deskripsi status aplikasi, dan master menangani sisanya. Ini memastikan bahwa status yang diminta dipelihara setiap saat. Namun, tidak diketahui pada node mana aplikasi saat ini berjalan, tetapi dapat diakses secara prinsip.
Pertanyaan dan Jawaban
Apa yang menentukan deskripsi status
- Deskripsi status adalah dasar dari setiap aplikasi. Ini berisi misalnya kontainer mana yang digunakan dalam versi mana atau apakah aplikasi harus dimulai beberapa kali untuk load balancing. Ini ditulis sepenuhnya dalam bentuk teks sebagai file
json atau yaml. Oleh karena itu ini sepenuhnya dapat di-versi (mis. Git atau SVN).
Cara menginstal klaster
- Partisipan (master dan nodes) harus disediakan dengan dua komponen perangkat lunak (container runtime dan Kubernetes). Setelah itu, hanya perlu satu login melalui token ke master. Sisanya dilakukan oleh master.
Cara melakukan pembaruan aplikasi
- Sebuah pembaruan adalah mengganti deskripsi status aplikasi dengan yang baru. Pembaruan dilakukan secara on the fly, yang berarti aplikasi baru pertama kali diinstal dan dimulai dan pada saat terakhir aplikasi lama dimatikan. Jika pembaruan gagal, rollback dapat dilakukan dan status lama dapat dengan mudah dipulihkan. Orchestrator menyimpan semua status lama. Selain itu ada kemampuan versi dari deskripsi kondisi.
- Kemungkinan baru dari skenario pembaruan muncul di sini. Jika aplikasi sering berjalan di klaster, misalnya, hanya beberapa aplikasi yang dapat diperbarui terlebih dahulu. Jika tidak ada kesalahan dalam aplikasi setelah beberapa hari atau minggu pengujian, yang lain dapat diperbarui.
Apa yang terjadi jika node gagal
- Jika kapan pun node gagal, semua aplikasi dengan mudah tersedia pada node lain. Aksesibilitas tetap sama. Selama cukup daya komputasi tersedia, semua aplikasi dapat terus berjalan. Ada banyak diskusi tentang server MQTT, yang sebagai komponen pusat menyebabkan banyak masalah dalam hal kegagalan, tetapi di klaster ini bukan masalah.
Apa yang terjadi jika master gagal
- Master juga dapat dijalankan secara redundan, setelah satu gagal node lain dapat mengambil alih pekerjaan.
Beberapa aplikasi perlu berjalan pada node tertentu karena akses ke hardware diperlukan.
- Ini dapat disertakan dalam deskripsi status. Status 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, selain itu setiap node dapat dilengkapi dengan klien MQTT untuk membangun komunikasi ke server MQTT. Master hanya ada satu, klien berjalan di setiap node.
Contoh
Contoh deskripsi status aplikasi yang terdiri dari tiga kontainer (frontend, backend, database).
Deployment:
- Menentukan semua pengaturan yang diperlukan untuk kontainer.
Service:
- Membuat antarmuka ke aplikasi secara terpusat di klaster. Antarmuka selalu valid terlepas dari node mana deployment berjalan.
Ingress:
- Menghubungkan antarmuka ke frontend menggunakan entri DNS. Jadi frontend selalu dapat diakses di satu domain.
- Proxy https://MyApp.MyDomain.de/ ke frontend service (Port 80)
- Proxy https://MyApp.MyDomain.de/api ke 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 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
Lihat
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