Luận văn Xây dựng kiến trúc triển khai liên tục cho các hệ thống dựa trên vi dịch vụ

phối container và các thành phần Hình 2.2 thể hiện các thành phần cơ bản của một nền tảng điều phối container như thành phần kiểm tra sức khỏe, tự động scale, thành phần khám phá dịch vụ, bộ lập lịch hay thành phần nâng cấp hệ thống. Nền tảng điều phối container sẽ thực hiện qúa trình khởi tạo, lập lịch, lựa chọn máy cho tới giám sát, cập nhật và đảm bảo giao tiếp của các container trong cluster. 24 Các nền tảng điều phối container khác nhau thường có nhiều đặc điểm khác nhau, nhưng tất cả những nền tảng này đều phải đảm bảo cung cấp được các tính năng cơ bản như: • Cách thức cấu hình đơn giản: Những nền tảng điều phối container thường cho phép người dùng khai báo các thông tin về cấu hình ứng dụng, kho ảnh, cấu hình về mạng và các cổng được mở trên máy, thông tin về bộ lưu trữ ... một cách đơn giản, trực quan thông qua các định dạng JSON hoặc YAML. • Có các API để bật tắt container: Nền tảng điều phối container sẽ có API cho phép việc cung ứng hay xếp lịch để bật container. Dựa vào các ràng buộc về tài nguyên, về mối tương quan của container cần bật với các container đang chạy khác mà các nền tảng điều phối sẽ chọn máy phù hợp để triển khai. • Có cơ chế khám phá dịch vụ: Khi triển khai một hệ thống gồm rất nhiều dịch vụ, các dịch vụ được đóng gói theo dạng ảnh container và chạy trên nhiều máy khác nhau thì việc một container có thể nhận biết các thông tin về container khác sẽ trở nên khó khăn và đây là một trong những việc quan trọng hàng đầu trong qúa trình quản lý toàn bộ cluster. Các nền tảng điều phối container đều cung cấp giải pháp để giải quyết vấn đề này cho người dùng, chẳng hạn thông qua các dịch vụ dạng DNS, dịch vụ proxy, ... • Cơ chế giám sát và sửa lỗi: Nền tảng điều phối container có trách nhiệm theo dõi, giám sát container cũng như các máy mà chúng đang chạy. Nếu container bị lỗi, việc bật một container mới để thay thế được thực hiện gần như ngay lập tức. Nếu một máy trong cluster bị lỗi, các container đang chạy trên máy đấy sẽ được phân phối để bật lại trên những máy còn lại. Thường thì người sử dụng sẽ miêu tả trạng thái container mong muốn thông qua file cấu hình (phổ biến nhất là dạng JSON hoặc YAML) còn nền tảng điều phối sẽ giám sát để luôn đảm bảo điều này. Để đảm bảo xây dựng được hệ thống triển khai liên tục cho các phần mềm dựa trên vi dịch vụ, yêu cầu đầu tiên chính là việc lựa chọn nền tảng điều phối container thỏa mãn những tính chất đã nêu trên, phù hợp với cơ sở hạ tầng mà tổ chức đang sử dụng, có nhiều công cụ hỗ trợ cũng như có khả năng mở rộng tốt trong tương lai. 2.2 Yêu cầu cho các nhà phát triển 2.2.1 Khả năng tự triển khai Ngoài việc tự động triển khai khi có sự thay đổi mã nguồn trên kho mã chung, hệ thống triển khai liên tục cũng cần có cơ chế để cho phép các đội phát triển, kiểm thử tự triển khai ứng dụng lên các môi trường, phục vụ mục đích kiểm tra tính năng hoặc 25 kiểm thử, tái hiện lỗi. Hệ thống phân quyền cần được cấu hình để đảm bảo quyền hạn khác nhau tùy theo vai trò của các đội. 2.2.2 Nhận được các thông tin về kết quả build Quá trình triển khai liên tục thường gồm hai giai đoạn: dịch và triển khai. Dịch là quá trình biên dịch từ mã nguồn để đưa ra được một phiên bản chạy của ứng dụng, còn triển khai sẽ sử dụng sản phầm của quá trình dịch để cập nhật lên môi trường. Trách nhiệm của các đội phát triển là phải đảm bảo build thành công đối với bất cứ sự thay đổi mã nào. Tuy nhiên, quá trình dịch thường mất thời gian và các lập trình viên thường bận rộn với việc phát triển tính năng mới cho sản phẩm, do vậy cần có cơ chế để thông báo trạng thái của các tác vụ dịch cho các đội thông qua các kênh giao tiếp của công ty như email, phần mềm chat, ... 2.3 Yêu cầu về vận hành 2.3.1 Quản lý cấu hình Cơ sở hạ tầng được quản lý như mã (Infrastructure as code - IAC) là cách tiếp cận việc tự động hóa quản lý cơ sở hạ tầng dựa trên những kinh nghiệm từ quá trình phát triển phần mềm [12]. IAC nhấn mạnh vào tính nhất quán, lặp đi lặp lại đối với việc cung ứng và thay đổi các hệ thống cũng như cấu hình của chúng. Ý tưởng của IAC là người dùng sẽ viết và thực thi mã để định nghĩa, triển khai và cập nhật cơ sở hạ tầng. IAC thay đổi nhận thức của mọi người trong việc đối xử các hoạt động vận hành như là phần mềm, dù một số hoạt động thực tế liên quan tới phần cứng (ví dụ: cài đặt máy chủ triển khai). Bằng việc ứng dụng IAC, không chỉ người quản trị, bất cứ ai cũng có thể đọc và hiểu về toàn bộ cấu hình hệ thống, có khả năng đảo ngược cấu hình về phiên bản chạy tốt bằng việc sử dụng hệ thống quản lí phiên bản. IAC cũng cho phép đánh giá, kiểm thử trước khi thực sự triển khai sự thay đổi về cơ sở hạ tầng. Hệ thống quản lý cấu hình là một dạng công cụ IAC. Các hệ thống công nghệ thông tin thường xuyên thay đổi. Với mỗi bản phát hành, để hệ thống hoạt động được, người vận hành có thể cần thay đổi một số cấu hình nhất định. Trong hệ thống triển khai liên tục, tần suất triển khai cao có thể khiến cấu hình của cơ sở hạ tầng ngày một khác biệt so với trạng thái ban đầu, trở nên khó quản lý và lộn xộn. Nhằm tránh tình trạng không nhất quán này, cần có một hệ thống quản lý cấu hình phù hợp. 2.3.2 Thu thập và lưu trữ log Thu thập và lưu trữ log là yêu cầu cơ bản đối với bất cứ hệ thống phần mềm thực tế nào [13]. 26 Trong một hệ thống vi dịch vụ dựa vào container, các container sẽ được triển khai trong một cluster gồm nhiều máy. Với mỗi máy, ngoài các container còn có những dịch vụ khác đang chạy. Các ứng dụng sẽ sản sinh ra các tệp log với định dạng, vị trí khác nhau, khiến cho việc quản lý và sử dụng log trở nên khó khăn [14] (Hình 2.3). Hình 2.3: Cách thức thu thập log trước đây Cần có cơ chế để thu thập toàn bộ log cho tất cả các ứng dụng hay container này, đồng thời cho phép người dùng sử dụng chúng một cách hiệu quả: ví dụ như việc sau khi thu thập, sẽ có quá trình phân loại log, đánh chỉ số và cho phép người dùng tìm kiếm trên một giao diện phù hợp. 2.3.3 Giám sát và thông báo lỗi Các nền tảng điều phối container có cơ chế giám sát để đảm bảo các dịch vụ hoạt động bình thường và có phương pháp sửa lỗi nếu phát hiện vấn đề. Tuy nhiên, cơ chế cung cấp bởi nền tảng điều phối container thường chỉ ở mức cơ bản. Ví dụ: các dịch vụ cung cấp một API luôn trả lại mã trạng thái 200 (HTTP CODE), thành phần giám sát trong điều phối container sẽ gửi yêu cầu tới API này một cách định kỳ, nếu kết quả trả lại khác 200 thì thành phần giám sát sẽ thông báo tới bộ lập lịch để tắt và bật lại dịch vụ đó. 27 Trên thực tế, các dịch vụ thường chứa logic nghiệp vụ phức tạp, mỗi một dịch vụ lại có yêu cầu và các tham số giám sát riêng. Cần có cơ chế để các nhà phát triển có thể tùy biến các tham số cần giám sát, có công cụ trực quan để đội vận hành theo dõi và các phương thức tự động thông báo nếu có lỗi xảy ra. 2.3.4 Triển khai không bị gián đoạn và có khả năng đảo ngược phiên bản Hệ thống triển khai liên tục cần có khả năng đảo ngược phiên bản triển khai một cách dễ dàng. Điều này giúp giảm áp lực trong việc triển khai và khuyến khich mọi người triển khai thường xuyên hơn để đẩy tính năng mới người dùng một cách nhanh chóng. Ngoài ra, hệ thống phải cho phép cập nhật phiên bản mới của ứng dụng mà không có thời gian ngừng hoạt động để đảm bảo tính liên tục. Một kỹ thuật thường được sử dụng là triển khai dạng blue-green: chạy hai bản sao giống hệt nhau của ứng dụng. Tại thời điểm ban đầu, cả hai bản sao được gọi là blue. Khi cần cập nhật, một trong hai bản sao sẽ được cập nhật trước và được gọi là green. Sau khi đảm bảo phiên bản green hoạt động tốt, phiên bản blue còn lại sẽ được thay thế bằng phiên bản green. Ngược lại, nếu có vấn đề xảy ra, phiên bản green sẽ bị loại và phiên bản blue sẽ được triển khai lại. Ở lần cập nhật tiếp theo, một trong hai phiên bản green sẽ được thay bằng phiên bản mới được gọi là blue. Phương pháp này là một biến thể của mô hình triển khai không tùy biến có sử dụng reverse proxy đã giới thiệu trong chương 01. 2.3.5 Thiết kế mạng triển khai Trong thực tế, các máy triển khai trong đám mây của một công ty/tổ chức thường nằm trong một VPC (Virtual Private Cloud) với dải mạng ảo riêng. Các máy trong VPC có thể kết nối ra ngoài Internet thông qua một thiết bị NAT hoặc Internet Gateway được cung cấp bởi nhà cung cấp dịch vụ đám mây. Tuy nhiên, chúng không thể được truy cập trực tiếp từ bên ngoài nếu không gắn các địa chỉ Public IP vào những máy này với những cấu hình định tuyến thích hợp, tạo liên kết VPN hay sử dụng các dạng cấu hình port-forwarding tại các bộ định tuyến. Máy chủ triển khai thường được cài đặt tại ngay trong mạng nội bộ của công ty, do vậy ở điều kiện bình thường sẽ không thể kết nối tới tất cả các máy trong VPC, gây khó khăn cho việc triển khai tự động. Những phương pháp nêu trên đều có thể được áp dụng để giải quyết vấn đề này. Tuy nhiên, khi số lượng các máy trong VPC tăng lên, hoặc khi công ty muốn tạo ra nhiều VPC (chẳng hạn tạo ra nhiều môi trường để kiểm thử, đánh giá, mỗi môi trường được triển khai trên một VPC) thì những cách kết nối này đều có các hạn chế nhất định. Do vậy, thiết kế hệ thống triển khai liên tục cần tìm ra giải pháp đề giải quyết được yêu cầu này. 28 CHƯƠNG 3: THIẾT KẾ HỆ THỐNG TRIỂN KHAI LIÊN TỤC Trong chương này, luận văn sẽ đề xuất luồng triển khai liên tục cơ bản cho một hệ thống vi dịch vụ, đồng thời tìm hiểu, đánh giá các công nghệ hiện có cho mỗi thành phần trong luồng, dựa vào các điều kiện, yêu cầu được đưa ra ở các chương trước để đưa ra lựa chọn công nghệ và thiết kế hệ thống triển khai hoàn thiện. 3.1 Luồng triển khai cơ bản Hình 3.1: Luồng triển khai liên tục cơ bản Hình 3.1 thể hiện thiết kế luồng triển khai liên tục cơ bản cho một hệ thống vi dịch vụ sử dụng container, trong đó hoạt động của các thành phần cụ thể như sau: 29 Các lập trình viên sẽ phát triển tính năng và đẩy mã nguồn lên kho chứa mã chung (repository) của toàn bộ công ty/tổ chức. Khi kho chứa mã nhận biết có sự thay đổi về mã, máy chủ CI sẽ được kích hoạt để dịch mã vừa được cập nhật. Khi mã được dịch xong, máy chủ sẽ đóng gói bản dịch theo dạng ảnh container. Sau đó, các cơ chế kiểm thử tự động sẽ được dùng để đảm bảo mã không có lỗi. Nếu build thất bại, toàn bộ quá trình sẽ bị dừng lại. Ngược lại, máy chủ sẽ đẩy bản build mới lên một kho chứa chung dùng để triển khai. Kết quả build thành công hay thất bại đều có thông báo gửi tới nhà phát triển thông qua các kênh giao tiếp chung của công ty. Sau khi bản build được đẩy lên kho chứa, máy chủ CI sẽ kích hoạt máy chủ triển khai để triển khai bản build lên môi trường sản phẩm. Quá trình triển khai cần đảm bảo không có thời gian ngừng hoạt động và trong suốt với người sử dụng. Việc lựa chọn máy để triển khai và giao tiếp giữa các container trong các máy sẽ được một nền tảng điều phối container quản lý. Các bản build được triển khai trên môi trường sản phẩm sẽ được hệ thống giám sát kiểm tra thường xuyên. Nếu có vấn đề xảy ra, hệ thống giám sát sẽ gửi thông báo tới thành phần cảnh báo. Thành phần cảnh báo có trách nhiệm gửi thông báo lỗi tới nhà phát triển thông qua các kênh giao tiếp. Hệ thống quản lý log sẽ liên tục thu thập log từ các dịch vụ được triển khai, lưu trữ log vào một hệ thống lưu trữ và cho phép người dùng truy cập, tìm kiếm thông tin log khi có lỗi xảy ra thông qua giao diện người dùng. 3.2 Phân tích và lựa chọn công nghệ 3.2.1 Hệ thống quản lý mã nguồn Luận văn sẽ sử dụng Git làm hệ thống quản lý mã nguồn do đặc điểm phân tán, khả năng hỗ trợ rẽ nhánh, làm việc nhóm hiệu quả cùng sự phổ biến của nó. Mô hình rẽ nhánh được sử dụng trong quá trình phát triển được miêu tả trong Hình 3.2 [15]. Nhánh develop là nhánh chính được sử dụng cho việc phát hành. Các nhà phát triển sẽ tạo nhánh mới cho các tính năng mới, cho việc sửa lỗi hay các bản vá. Sau khi đảm bảo mã hoạt động tốt ở nhánh mới, nhà phát triển sẽ gửi một yêu cầu hợp nhất mã (merge request) vào nhánh develop. Ngay khi yêu cầu được tạo ra, Git sẽ sử dụng kỹ thuật Web Hook để kích hoạt quá trình build với mã mới (pre-merge build). Kết quả quá trình build và yêu cầu sẽ được gửi cho người quản lý kho mã nguồn. Người quản lý kho mã sẽ đánh giá yêu cầu và chấp nhận hợp nhất. Ngay sau khi người quản lý chấp nhận, một quá trình build khác sẽ được kích hoạt (post-merge build). Quá trình này sẽ đóng gói bản build mới vào ảnh container theo công nghệ container được chọn, 30 thực hiện kiểm thử với ảnh đóng gói và đẩy ảnh lên kho lưu trữ container nếu không có lỗi xảy ra. Hình 3.2: Mô hình rẽ nhánh 3.2.2 Máy chủ CI và máy chủ triển khai Ngay khi nhà phát triển gửi yêu cầu hợp nhất vào nhánh develop, Git sẽ kích hoạt các tác vụ dịch được chuẩn bị trong máy chủ CI. Quá trình dịch sẽ bao gồm tiền hợp nhất (pre-merge) và hậu hợp nhất (post-merge), với các bài kiểm thử khác nhau được thực hiện để đảm bảo chất lượng mã. Tất cả các bên liên quan đều có thể nhìn thấy quá trình dịch, thời gian thực hiện, trạng thái kết quả từ máy chủ CI. Nếu có vấn đề xảy ra, sẽ có thông báo gửi tới các bên liên quan thông qua kênh giao tiếp chung. Máy chủ CI được sử dụng trong bài là Jenkins, một phần mềm tự động hóa, mã nguồn mở và viết bằng Java. Jenkins hỗ trợ hầu hết các phần mềm quản lý mã nguồn 31 hiện nay như Git, Subversion, Mercurial ... và hỗ trợ các mã lệnh của nhiều loại ngôn ngữ kịch bản như Bash, Python, Groovy, Gradle ... Jenkins có kiến trúc plugin, cho phép thêm bớt các tính năng tùy theo yêu cầu. Một số plugin phổ biến cho Jenkins như phân quyền, Slack, Mail, ... Việc sử dụng Jenkins sẽ đảm tính mở rộng sau này do khả năng hỗ trợ đa dạng các công nghệ của nó. Do các đặc điểm linh hoạt, Jenkins cũng sẽ được sử dụng làm máy chủ triển khai trong luận văn. Hình 3.3: Máy chủ CI Jenkins Jenkins có thể chạy ở chế độ một mình. Tuy nhiên, ở chế độ một mình, khi số lượng các tác vụ build tăng lên, CPU và bộ nhớ sẽ không đáp ứng được. Để ngăn chặn điều này, cách sử dụng Jenkins phổ biến là theo mô hình chủ-nô lệ (master-slave) (Hình 3.4). Một máy nô lệ là một thiết bị được cấu hình để hành xử như một executor của máy chủ. Máy chủ sẽ phục vụ như giao diện chính, nhận các tác vụ và phân tán tải lên các executor/slave được đăng kí. 32 Hình 3.4: Kiến trúc master-slave của Jenkins [16] Các máy nội bộ của mỗi đội có thể được cấu hình và tham giao vào Jenkins với vai trò slave. Các bản build mã của những đội này có thể được điều chỉnh để luôn chạy trên các máy slave của đội. Điều này giúp hạn chế việc quản lý slave cho đội vận hành và phân phối tải tùy theo nhu cầu sử dụng về mỗi đội, phù hợp với mô hình phát triển vi dịch vụ. 3.2.3 Công nghệ container Mã nguồn sau khi được hợp nhất và build hậu hợp nhất sẽ được đóng gói thành ảnh container và lưu trong kho ảnh. Luận văn sẽ sử dụng công nghệ container phổ biến nhất hiện nay là Docker. Docker sử dụng Dockerfile để miêu tả các lớp ảnh, các câu lệnh cần thực hiện cho việc build ảnh container. Nhằm đảm bảo tính nhất quán trong việc tích hợp build ảnh container với mã nguồn, Dockerfile sẽ được lưu trữ và được quản lý trong cùng thư mục trên kho lưu trữ chung như mã nguồn. 3.2.4 Nền tảng điều phối container Hiện nay, cùng với sự phổ biến của công nghệ container, số lượng các nền tảng điều phối container ngày càng tăng lên. Trong đó, các nền tảng phổ biến nhất là Amazon ECS, Azure Container Service, Goole Container Engine, Diego của Cloud Foundry, Kubernetes, Docker Swarm, Mesosphere Marathon. Tuy nhiên, hầu hết các nền tảng điều phối đều là bản thương mại được cung cấp bởi các công ty điện toán đám mây, ngoại trừ Docker swarm, Mesosphere Marathon và Kubernetes. Luận văn do vậy chỉ tập trung hướng tới phân tích ba nền tảng này. 33 3.2.4.1 Docker swarm Từ Docker Engine phiên bản 1.12.0 trở đi, Docker cho phép người dùng triển khai container theo trạng thái Swarm. Docker swarm được xây dựng dựa trên Docker API và làm việc như sau: một swarm là một nhóm các máy chạy Docker và làm việc cùng nhau như một cluster. Người dùng vẫn sử dụng các lệnh Docker như trước để tương tác nhưng ở trạng thái này, các lệnh sẽ được thực thi trong cluster bởi swarm manager. Hình 3.5: Kiến trúc của Docker Swarm [17] Swarm manager có trách nhiệm như bộ lập lịch, phối hợp với các agent chạy trên mỗi máy để quản lý tài nguyên. Trong Docker swarm, chức năng lập lịch không bị giới hạn bởi Docker và có thể được thay thế bởi các phần mềm khác như Apache Mesos. Các swarm manager là các máy duy nhất nhận yêu cầu của người dùng. Các máy khác gia nhập vào swarm sẽ đóng vai trò là worker, được ủy quyền để thực hiện tác vụ. Để chạy một dịch vụ trong Docker Swarm, người dùng khai báo ảnh container cần chạy và số lượng bản sao cần thiết. Ví dụ: để khai báo việc chạy dịch vụ nginx với hai bản sao, người dung có thể triển khai bằng câu lệnh sau: # docker service create --replicas 2 --name mynginx nginx Trong ví dụ này, hai bản sao của ảnh nginx sẽ được các manager node điều phối để chạy trên worker node. Mỗi ảnh sẽ là một container chạy độc lập. Để đảm bảo giao tiếp mạng giữa các container trên các máy khác nhau, Docker swarm cần sử dụng thêm kỹ thuật mạng multihost. Kỹ thuật mạng multihost được hỗ 34 trợ mặc định trên Docker swarm là Docker Overlay Driver. Ngoài ra, người dùng có thể sử dụng các công nghệ khác để thay thế như Flannel, Weave, Calico ... Docker swarm hỗ trợ các công nghệ thường dùng để lưu trạng thái cluster như etcd, consul và zookeeper. Trước đây người dùng cần tự phát triển tính năng khám phá dịch vụ dựa vào Docker API và các công nghệ lưu trữ nêu trên, nhưng hiện tại một số công cụ khám phá tự động dựa vào DNS đã được phát triển và sử dụng phổ biến với Docker Swarm như wagl. 3.2.4.2 Mesosphere Marathon Apache Mesos là nền tảng quản lý cluster mục đích chung, hoạt động như nhân của một điều hành phân tán, được xây dựng dựa trên các nguyên lý tương tự như nhân Linux nhưng khác ở phạm vi ứng dụng: Mesos trừu tượng hóa CPU, bộ nhớ, bộ lưu trữ và các tài nguyên tính toán khác trong toàn bộ cluster, khiến cluster giống như một máy tính khổng lồ mà dựa vào đó các hệ thống phân tán được build và chạy một cách dễ dàng, hiệu quả. Nhân Mesos được chạy trên tất cả các máy và cung cấp các ứng dụng lớp trên (như: Hadoop, Spark, Cassandra, Elasticsearch) những API giúp quản lý tài nguyên và lập lịch chạy trên toàn bộ cluster. Giống với nhân hệ điều hành bình thường, Mesos thường không hoạt động một mình mà được sử dụng kèm với các bộ khung khác, như Apache Spark, Apache Casandra, Chronos hay Marathon (Hình 3.6). Mesos hỗ trợ chạy dịch vụ ở dạng đã được container hóa cũng như dạng chạy trực tiếp (bash script, Python, ứng dụng JVM...). Mesosphere Marathon là một bộ khung giúp điều phối container trên Mesos, cung cấp khả năng scale và tự khôi phục. Tương tự như Docker Swarm, Mesos hoạt động theo mô hình chủ-nô lệ, trong đó các agent trong máy nô lệ sẽ gửi thông tin về tài nguyên cho máy chủ. Bộ lập lịch trong Marathon đăng kí với Mesos để nhận các thông tin cập nhật về tài nguyên và dựa theo đó để lựa chọn máy chạy một cách hợp lí. Kết nối mạng giữa các container trên các máy chạy trong Mesos cluster phụ thuộc vào công nghệ container được sử dụng: Mesos containerizer hoặc Docker containerizer. Với Docker containerizer, kỹ thuật mạng multihost được sử dụng như đề cập ở phần Docker swarm [11]. 35 Hình 3.6: Kiến trúc của Apache Mesos Mesos cho phép người dùng tích hợp nhiều công cụ khám phá dịch vụ khác nhau, tuy nhiên giải pháp thường được dùng là Mesos-DNS, một dạng dịch vụ DNS tương tự như DNS trong Docker swarm wagl. Hình 3.7: Kiến trúc Mesosphes Marathon [18] 36 3.2.5 Kubernetes Kubernetes là một nền tảng điều phối mã nguồn mở được phát triển sau hơn một thập kỷ chạy các ứng dụng container của Google. Như hai nền tảng ở trên, Kubernetes gồm ít nhất một máy chủ và nhiều máy nô lệ. Máy chủ cung cấp API cho người dùng, có trách nhiệm lập lịch để triển khai và quản lý toàn bộ cluster. Tất cả các node trong Kubernetes cluster đều cung cấp môi trường chạy container, ví dụ như Docker hay rkt. Trong Kubernetes, một pod là một tập hợp các container được triển khai và quản lý cùng nhau. Pod là đơn vị triển khai nhỏ nhất, đóng vai trò như lớp bao của các container với môi trường ngoài. Các ảnh container trong pod và số lượng bản sao các pod cần chạy có thể được khai báo trực quan trong tệp dạng JSON hoặc YAML. Thành phần Replication Controller (trong các phiên bản Kubernetes mới hơn, thành phần ReplicaSet hoặc Deployment có thể được sử dụng thay cho Replication Controller) có vai trò đọc các tệp JSON được khai báo và đảm bảo trạng thái của các pod. Kubernetes cài lên mỗi máy trong cluster một kubelet agent, chịu trách nhiệm điều khiển các dịch vụ Docker, giám sát và thông báo cho master trạng thái tài nguyên của máy. Máy chủ thu thập và lưu trữ trạng thái toàn bộ các máy vào cơ sở dữ liệu dạng key-value etcd; dựa vào đó, bộ lập lịch trong máy chủ lựa chọn vị trí triển khai cho các pod. Hình 3.8: Kiến trúc của Kubernetes [11] Trong Kubernetes, các pod có thể xuất hiện hay biến mất trên mỗi máy tùy thuộc vào tài nguyên hiện tại. Do vậy, các thông tin về pod như địa chỉ IP hay các cổng được 37 mở ra cho các container trong pod là không đáng tin cậy. Để giải quyết vấn đề này, Kubernetes cung cấp một lớp trừu tượng gọi là lớp dịch vụ. Một tập hợp các pod sẽ được đại diện bởi một dịch vụ, với tên và cổng không đổi. Dịch vụ lựa chọn các pod để đại diện dựa vào Label Selector. Trong các ứng dụng nội bộ, Kubernetes cung cấp các Endpoints API và luôn cập nhật API theo sự thay đổi của các Pod trong dịch vụ. Với các ứng dụng khác, Kubernetes cung cấp một dạng IP ảo cho dịch vụ, từ dịch vụ sẽ redirect các yêu cầu sang Pod. Trên mỗi máy trong Kubernetes cluster đều được cài kube-proxy, có nhiệm vụ cung cấp một dạng địa chỉ IP ảo cho các service. Kube-proxy có nhiều dạng hoạt động, tuy nhiên mục đích chung đều là ánh xạ các yêu cầu gửi tới Service vào các Pod chạy phía sau. Ví dụ (Hình 3.9): Ở dạng userspace, kube-proxy sẽ lắng nghe sự kiện thêm/bớt Service hay Pod từ master. Với mỗi Service, kube-proxy sẽ mở một cổng proxy ảo trên máy. Tất cả yêu cầu gửi tới cổng sẽ được đẩy tới các Pod mà Service ánh xạ tới (thông tin ánh xạ của Service và Pod được lưu trong EndPoints API). Kube- proxy cũng sẽ sửa đổi bảng iptables để redirect tất cả yêu cầu tới địa chỉ IP ảo và cổng của Service sang cổng proxy ảo, từ đó redirect sang đúng Pod mà Service đang đại diện. [19] Hình 3.9: Ánh xạ Service và Pod trong Kubernetes Kubernetes hỗ trợ công cụ khám phá dịch vụ bằng DNS, cho phép phân giải tên của dịch vụ sang địa chỉ Cluster IP, từ đó giúp tất cả các container trên các máy trong cluster có thể giao tiếp với nhau thông qua tên dịch vụ. Dịch vụ ngoài ra còn đóng vai trò như load-balancing trong nội bộ kubernetes. Kubernetes không cung cấp giải pháp để đảm bảo thông tin kết nối mạng giữa các máy mà đòi hỏi người dùng sử dụng dịch vụ ngoài như: Flannel, CNI, ... Dựa vào đó, Kubernetes sinh ra các Cluster IP ảo để đại diện cho dịch vụ và các Pod. 38 3.2.5.1 So sánh và lựa chọn nền tảng Ba nền tảng điều phối đều cung cấp các chức năng cơ bản nhất để quản lý container, tuy nhiên độ phức tạp trong sử dụng, số lượng máy có thể quản lý và khả năng tùy biến của các nền tảng hoàn toàn khác nhau: • Docker Swarm: dễ sử dụng và cài đặt do được cung cấp bởi Docker, tuy nhiên khả năng tùy biến thấp. Quản lý số lượng máy nhỏ tốt (dưới 10), tuy nhiên hiệu năng giảm đáng kể khi số lượng máy tăng lên (dưới 100). Chưa có số liệu thống kê về sử dụng Docker swarm để quản lý tới 1000 máy. Docker swarm phù hợp với các tổ chức có quy mô nhỏ. Nền tảng < 10 máy 10 - 100 máy 100 – 1000 máy > 1000 máy Khả năng tùy biến Tính dễ sử dụng Docker swarm ++ + ? ? + +++ Mesphere Marathon + ++ ++ ++ ++ + Kubernetes ++ ++ + ? ++ ++ Bảng 3-1: So sánh Docker Swarm, Mesosphere Marathon và Kubernetes • Mesosphere Marathon: Sử dụng Mesos để quản lý số lượng máy nhỏ là không hiệu quả (dưới 10), do được thiết kế để hỗ trợ tối đa sự dư thừa cho các hệ thống lớn. Mesos cho phép cấu hình linh hoạt và có thể quản lý tới hơn 1000 máy mà vẫn đảm bảo hiệu năng. Tuy nhiên, cấu hình Mesos quá phức tạp, đòi hỏi nhiều kiến thức, do vậy chỉ phù hợp với các công ty quy mô lớn. • Kubernetes: Kubernetes là phiên bản trung hòa của hai nền tảng trên, cho phép cấu hình linh hoạt, hoạt động tốt với cả số lượng máy nhỏ và vừa (từ 10 tới trên 100 máy). Cấu hình Kubernetes không quá phức tạp, có nhiều tài liệu hỗ trợ và cộng