Mở đầu

Một trong những xu hướng mà tôi được tiếp cận khi sang làm DevOps ở một division trong Caterpillar chính là công nghệ Serverless. Project đầu tiên mà tôi nhận được chính là migrate hệ thống từ sử dụng server vật lý cổ điển lên sử dụng AWS Lambda. Đây là một trải nghiệm vô cùng thú vị khi tôi có cơ hội rất tốt để có thêm một mindset mới để thiết kế một hệ thống dựa hoàn toàn vào một nhà cung cấp hạ tầng và không phải lo lắng về những lỗi về server cổ điển như trước. Tất nhiên, không có bữa trưa nào là miễn phí, việc chuyển giao không chỉ đơn giản là port các method trong code cũ thành các function và cứ thế mà nó chạy, tôi đã tốn khá nhiều thời gian để re-engineer lại hệ thống để đảm bảo chi phí tiết kiệm và tốc độ được cải thiện. Dưới đây là một vài kinh nghiệm tôi thu thập được trong quá trình chuyển giao.

Lưu ý: Phương pháp này không hoàn toàn ngăn chặn Man-in-the-Middle attack nếu hacker can thiệp được vào tầng network, do Cloudflare không verify độ uy tín của certificate nên hacker có thể chen vào giữa luồng network bằng cách cung cấp certificate của riêng hắn rồi proxy ngược vào server. Để đảm bảo End-to-End Encryption hoạt động một cách chính xác, tham khảo document này: Full (strict) - SSL/TLS encryption modes. Như vậy Cloudflare chỉ thực hiện request đến server nếu như server đó sử dụng certificate của mà Cloudflare cho là an toàn, bao gồm các certificate có CA uy tín hoặc cerficate được sign bởi Cloudflare.

Hiện tại như thiết kế điển hình của các hệ thống nằm trên AWS, Azure, ta đều có Load Balancer đứng trước chúng, không cho phép traffic chảy trực tiếp vào server. Như vậy, các server nằm phía sau tương đối an toàn khỏi các cuộc tấn công liên quan đến viêc lộ địa chỉ IP của server. Nhưng việc sử dụng Cloudflare sẽ giúp được các vấn đề sau đây:

Hiện tại đã có bản Rancher 2.6 trở lên với giao diện mới hơn.

Mở đầu câu chuyện

Kubernetes gần đây đã trở thành một công nghệ nổi tiếng. Không chỉ gắn liên với việc quản lý các cluster lớn, rất nhiều framework hay các stack công nghệ bây giờ đều hỗ trợ k8s (điển hình nhất là kubeflow, nginx). Việc học k8s gần như không còn là môt lựa chọn mà trở thành một yêu cầu quan trọng cho nhiều công việc. Những ai đã/đang sử dụng k8s đều phải công nhận đây là một công nghệ rất mạnh và mềm dẻo, nhưng kèm theo đó là một nhược điểm rất lớn cố hữu: Rất khó sử dụng. Với những dev không phải quản lý hệ thống nhiều, việc điều khiển một cluster k8s thực sự là một cực hình do phải điều khiển nó thông quan kubectl - một CLI có quá nhiều thứ phải nhớ. Ngoài ra để deploy bất kì thứ gì lên đó, chúng ta phải viết một file yml dài ngoằng khó hiểu, liệt kê đầy đủ tất cả những gì cần phải có để một chương trình có thể chạy. Và tất nhiên k8s mặc định hoàn toàn không có giao diện. Kubernetes Dashboard (UI chính thức của k8s) cuối cùng vẫn bắt bạn phải viết yml. Rất nhiều config lưu trong k8s không thể lưu chính xác, và kết quả bạn lại phải viết thêm yml để phục vụ các config đó. Vậy nên yêu cầu của chúng ta khi deploy một cluster k8s ở máy bàn cá nhân cần phải thoả mãn các tiêu chí sau:

Đặt vấn đề

Một trong những thiếu sót khi sử dụng k8s trong môi trường production là không thiết đặt giới hạn tài nguyên cho hệ thống. Khi bạn không giới hạn tài nguyên cho các pod trong k8s, không sớm thì muộn sẽ có một thời điểm server của bạn sẽ hết sạch tài nguyên (điển hình là hết CPU và RAM). Việc này rất dễ xảy ra chạy các workload nặng trên nhiều node có cấu hình khác nhau. Cuối cùng server của bạn sẽ crash, hoặc là chạy rất chậm, khiến hệ thống trở nên kém ổn định, thậm chí là mất mát dữ liệu, gây tổn thất về uy tín và tiền bạc. Vậy một trong những việc đầu tiên khi một đưa bất kì thứ gì lên k8s là phải thiết đặt tài nguyên cho nó.