Kubernetes - hiện đại hóa kiến trúc vi dịch vụ.‌‌

Tác Giả: Marco Palladino - CTO Kong Inc.

Trong cuốn sách này chúng tôi sẽ thảo luận về cách Kubernetes (/_ ky.ber.nɛ̌ː.tɛːs _/) nâng cao kiến trúc vi dịch vụ trên nền tảng công-ten-nơ. Chúng tôi sẽ xét tới sự nổi lên của (công nghệ) công-ten-nơ và Kubernetes để hiểu tổ chức và ưu điểm kỹ thuật của mỗi loại. Và cũng sẽ đào sâu (deep dive) vào cách Kubernetes có thể cải tiến quy trình triển khai, mở rộng và quản lý ứng dụng công-ten-nơ.

Phi Lộ

• Bài viết này được dịch từ cuốn sách Kubernetes: The Future of Infrastructure (Marco Palladino): Link
• Người đăng không sở hữu gì ngoại trừ nội dung Việt văn.

Thế hệ kế tiếp của việc phát triển ứng dụng

Thế giới cơ sở hạ tầng công nghệ thông tin (CNTT) đã phát triển vượt bậc sau thời kỳ chỉ biết dựa vào máy chủ vật lý để hỗ trợ phát triển ứng dụng. Đầu những năm 2000, một công ty tên là VMWare đã phá vỡ khuôn mẫu, quật khởi ảo hóa - (là) một khái niệm trừu tượng (abstraction) giúp cho phần mềm (máy ảo) hoạt động và “trông” giống hệt như phần cứng thật. Sự khác biệt chính giữa ảo hóa và máy chủ vật lý là lợi ích cố hữu của việc sử dụng phần mềm để “ảo hóa” cơ sở hạ tầng. Ảo hóa cho phép tăng tính linh hoạt, khả năng mở rộng, độ tin cậy và thường là năng lực cùng hiệu suất tổng thể, kèm theo việc giảm vốn và chi phí vận hành.

Trong những năm gần đây, sự hợp lưu của điện toán đám mây và dữ liệu lớn đã tiếp liệu (fueled) cho một sự bùng nổ khác trong việc thiết kế để công nghệ được cải thiện hơn nữa về tính linh hoạt và sự tiện lợi ở quy mô lớn - (đó là) việc áp dụng các công-ten-nơ để tạo điều kiện phát triển phần mềm và phổ biến (kiến trúc) vi dịch vụ.

Công-ten-nơ là cách thức đóng gói phần mềm hiệu quả hơn - nó chứa tất cả các thành phần cần thiết để “chạy” một phần mềm, như mã lệnh, môi trường thực thi (runtime), thư viện hệ thống và cấu hình. 451 dự án nghiên cứu cho thấy toàn thị trường công-ten-nơ sẽ đạt khoảng 2,7 tỷ đô-la vào năm 2020, tăng gấp 3,5 lần so với 762 triệu đô-la chi cho công nghệ liên quan đến công-ten-nơ trong năm 2016.

Với công-ten-nơ, mọi sự phức tạp (moving parts) và phụ thuộc trên từng cơ sở hạ tầng được giảm lược và đương nhiên, cho phép các lập trình viên (developers) làm việc với môi trường phát triển và tập hợp phần mềm (stacks) tương đồng.

Giống máy ảo, nhưng tốt hơn

Có nhiều điểm tương đồng giữa sự gia tăng của máy ảo và sự gia tăng của công-ten-nơ. Công-ten-nơ đang chuyển đổi cách thức phát triển phần mềm giống như cách mà ảo hóa và máy ảo đã làm vào nửa đầu thập niên 2000. Trước khi có máy ảo, nếu ta muốn mở rộng cơ sở hạ tầng để hỗ trợ nhu cầu phát triển phần mềm, chúng ta phải mua thêm máy chủ và phải mở rộng cả quy mô “vật lý”. Cách này vừa tốn kém về tài nguyên, vừa hao tổn sức lực không chỉ ở xây dựng mà còn ở việc duy trì hiệu suất và tính sẵn sàng. Nhưng máy ảo đã thay đổi cuộc chơi (changed the game), cho phép ta mở rộng dễ dàng hơn mà không cần tới nhà cung ứng phần cứng để mua thêm máy chủ. Ta có thể tăng tính hiệu quả của (việc sử dụng) phần cứng đang có và mở rộng tới hàng ngàn máy ảo trên chính phần cứng có sẵn. Ở dạng đơn giản nhất, công-ten-nơ giúp ta đạt được điều tương tự bằng cách cho phép tận dụng tối đa từng inch phần cứng đang chạy bên dưới, nhưng ở quy mô lớn hơn nhiều.

