Managed – FPT Kubernetes Engine

Đây là mô hình kiến trúc hệ thống để bạn tham khảo khi triển khai ứng dụng Mcroservices trên FPTCloud với FPT Kubernetes Engine. Mô hình kiến trúc này dựa trên những nguyên tắc thiết kế cơ bản của các thành phần như network, security, high-availability.

Các dịch vụ được FPT Cloud cung cấp dưới dạng Service như: API Management, FMON, Container Registry, Key Vault. Các dịch vụ này được đặt ở VPC do FPT Cloud quản lý.

Network Topology:

Mô hình network được phân chia tách biệt subnet cho từng thành phần giúp quản trị dễ dàng hơn, có thể đặt tưởng lửa vào giữa các subnet giúp bảo mật hơn. 

• Subnet cho Database: Subnet để đặt các Databases Nodes. Thông thường subnet này sẽ không được truy cập ra vào internet. Giới hạn truy cập từ subnet cho Kubernetes với các ports giới hạn theo Databases.
• Subnet cho Kubernetes Cluster Nodes: Với model Dedicated, các Nodes sẽ được đặt trong cùng 01 subnet. Với model Managed, bạn có thể chọn subnet cho từng worker group. Subnet này sẽ được kết nối đến các thành phần trong hệ thống như Databases, Registry, Vault, FMON, API Gateway, WAF & LB.
• Subnet cho Web Application Firewall (WAF): WAF giúp bảo vệ ứng dụng web & các HTTP API bằng cách giám sát và sàng lọc HTTP traffic. Đặt WAF ở trước ứng dụng của bạn giúp ngăn chặn các cuộc tấn công từ bên ngoài. WAF thường được đặt ở một subnet riêng biệt để thuận tiện cho việc quản trị, cấu hình.
• Subnet cho Load-Balancer: Subnet 192.168.255.1/25 để đặt LB Nodes, subnet được cấu hình bởi FPT Cloud và bạn không được cấu hình subnet trùng với subnet này. Load-Balancer hỗ trợ L4 & L7.

Components:

• FPT Kubernetes Engine (FKE): là dịch vụ cung cấp Kubernetes Cluster mới 02 model là Dedicated & Managed (ưu tiên). Với mô hình Managed, Kubernetes Control Plane được quản lý bởi FPT Cloud. Người sử dụng có thể quản lý và truy cập vào các Worker Nodes.

• FPT Database Engine (FDE): dịch vụ cung đa dạng các loại Databases đáp ứng đầy đủ các nhu cầu sử dụng của khách hàng.

• FPT API Management: là dịch vụ cung cấp hệ thống quản lý API chuyên nghiệp được thiết kế tập trung cho khả năng tích hợp và mở rộng dễ dàng.

• FPT Observability (FMON): dịch vụ cung cấp hệ thống giám sát toàn diện bao gồm metrics, logs và traces cho phép người sử dụng dễ dàng giám sát và cấu hình cảnh báo cho hệ thống của mình.

• FPT Container Registry: Dịch vụ lưu trữ và quản trị các container images.

• FPT Key Vault: Dịch vụ lưu trữ và quản trị các key-value cần bảo mật.

Workflow:

• Trước tiên, HTTPS request đi vào hệ thống thông qua lớp Firewall L4 được cung cấp mặc định bởi FPT Cloud VPC. Tại đây, người sử dụng có thể cấu hình firewall theo IP & port.

• Tiếp đến, các request đi qua WAF. Tại đây, các request không hợp lệ sẽ bị chặn lại, các request hợp lệ sẽ được đi qua.

• Nếu bạn sử dụng FPT API Management, các request sau khi đi qua WAF sẽ được route tới API Gateway, sau đó sẽ được route tới các service backend (như trong mô hình kiến trúc này sẽ tới đầu ingress Load Balancer). Nếu bạn không sử dụng API Management, các request đi qua WAF sẽ được route tới ingress Load Balancer.

• Load Balancer đóng vai trỏ cân bằng tải cho các ingress controller được chạy đều trên các worker nodes. Load Balancer này được hệ thống tự động tạo khi bạn thực hiện tạo kubernetes cluster. Khi cài đặt ingress, bạn cần thực hiện tạo ingress service (svc) với type là Load Balancer để hệ thống hoạt động tốt với cluster autoscaler.

