Deploy Air-viewer trên Kubernetes sử dụng Nginx ingress

Tram Ho


Ở phần trước mình đã deploy nginx, cùng các service như tea hay coffee, đến phần này mình sẽ deploy 1 ứng dụng web có hệ thống được miêu tả như hình trên, phần sensor thì mình sẽ không làm chi tiết, các bạn có thể tham khảo tại đây hoặc qua github. Chúng ta có các services như Flask, mysql, nuxt.js được định tuyến chung với nginx-ingress sau đó sử dụng luôn worker node làm domain, loadbalancer. Dự án đo nồng độ ô nhiễm bụi trong không khí này cũng được xây dựng microservices các bạn có thể tham khảo tại đây https://github.com/sun-asterisk-research/air-viewer

CleanUp phần trước

Clone Project Air-viewer

Install đối với các bạn chưa đọc bài trước

Ở phần trước mình đã cài đặt kubernetes-ingress nên mình sẽ đi nhanh phần này nếu các bạn chưa cài đặt kubernetes-ingress. Từ giờ trở đi mặc định các câu lệnh thực thi trên master node thôi

Create a Namespace, a SA, the Default Secret, the Customization Config Map, and Custom Resource Definitions

Tạo một secret với chứng chỉ TLS và key cho server mặc định NGINX:

Tạo một config map cho tùy biến NGINX configuration

Tạo custom resource definitions cho VirtualServer và VirtualServerRoute

Configure RBAC

Deploy the Ingress Controller

Config Air-viewer

Create Namespaces

Deploy Mysql

Về deploy mysql chúng ta cần persistent Volume nơi chưa database, secret chứa các password của root và user name để che dấu password tránh người khác cùng quản lý các services khác đọc được thông qua câu lệnh describe deployment của mysql. Cuối cùng là các file chứa servicedeployment

Secret

ouput: cm9vdA==

Chúng ta có thể liệt kê các secret trong namespace air-viewer

Output:

mô tả hiển thị thông tin của secret mysql-secrets, tương tự mysql-pass-non-root

Output:

Persistent Storage

Container là một cấu trúc ephemeral. Mọi thay đổi đối với container đang chạy sẽ bị mất dữ liệu khi container stop. Vì đó, container sẽ không phù hợp cho cơ sở dữ liệu lưu trữ, chúng ta bắt buộc phải sử dụng volume store để mount với các pod của mysql

Deployment

Như trên có thể thấy việc mapping giữa deployment với secretmysql-pv-claim

Kiểm tra trạng thái của deployment mysql

output:

Truy cập môi trường bên trong của pods được tạo

output:

output:

Service

Dựng service cho các pod(s)

Kiểm tra lại:

output:

Deploy Backend (Flask, UWSGI)

Deployment

Deploy này sẽ kết hợp với secret user, password đã tạo trước đó.

Kiểm tra:

output:

Service

Deploy Frontend (Nuxt.js)

Deployment

Service

Kiểm tra:

Output:

Ingress controller config

Sơ sơ về VirtualServer: VirtualServer để định cấu hình cân bằng tải cho một tên miền

Ở phần này mình có chút yêu cầu về Virtual server routevirtual server tìm hiểu thêm ở đây

Secret DNS framgia2c.mylabserver.com

Backend Virtual Server Route

Cấu hình route của backend với prefix /api

Frontend Virtual Server Route

Cấu hình route của frontend với prefix /

Air-viewer Virtual Server

Map các quy tắc đường dẫn cho nginx controller

Kiểm tra frontend-air-viewer cũng tương tự đối với backend-air-viewer

output:

Kiểm tra virtualserver air-viewer

output:

Kiểm tra đối với trình duyệt truy cập

truy cập https://framgia2c.mylabserver.com/api/ chúng ta sẽ truy cập đến service backend do quy tắc prefix: /api

output:

truy cập https://framgia2c.mylabserver.com/vi/faq chúng ta sẽ dẫn đến info FAQ của air-viewer

output:

Hiện tại thì chúng ta chưa có client PI + sensor để thu thập dữ liệu không khí để gửi đến tên miền này, dữ liệu sẽ bị trống không được như trang http://airviewer.sun-asterisk.vn/

Do server dạng phục vụ mục đích học tập nên rất có thể chỉ hoạt động trong mấy tiếng rồi bị shutdown. Tên miền sẽ không truy cập được mong các bạn thông cảm

Một vài thí nghiệm nhỏ

Thí nghiệm 1 (loại bỏ 1 worker node)

Chúng ta sẽ shut down worker node 2 có domain framgia3c.mylabserver.com tức ko ảnh hưởng đến domain hiện tại và cũng ko làm thay đổi master node. Nhận thấy rằng app vẫn chạy bình thường, kiểm tra các pods được dịch chuyển sang worker node 1 để gồng gánh các pods đã bị shutdown.

Thí nghiệm 2(loại bỏ hẳn master node)

Chúng ta đang có 3 nodes, 1 master và 2 worker đang chạy và thử shutdown con master nodes. App vẫn chạy như bình thường, chỉ có chết 1 số service mà NuxtServerInit của Nuxt.js gọi API trên nền server kết nối với Flask sẽ bị chết, ngoài ra các services hay các API khác vẫn hoạt động như bình thường. Cũng giống như 1 tổ chức, leader nghỉ 1 hôm làm việc, member vẫn làm như bình thường theo lịch trình, nhưng chỉ cần thay đổi lịch trình, hay có vấn đề gì ở các member (shutdown tiếp cả worker node) lúc đó chắc chắn web của chúng ta sẽ bị chết. Do các pods sẽ không được điều phối nữa vì master node không còn quản lý hoạt động.

Qua 2 thí nghiệm trên rút ra được zero downtime của kubernetes nó mạnh đến cỡ nào

Kết thúc

Việc triển khai này cũng sẽ vẫn chưa đầy đủ, ngoài ra chúng ta cần kết hợp các công cụ khác của DevOps khác để quản lý các monitor, logs… thu thập phân tích báo cáo các logs tình trạng cuả hệ thống, rất nhiều thứ khác mà đến mình còn đang rất mung lung. Hứa hẹn sẽ đến với bài viết tương lai sau

Chia sẻ bài viết ngay

Nguồn bài viết : Viblo