Có rất nhiều lợi điểm của việc sử dụng công-ten-nơ. Đầu tiên, nhóm DevOps được hưởng lợi rất nhiều bởi cách tiếp cận hiệu quả hơn trong việc phát triển phần mềm. Công-ten-nơ giúp cho các nhóm kỹ sư linh hoạt hơn bằng việc giảm lãng phí nguồn lực và ủy quyền để dựng(build) cùng việc chia sẻ mã lệnh nhanh hơn dưới kiến trúc vi-dịch-vụ. Hơn hết, việc công-ten-nơ hóa cải thiện khả năng mở rộng thông qua một cách tiếp cận giản lược(lightweight) và sử dụng tài nguyên hợp lý hơn. Việc cải thiện (khả năng mở rộng) này, cùng với những cải tiến về hiệu năng và tốc độ phát triển, mang lại hiệu quả tốt hơn về thời gian và chi phí.

Công-ten-nơ rất linh hoạt và dễ mở rộng. Dùng công-ten-nơ, ta có thể tận dụng nhiều tiến trình trên mỗi máy ảo và có thể gia tăng(các tiến trình đó) một cách hiệu quả. Ta cũng có thể chạy bất cứ loại “tải” (workload) gì với công-ten-nơ vì tính chất cô lập (isolated) - đảm bảo từng loại “tải” được bảo vệ khỏi các loại khác. Kết quả là, một công-ten-nơ không thể đụng vào hay phá hoại công-ten-nơ khác.

Dễ dùng là một lợi ích cốt lõi khác của công-ten-nơ. Giống với việc máy ảo từng dễ tạo, mở rộng và quản lý hơn so với máy chủ vật lý, công-ten-nơ thậm chí còn dựng phần mềm dễ hơn máy ảo vì chúng có thể khởi chạy sau vài giây. Đã qua rồi những ngày chạy toàn tiến trình tải nặng trên một máy ảo hoàn chỉnh. Thay vào đó, một công-ten-nơ ban cho ta sự lộng lẫy(luxury) của việc chạy tiến trình “nhẹ” và được cô lập ngay trên chính những máy ảo đó. Việc này cho phép ta mở rộng nhanh chóng và dễ dàng mà không bị xa lầy vào công việc DevOps bận rộn.

Ranh giới tiếp theo: Điều phối công-ten-nơ

Việc ứng dụng công-ten-nơ bùng nổ dẫn tới việc áp dụng điều phối công-ten-nơ. Việc này một lần nữa “đồng hành” với thế giới ảo hóa, các công ty như VMware cung cấp những công cụ thiết yếu để triển khai, quản lý, tạo và xóa máy ảo. Hệt như các máy ảo, công-ten-nơ cũng cần được quản lý và điều phối để đảm bảo rằng chúng hoạt động chuẩn xác.

(Việc) điều phối công-ten-nơ cho phép các nhà phát triển có thể theo dõi, lập lịch và “vận hành hóa” (operationalize) đa dạng công-ten-nơ với số lượng lớn một cách tốt hơn. Nếu ta muốn chạy nhiều công-ten-nơ trên nhiều máy chủ và máy ảo - điều cần làm khi sử dụng kiến trúc vi dịch vụ - việc này cần một lượng “tài nguyên” DevOps đáng kể để hiện thực hóa.

Rất nhiều câu hỏi phức tạp cần lời giải, ví như khi nào cần khởi chạy đúng loại công-ten-nơ, làm sao để đảm bảo công-ten-nơ có thể nói chuyện với nhau, cần cân nhắc loại lưu trữ nào, và làm sao để đảm bảo tính sẵn sàng cao trên toàn hệ thống? Chắc không có gì lạ khi khái niệm được dùng cho toàn bộ những việc đó là “điều phối công-ten-nơ”. May mắn thay, có nhiều công cụ được thiết kế để làm việc đó - xóa bỏ sự phức tạp của việc điều phối công-ten-nơ chạy trên máy ảo, giống hệt cách mà AWS đơn giản hóa việc cung cấp một máy chủ EC2. Ta chỉ cần tạo một máy ảo theo nhu cầu mỗi khi cần. Ta không cần phải lo lắng về các vấn đề của cơ sở hạ tầng như là việc chọn lựa máy chủ vật lý để chạy.