• Ingress giúp bạn “expose” các micro services ra bên ngoài Cluster. Các request đi qua ingress sẽ được route đến đúng Service thông qua domain & path tương ứng trong cấu hình ingress.

• Service là một thực thể trong Kubernetes Cluster giúp bạn “expose” một nhóm Pods (Containers) ra mạng. Các micro services gọi nhau thông qua Service. Service sẽ thực hiện cân bằng tải tới các Pods (Containers) tương ứng. Các Service này được cấu hình là backend của ingress, đại diện cho các micro services.

• Pods (Containers) là nơi chạy các ứng dụng micro services. Các micro services gọi nhau thông qua Service và có thể kết nối tới các dịch vụ khác như Databases, Key Vault… Pods đi ra mạng ngoài thông qua Worker Nodes network.

Các khuyến nghị:

• Chọn HA Master Nodes với model Dedicated.

– Để đảm bảo tính sẵn sàng, chọn HA Master Nodes cho các hệ thống quan trọng. Có thể chọn non-HA cho các hệ thống Dev Test. 

• Managed FKE: với các hệ thống production & tải lớn, tách biệt worker group base và worker group sử dụng cho ứng dụng. Cấu hình autoscale tối thiểu 3 node cho mỗi worker group.
• Sử dụng Namespaces

– Tạo namespace để phân chia ứng dụng hoặc môi trường để dễ dàng quản lý. Tránh sử dụng các namespace được hệ thống tạo sẵn để deploy ứng dụng. 

• Sử dụng Readiness & Liveness Probes

– Giúp đảm bảo tính sẵn sàng của ứng dụng. 

– Readiness Probes đảm bảo request được điều hướng tới pod chỉ khi pod đó ở trạng thái sẵn sàng để nhận request. Các Pod thường tốn thời gian để start ứng dụng, việc đặt Readiness Probes giúp service không điều hướng request đến các – Pod khi start (ứng dụng chưa ready). 

– Liveness Probes đảm bảo Pod chạy ứng dụng đang ở trạng thái Running, nếu Liveness Probes fail, pod sẽ được restart. 

• Đặt Resource Requests & Limits

– Giúp container đảm bảo đủ lượng resources để chạy và không chạy quá lượng resource cho phép. Nếu không có limits, pod có thể sử dụng nhiều resource quá tài nguyên cho phép, có thể làm Node crash. 

• Sử dụng Autoscale

– Sử dụng tính năng Autoscale của FKE dựa trên Kubernetes HPA giúp ứng dụng đáp ứng nhanh khi lượng truy cập tăng cao. Khi lưu lượng sử dụng sử dụng thấp, hệ thống sẽ tự động giảm các Pod/Nodes về mức tối thiểu. 

• Sử dụng nhiều Pod (>=2)

– Để đảm bảo HA, nên sử dụng >=2 Pod cho mỗi service.  Sử dụng anti-affinity để các replica pods nằm trên các Nodes khác nhau. 

• Đặt Pod Disruption Budgets (PDB)

– Để tránh việc giảm pod quá nhiều có thể gây gián đoạn dịch vụ, bạn nên đặt PDB để giới hạn số lượng pod có thể terminate (có thể trong quá trình scale down node hoặc deploy ứng dụng). Ví dụ nếu bạn đặt replica là 05 và mong muốn rằng trong 1 thời điểm chỉ cho phép 02 Pod được terminate, 03 Pod running để đảm bảo ứng dụng đáp ứng tốt, bạn có thể cấu hình PodDisruptionBudget với thông số minAvailable là 3. 

• Sử dụng Persistent Volume

– FKE hỗ trợ Block và File Storage. 

– Block Storage là lựa chọn mặc định cho hệ thống, hỗ trợ RWO, đáp ứng performance tốt theo Storage Policy. 

– File Storage hỗ trợ RWX sử dụng NFS. Không sử dụng File storage cho Database. 

• Backup

– Đặt lịch Backup Cluster (Dedicated) theo hướng dẫn. Người sử dụng cần tự thực hiện việc backup dữ liệu trên PVC (nếu có). Có thể backup ra VM sau đó thực hiện backup VM sử dụng giải pháp FCloud Backup & Recovery. 

• Monitoring & Logging

– Sử dụng FMON để tích hợp monitor & log với Kubernetes cluster. Đặt cảnh báo cho hệ thống.