Tương tự vậy, công-ten-nơ và công cụ điều phối cho phép ta chạy công-ten-nơ mới mà không cần quan tâm tới máy ảo nào chạy ở dưới sẽ nhận tải. Ví dụ, một công cụ điều phối công-ten-nơ như Kubernetes sẽ thực hiện việc quyết định chạy công-ten-nơ trên máy ảo chưa được tận dụng đúng mức (underutilized).

Kubernetes: Hạ tầng hiện đại dành cho ứng dụng hiện đại

Theo dữ liệu khảo sát mới đây từ The New Stack cho thấy việc áp dụng công-ten-nơ là chất xúc tác quan trọng nhất trong việc sử dụng công cụ điều phối (công-ten-nơ). Thực ra, 60% người được hỏi đã triển khai công-ten-nơ trong môi trường sản xuất (production) cũng dựa vào Kubernetes để hỗ trợ điều phối. Có 19% đã triển khai công-ten-nơ trên môi trường sản xuất ở diện rộng cũng bước đầu áp dụng công cụ điều phối.

Vậy, chính xác Kubernetes là gì? Được khởi đầu bởi Google từ 2014, Kubernetes là một dự án mã nguồn mở nhắm tới việc xây dựng một công cụ điều phối mạnh mẽ để chạy hàng ngàn công-ten-nơ trên môi trường sản xuất. Thông qua việc tự động hoá các tiến trình, Kubernetes có thể loại bỏ rất nhiều sự phiền não (painful) của các tác vụ thủ công hay sự phức tạp của cơ sở hạ tầng mà đội DevOps thường gặp phải , (nó) giúp việc triển khai, mở rộng và quản lý ứng dụng công-ten-nơ (containerized applications).

Kubernetes không chỉ giúp ta chạy công-ten-nơ một cách dễ dàng, mà còn (giúp ta) chạy bất cứ loại tải nào cùng với công-ten-nơ. Chìa khoá cho sự trỗi dậy của Kubernetes là khả năng thấu hiểu rằng, khi bạn vận hành một hệ thống, nó không chỉ là việc chạy một công-ten-nơ. Hơn nữa, không phải công-ten-nơ nào cũng giống nhau. Một công-ten-nơ có thể là ứng dụng web, hoặc nó có thể cần lưu trữ dữ liệu liên tục (persistently).

Những câu hỏi phổ biến được Kubernetes giải quyết gồm có:‌‌

• Làm sao để thiết kế ứng dụng gồm nhiều thành phần phức tạp nhưng vẫn dễ triển khai và (dễ) điều phối?‌‌
• Làm sao để thiết kế ứng dụng để có thể dễ dàng chuyển từ “đám mây” này sang (“đám mây”) khác? ‌‌
• Làm sao để giữ cho việc lưu trữ đồng nhất với nhiều bản sao (công-ten-nơ) của một ứng dụng?‌‌
• Làm sao để đảm bảo tải được chia đều trên tất cả công-ten-nơ?‌‌
• Làm sao để tận dụng các năng lực kỹ thuật phát triển, thiết kế phần mềm sẵn có mà không cần đào sâu vào mảng khác khiến cho (việc phát triển phần mềm) chậm lại?

Ngay cả khi Kubernetes vươn lên trở thành tiêu chuẩn (de facto) của hệ thống điều phối công-ten-nơ, vẫn có nhiều quan niệm sai lầm về nó. Trước tiên, nhiều người ban đầu không hiểu sự khác biệt giữa Docker và Kubernetes. Nói một cách đơn giản, Docker là một công cụ được dùng để tạo công-ten-nơ trong khi Kubernetes cung cấp việc quản lý những Docker công-ten-nơ đó. Một sự nhầm lẫn khác là Kubernetes không phải là giải pháp nền tảng (PaaS), thực ra ta có thể dùng nó như một nền tảng để phát triển PaaS nếu muốn.

Cách Kubernetes hoạt động

Trong Kubernetes, mỗi máy (node) chạy nhiều dịch vụ với nền tảng Docker (Docker engine) dù là môi trườngảo hóa hay máy chủ vật lý. Có 2 loại máy: một máy chính (master) đóng vai trò như một bộ điều khiển của một cụm máy thực thi (worker) - nơi được sử dụng để chạy hoặc lưu trữ các dịch vụ của chúng ta dưới dạng công-ten-nơ.

Trong máy thực thi, ta có một khái niệm”pod” (/ päd /) đại diện cho 1 đơn vị công việc (unit of work) hoặc một tập hợp các công-ten-nơ được triển khai trên cùng một máy. Thường thì ta chạy một công-ten-nơ hoặc một dịch vụ trong một”pod”. Tuy nhiên, cũng có trường hợp chạy nhiều công-ten-nơ cùng trên một “pod” là hợp lý nếu chúng liên kết chặt chẽ với nhau.

Kubernetes kết nối pod vào môi trường và quản lý pod, gồm mở rộng, triển khai cuốn chiếu (rolling deployments) và giám sát. Các pod có IP riêng - nghĩa là ứng dụng có thể dễ dàng tìm dịch vụ thông qua (chức năng) tìm kiếm / phát hiện dịch vụ của Kubernetes (service discovery).

Tiếp đến là khái niệm “service”. Một “service” nhóm các pod có cùng chức năng thành một tập hợp để thể hiện dưới dạng một thực thể duy nhất (single entity). Khi một “service” được tạo ra, tất cả các máy trong cụm đều được biết về “service” mới đó. Những gì (“service”) đang làm là cung cấp một điểm truy cập duy nhất nhằm đơn giản hoá việc kết nối một cách thuận tiện giữa các “pod”. Việc triển khai một “service” giúp đơn giản hóa thiết kế công-ten-nơ và giúp người dùng dễ dàng tìm kiếm / phát hiện công-ten-nơ (container discovery).

“label” là một khái niệm về tổ chức, (“label”) tạo ra một thẻ siêu dữ liệu (metadata) cho tài nguyên của Kubernetes nhằm dễ đang tìm kiếm. Nó cho phép lập trinh viên dễ dàng truy vấn dựa trên cách đánh nhãn (labeled). Do một loạt chức năng của Kubernetes phụ thuộc vào việc truy vấn vào cụm (máy chủ Kubernetes) để lấy tài nguyên được hoạch định, nên với khả năng đánh nhãn (label) tài nguyên là rất quan trọng để đảm bảo hiệu quả (làm việc) của lập trinh viên. “Label” là nền móng để cho cả “services” và “replication controllers” hoạt động.

“volume” đại diện cho vị trí mà công-ten-nơ có thể truy cập và lưu trữ thông tin. Đối với ứng dụng, “volume” thể hiện như là một phần của hệ thống tập tin nội bộ (local filesystem). Tuy nhiên “volume” có thể được hỗ trợ bởi đĩa lưu trữ nội bộ (local storage), CEPH, Gluster, Elastic Block Storage, và hàng loạt các hệ thống lưu trữ phụ trợ khác (storage backend).

“namespace” hoạt động như một cơ chế nhóm (grouping mechanism) trong Kubernetes. “Service”, “pod”, “replication controller” và “volume” có thể dễ dàng phối hợp trong “namespace”, tuy nhiên “namespace” cũng cung cấp một cấp độ cô lập với các phần khác của cụm.

“replication controller” được thiết kế để duy trì số lượng “pod” mà người dùng yêu cầu – (nên nó) cho phép mở rộng (số lượng pods) dễ dàng. Nếu một công-ten-nơ bị “chết” (goes down), “replication controller” sẽ chạy một công-ten-nơ khác lên, nhằm đảm bảo luôn có sẵn chinh xác số lượng bản sao của “pod”.

Toàn cảnh về (bộ) điều phối công-ten-nơ

Có một vài công cụ khác cũng cung cấp khả năng điều phối công-ten-nơ. Hai đối thủ lớn nhất cạnh tranh với Kubernetes là Docker Swarm và Mesosphere DC / OS. Docker Swarm là một lựa chọn dễ dùng, đánh vào phần chịu nhiều lời chỉ trích nhất xung quanh việc vô cùng phức tạp để triển khai và quản lý của Kubertes. Mesosphere DC / OS là một bộ điều phối công-ten-nơ được thiết kế cho dữ liệu lớn. Nó được thiết kế để chạy các công-ten-nơ cùng với những tải (workload) khác như học máy và dữ liệu lớn và cung cấp việc tích hợp với các công cụ liên quan như Apache Spark và Apache Cassandra. Nhìn chung, Kubernetes hiện đang (là công cụ) trưởng thành và phổ biến nhất trong cả 3, bằng chứng là của số lượng người đóng góp trong cộng đồng và việc áp dụng trong doanh nghiệp. Chìa khóa thành công của Kubernetes không chỉ là khả năng cung cấp các cấu phần (building block) để khởi chạy và giám sát các công-ten-nơ, mà còn tập trung nỗ lực tạo ra các cách sử dụng công-ten-nơ khác nhau nền tảng (đó) để giải quyết các loại tải (workload) khác nhau.

Ví dụ trong Kubernetes, có những đối tượng gốc (native objects), những thực thể riêng (native entities) trong hệ thống cho phép ta chạy một trinh nền (daemon), hoặc chạy một công-ten-nơ hoặc chạy một cơ sở dữ liệu. Các giải pháp khác, không có sự phân biệt giữa các công-ten-nơ đang chạy đâu đó có thể dẫn đến việc (công-ten-nơ) bị phá hủy bất cứ lúc nào.

Kubernetes đang thay đổi kiến trúc vi dịch vụ.

Tác động của bộ khung (framework) kiến trúc vi dịch vụ đối với sự phát triển của các giải pháp CNTT trong các doanh nghiệp hiện nay là rõ nét. Ở thượng tầng, (kiến trúc) vi dịch vụ cho phép các ứng dụng được thiết kế thành các dịch vụ độc lập nhỏ hơn, không phụ thuộc vào một ngôn ngữ lập trình cụ thể. Điều này có nghĩa là khi chúng ta đang xây dựng một ứng dụng nguyên khối (monolithic), kiến trúc vi dịch vụ cho phép một đơn vị kỹ thuật (engineering organization) chia tách ứng dụng thành các cấu phần khác nhau và không phụ thuộc vào nhau. Thay vào đó, các thành phần có thể kết hợp để cung cấp toàn bộ chức năng của ứng dụng nguyên khối.

Các thành phần hoặc các vi dịch vụ này giao tiếp với nhau thông qua API. Và vì nó không phụ thuộc vào ngôn ngữ lập trình, có thể có nhiều nhóm (lập trinh) xây dựng các thành phần khác nhau trên nhiều ngôn ngữ (khác nhau) mà không gặp bất kỳ vấn đề tương thích nào. Ví dụ: có một đội chạy vi dịch vụ ngôn ngữ Ruby trong công-ten-nơ giao tiếp liền mạch với một vi dịch vụ chạy ngôn ngữ Python trong công-ten-nơ thông qua Kubernetes.

Khi áp dụng kiến trúc vi dịch vụ, một việc rất quan trọng là tìm ra cách giám sát các dịch vụ khác nhau. Đây là điểm mà Kubernetes và công cụ đang phát triển thuộc hệ sinh thai của nó đang hướng tới (come in to the picture). Kubernetes cung cấp thêm lựa chọn cho các tổ chức chuyển dịch từ máy ảo sang công-ten-nơ. Kubernetes đã hoàn thành một việc tuyệt vời là thúc đẩy một hệ sinh thái xung quanh mình để khi sử dụng Kubernetes, chúng ta đã biết trước (know that out of the box) là có các công cụ giám sát, công cụ CI / CD và nhiều nền tảng hỗ trợ Kubernetes.

Do đó, việc quyết định sử dụng Kubernetes không chỉ là lựa chọn công cụ điều phối công-ten-nơ nào được sử dụng mà còn hỗ trợ chiến lược vi dịch vụ của tổ chức. Những gì các tổ chức đang cân nhắc cũng là những gì mà công cụ của hệ sinh thái bổ sung được thiết kế. Hệ sinh thái Kubernetes cung cấp tất cả các cấu phần (building block) cho mọi thứ chúng ta cần để tận dụng (công nghệ) công-ten-nơ nhằm xây dựng một kiến trúc vi dịch vụ vững vàng (rock solid).

Một tương lai sáng lạn

Công-ten-nơ đang nhanh chóng bao trùm thế giới phát triển phần mềm. Và động lực đằng sau - Kubernetes - tương lai của cơ sở hạ tầng sẽ không dừng lại bất cứ lúc nào. Nó đã trở thành công cụ điều phối công-ten-nơ hàng đầu (the go to container orchestrator ) bởi chuyên môn sâu, khả năng áp dụng doanh nghiệp và hệ sinh thái mạnh mẽ. Số lượng của các cá nhân, các tổ chức cung cấp dịch vụ CNTT ủng hộ bộ khung (framework) ngày một tăng, Kubernetes sẽ tiếp tục cải thiện và mở rộng các tính năng, các loại ứng dụng được hỗ trợ và khả năng tích hợp với hệ sinh thái tổng thể (overarching ecosystem).