Tại sao Kubernetes là Máy chủ ứng dụng mới

toannm

Đã có ai tự hỏi tại sao lại phải triển khai các ứng dụng đa nền tảng bằng cách sử dụng các container chưa? Có phải đó chỉ là vấn đề của những người “theo xu hướng”? Bài viết này đưa ra một số câu hỏi để trả lời cho câu hỏi Tại sao Kubernetes là máy chủ ứng dụng mới.

Có thể nhận thấy rằng phần lớn các ngôn ngữ được diễn giải và sử dụng các runtimes của Wap để thực thi mã nguồn. Về lý thuyết, hầu hết code Node.js, Python và Ruby có thể dễ dàng di chuyển từ một nền tảng (Windows, Mac, Linux) sang nền tảng khác. Các ứng dụng Java còn đi xa hơn bằng cách biến lớp Java được biên dịch thành bytecode, có khả năng chạy bất cứ nơi nào có JVM (Máy ảo Java).

Hệ sinh thái Java cung cấp một định dạng chuẩn để phân phối tất cả các lớp Java là một phần của cùng một ứng dụng. Có thể đóng gói các lớp này dưới dạng JAR (Java Archive), WAR (Web Archive) và EAR (Enterprise Archive) có front end, back end và thư viện nhúng. Vì vậy, câu hỏi ở đây là: Tại sao phải sử dụng các container để phân phối ứng dụng Java? Liệu có dễ dàng để di chuyển giữa các môi trường?

Trả lời câu hỏi này từ góc độ nhà phát triển là luôn không rõ ràng. Nhưng hãy suy nghĩ một chút về môi trường phát triển và một số vấn đề có thể xảy ra do sự khác biệt giữa nó và môi trường sản xuất:

  • Có sử dụng Mac, Windows hoặc Linux không? Đã bao giờ phải đối mặt với một vấn đề liên quan đến trình phân tách đường dẫn tệp chưa?
  • Phiên bản JDK nào đang được sử dụng? Có đang sử dụng Java 10 trong phát triển, nhưng sản xuất sử dụng JRE 8 không? Đã phải đối mặt với bất kỳ lỗi nào bởi sự khác biệt của JVM chưa?
  • Phiên bản nào của máy chủ ứng dụng đang được sử dụng? Là môi trường sản xuất sử dụng cùng cấu hình, bản vá bảo mật và phiên bản thư viện?
  • Trong quá trình triển khai sản xuất, có gặp phải sự cố trình điều khiển JDBC mà đã gặp phải trong môi trường phát triển do các phiên bản khác nhau của trình điều khiển hoặc máy chủ database không?
  • Đã bao giờ phải yêu cầu quản trị viên máy chủ ứng dụng tạo datasource hoặc hàng đợi JMS và nó có lỗi đánh máy chưa.
Tất cả các vấn đề ở trên là do các yếu tố bên ngoài ứng dụng và một trong những điều tuyệt vời nhất về container là có thể triển khai mọi thứ (ví dụ: bản phân phối Linux, JVM, máy chủ ứng dụng, thư viện, cấu hình và cuối cùng là ứng dụng) bên trong một container được xây dựng sẵn. Thêm vào đó, việc thực thi một container duy nhất có mọi thứ được tích hợp dễ dàng hơn nhiều so với việc chuyển code sang môi trường sản xuất và cố gắng giải quyết các khác biệt khi nó không hoạt động. Vì nó rất dễ thực hiện, nên cũng dễ dàng chia tỷ lệ cùng một hình ảnh container thành nhiều replicas.

Trao quyền cho ứng dụng

Trước khi các container trở nên phổ biến, một số NFR (non-functional requirements - yêu cầu phi chức năng) như bảo mật, cách ly, chịu lỗi, quản lý cấu hình và các loại khác được cung cấp bởi các máy chủ ứng dụng. Tương tự như vậy, các máy chủ ứng dụng đã được lên kế hoạch để trở thành ứng dụng cho trình phát CD.

Một nhà phát triển sẽ có trách nhiệm tuân theo một tiêu chuẩn được xác định trước và phân phối ứng dụng theo một định dạng cụ thể, trong khi đó, máy chủ ứng dụng sẽ “thực thi” ứng dụng và cung cấp các khả năng bổ sung có thể khác nhau từ các “brand” khác nhau. Lưu ý: Trong thế giới Java, tiêu chuẩn cho các khả năng của doanh nghiệp được cung cấp bởi một máy chủ ứng dụng gần đây đã được chuyển theo nền tảng Eclipse. Công việc trên Eclipse Enterprise cho Java (EE4J), đã dẫn đến Jakarta EE. (Để biết thêm thông tin, hãy đọc bài viết Jakarta EE chính thức hoặc xem video DevNation: Jakarta EE: Jakarta EE: The future of Java EE.)

Theo cùng một cách tương tự trình phát CD, với sự tăng dần của các container, hình ảnh container đã trở thành định dạng CD mới. Trong thực tế, một hình ảnh container không có gì khác hơn là một định dạng để phân phối các container. (Nếu cần xử lý tốt hơn về hình ảnh container là gì và cách chúng được phân phối, hãy xem A Practical Introduction to Container Terminology.)

Lợi ích thực sự của container xảy ra khi cần thêm khả năng doanh nghiệp vào ứng dụng. Và cách tốt nhất để cung cấp các khả năng này cho một ứng dụng được container hóa là sử dụng Kubernetes làm nền tảng cho chúng. Ngoài ra, nền tảng Kubernetes cung cấp nền tảng tuyệt vời cho các dự án khác như Red Hat OpenShift, Istio và Apache OpenWhisk để xây dựng và giúp dễ dàng xây dựng và triển khai các ứng dụng chất lượng sản xuất mạnh mẽ.

Hãy cùng khám phá chín trong số các khả năng này:

Screenshot-2018-05-18-21.20.31-2.png

1 - Khám phá dịch vụ

Khám phá dịch vụ là quá trình tìm ra cách kết nối với dịch vụ. Để có được nhiều lợi ích của container và ứng dụng cloud-native, cần xóa cấu hình khỏi hình ảnh container để có thể sử dụng cùng một hình ảnh container trong tất cả các môi trường. Cấu hình bên ngoài từ các ứng dụng là một trong những nguyên tắc chính của ứng dụng 12 yếu tố. Khám phá dịch vụ là một trong những cách để lấy thông tin cấu hình từ môi trường runtime thay vì nó được mã hóa cứng trong ứng dụng.

Kubernetes cung cấp dịch vụ khám phá đặc biệt. Kubernetes cũng cung cấp ConfigMaps và Secrets để xóa cấu hình khỏi container. Secrets giải quyết một số thách thức phát sinh khi cần lưu trữ thông tin đăng nhập để kết nối với dịch vụ như cơ sở dữ liệu trong môi trường runtime.

Với Kubernetes, không có nhu cầu sử dụng máy chủ hoặc framework bên ngoài. Mặc dù có thể quản lý cài đặt môi trường cho từng môi trường runtime thông qua các tệp YAML của Kubernetes, Red Hat OpenShift cung cấp GUI và CLI có thể giúp các nhóm DevOps dễ dàng quản lý hơn.

2 - Invoke cơ bản

Các ứng dụng chạy bên trong các container có thể được truy cập thông qua truy cập Ingress, nói cách khác, các tuyến đường từ thế giới bên ngoài đến dịch vụ đang được tiếp xúc. OpenShift cung cấp các đối tượng định tuyến bằng HAProxy, có một số khả năng và chiến lược cân bằng tải. Có thể sử dụng các khả năng định tuyến để thực hiện triển khai cán. Đây có thể là cơ sở của một số chiến lược CI / CD rất tinh vi. Xem “Phần 6 - Xây dựng và triển khai các Pipeline” dưới đây.

Điều gì sẽ xảy ra nếu cần chạy một công việc một lần, chẳng hạn như quy trình hàng loạt hoặc đơn giản là tận dụng cụm để tính kết quả (chẳng hạn như tính toán các chữ số của Pi)? Kubernetes cung cấp các đối tượng công việc cho trường hợp sử dụng này. Ngoài ra còn có một công việc định kỳ quản lý các công việc dựa trên thời gian.

3 - Elasticity

Elasticity được giải quyết trong Kubernetes bằng cách sử dụng ReplicaSets (được gọi là Bộ điều khiển nhân rộng). Giống như hầu hết các cấu hình cho Kubernetes, ReplicaSet là một cách để điều hòa trạng thái mong muốn: nói với Kubernetes trạng thái của hệ thống và Kubernetes tìm ra cách làm cho nó trở nên như vậy. ReplicaSet kiểm soát số lượng bản sao hoặc bản sao chính xác của ứng dụng sẽ chạy bất cứ lúc nào.

Nhưng điều gì xảy ra khi xây dựng một dịch vụ thậm chí còn phổ biến hơn dự định và hết tính toán? Có thể sử dụng Kubernetes Horizontal Pod Autoscaler, chia tỷ lệ số lượng pod dựa trên mức độ sử dụng CPU được quan sát (hoặc, với sự hỗ trợ số liệu tùy chỉnh, trên một số số liệu do ứng dụng cung cấp khác).

4 - Logging

Vì cụm Kubernetes có thể và sẽ chạy một số bản sao của ứng dụng được container hóa, điều quan trọng là phải tổng hợp các log này để chúng có thể được xem ở một nơi. Ngoài ra, để sử dụng các lợi ích như tự động cân bằng (và các khả năng cloud-native khác), các container cần phải bất biến. Vì vậy, cần lưu trữ log bên ngoài container để chúng sẽ tồn tại trong suốt quá trình chạy. OpenShift cho phép triển khai ngăn xếp EFK để tổng hợp các bản ghi từ máy chủ và ứng dụng, cho dù chúng đến từ nhiều container hoặc thậm chí từ các pod bị xóa.

Ngăn xếp EFK bao gồm:

  • Elaticsearch (ES), một kho lưu trữ đối tượng nơi lưu trữ tất cả các log
  • Fluentd, tập hợp các bản ghi từ các nút và đưa chúng vào Elaticsearch
  • Kibana, giao diện người dùng web cho Elaticsearch
5 - Giám sát

Mặc dù việc logging và giám sát dường như giải quyết cùng một vấn đề, nhưng chúng khác nhau. Giám sát là quan sát, kiểm tra, thường xuyên cảnh báo, cũng như ghi âm. Logging là chỉ ghi mà thôi.

Prometheus là một hệ thống giám sát nguồn mở bao gồm cơ sở dữ liệu chuỗi thời gian. Nó có thể được sử dụng để lưu trữ và truy vấn các số liệu, cảnh báo và sử dụng trực quan hóa để hiểu rõ hơn về hệ thống. Prometheus có lẽ là lựa chọn phổ biến nhất để theo dõi các cụm Kubernetes. Trên blog của Red Hat Developers, có một số bài viết về giám sát bằng Prometheus. Cũng có thể tìm thấy các bài viết của Prometheus trên blog OpenShift.

Và cũng có thể thấy Prometheus hoạt động cùng với Istio tại https://learn.openshift.com/servicemesh/3-monitoring-tracing.

6 - Xây dựng và triển khai Pipeline

Các CI / CD pipline không phải là một yêu cầu nghiêm ngặt “bắt buộc phải có” đối với các ứng dụng. Tuy nhiên, CI / CD thường được trích dẫn là trụ cột của sự phát triển phần mềm và thực hành DevOps thành công. Không có phần mềm nào nên được triển khai vào sản xuất mà không có CI / CD pipeline. Cuốn sách Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation của Jez Humble và David Farley, nói về CD: “Giao hàng liên tục là khả năng nhận được các thay đổi - của tất cả các loại hình bao gồm các tính năng mới, thay đổi cấu hình, sửa lỗi và thử nghiệm - vào sản xuất, hoặc vào tay người dùng, một cách an toàn và nhanh chóng một cách bền vững.

OpenShift cung cấp các CI / CD pipeline đặc biệt như một “chiến lược xây dựng”. Hãy xem video này mà đã được ghi lại hai năm trước, trong đó có một ví dụ về CI / CD pieline của Jenkins triển khai một microservice mới.

7 - Khả năng phục hồi

Mặc dù Kubernetes cung cấp các tùy chọn khả năng phục hồi cho chính cụm, nó cũng có thể giúp ứng dụng có khả năng phục hồi bằng cách cung cấp PersistentVolume hỗ trợ các khối lượng được nhân rộng. ReplicationControllers/ triển khai của Kubernetes đảm bảo rằng số lượng pod replicas được chỉ định được triển khai nhất quán trên toàn cụm, tự động xử lý bất kỳ lỗi node nào có thể xảy ra.

Cùng với khả năng phục hồi, khả năng chịu lỗi đóng vai trò là phương tiện hiệu quả để giải quyết vấn đề về độ tin cậy và tính khả dụng của người dùng. Khả năng chịu lỗi cũng có thể được cung cấp cho một ứng dụng đang chạy trên Kubernetes thông qua Istio bằng các quy tắc thử lại, bộ ngắt mạch và pool ejection. Nếu muốn tìm hiểu thêm về nó thì hãy thử hướng dẫn Istio cho Circuit Breaker tại https://learn.openshift.com/servicemesh/7-circuit-breaker.

8 - Xác thực

Xác thực trong Kubernetes cũng có thể được Istio cung cấp thông qua xác thực TLS lẫn nhau, nhằm mục đích tăng cường bảo mật cho microservice và giao tiếp của họ mà không yêu cầu thay đổi code dịch vụ. Nó chịu trách nhiệm cho:
  • Cung cấp cho mỗi dịch vụ một cái tôi mạnh mẽ thể hiện vai trò của nó để cho phép khả năng tương tác giữa các cụm và cloud
  • Đảm bảo liên lạc giữa dịch vụ với dịch vụ và giao tiếp giữa người dùng cuối với dịch vụ
  • Cung cấp một hệ thống quản lý khóa để tự động hóa việc tạo khóa, phân phối, luân chuyển và thu hồi khóa
Ngoài ra, điều đáng nói là cũng có thể chạy Keycloak bên trong cụm Kubernetes / OpenShift để cung cấp cả xác thực và ủy quyền. Keycloak là sản phẩm ngược dòng cho Đăng nhập một lần của Red Hat. Để biết thêm thông tin, hãy đọc Single-Sign On Made Easy with Keycloak. Nếu đang sử dụng Spring Boot, hãy xem video DevNation: Secure Spring Boot Microservices with Keycloak or read the blog article.

9 - Truy tìm

Các ứng dụng hỗ trợ Istio có thể được cấu hình để thu thập các dấu vết bằng cách sử dụng Zipkin hoặc Jaeger. Bất kể ngôn ngữ, framework hoặc nền tảng nào đang được sử dụng để xây dựng ứng dụng, Istio có thể cho phép theo dõi phân tán. Hãy xem thử tại https://learn.openshift.com/servicemesh/3-monitoring-tracing.

Xem thêm Getting Started with Istio and Jaeger on your laptop và video DevNation gần đây: Advanced microservices tracing with Jaeger.

Máy chủ ứng dụng đã chết?

Vượt qua các khả năng này, có thể nhận ra cách Kubernetes + OpenShift + Istio thực sự có thể trao quyền cho ứng dụng và cung cấp các tính năng từng là trách nhiệm của máy chủ ứng dụng hoặc framework phần mềm như Netflix OSS. Điều đó có nghĩa là các máy chủ ứng dụng đã chết?

Trong thế giới container hóa mới này, các máy chủ ứng dụng đang biến đổi trở nên giống như các framework hơn. Nó tự nhiên rằng sự phát triển của phát triển phần mềm gây ra sự phát triển của các máy chủ ứng dụng. Một ví dụ tuyệt vời về sự tiến hóa này là đặc tả MicroProfile Eclipse có WildFly Swarm làm máy chủ ứng dụng, cung cấp các tính năng của nhà phát triển như khả năng chịu lỗi, cấu hình, theo dõi, REST (máy khách và máy chủ), v.v. Tuy nhiên, WildFly Swarm và đặc tả MicroProfile được thiết kế rất nhẹ. WildFly Swarm hiện không có nhiều thành phần được yêu cầu bởi một máy chủ ứng dụng doanh nghiệp Java đầy đủ. Thay vào đó, nó tập trung vào microservice và có đủ máy chủ ứng dụng để xây dựng và chạy ứng dụng dưới dạng tệp .jar đơn giản. Có thể đọc thêm về MicroProfile trên blog này.

Hơn nữa, các ứng dụng Java có thể có các tính năng như công cụ Servlet, nhóm nguồn dữ liệu, nội dung phụ thuộc, giao dịch, nhắn tin, v.v. Tất nhiên, các framework có thể cung cấp các tính năng này, nhưng một máy chủ ứng dụng cũng phải có mọi thứ cần có để xây dựng, chạy, triển khai và quản lý các ứng dụng doanh nghiệp trong bất kỳ môi trường nào, bất kể chúng có ở trong các container hay không. Trên thực tế, các máy chủ ứng dụng có thể được thực thi ở mọi nơi, ví dụ, trên máy chủ vật lý, trên các nền tảng ảo hóa như Red Hat Virtualization, trên các môi trường private cloud như Red Hat OpenStack Platform và cả trên các môi trường public cloud như Microsoft Azure hoặc Amazon Web Services.

Một máy chủ ứng dụng tốt đảm bảo tính nhất quán giữa các API được cung cấp và việc triển khai chúng. Các nhà phát triển có thể chắc chắn rằng việc triển khai logic kinh doanh của họ, đòi hỏi một số khả năng nhất định, sẽ hoạt động vì các nhà phát triển máy chủ ứng dụng (và các tiêu chuẩn đã xác định) đã đảm bảo rằng các thành phần này hoạt động cùng nhau và đã phát triển cùng nhau. Hơn nữa, một máy chủ ứng dụng tốt cũng chịu trách nhiệm tối đa hóa thông lượng và khả năng mở rộng, bởi vì nó sẽ xử lý tất cả các yêu cầu từ người dùng; giảm độ trễ và cải thiện thời gian tải, bởi vì nó sẽ giúp ứng dụng có thể xử lý được; gọn nhẹ với một dấu chân nhỏ giúp giảm thiểu tài nguyên và chi phí phần cứng; và cuối cùng, đủ an toàn để tránh mọi vi phạm an ninh. Đối với các nhà phát triển Java, Red Hat cung cấp Nền tảng ứng dụng doanh nghiệp Red Hat JBoss, đáp ứng tất cả các yêu cầu của một máy chủ ứng dụng mô-đun hiện đại.

Phần kết luận

Hình ảnh container đã trở thành định dạng đóng gói tiêu chuẩn để phân phối các ứng dụng cloud-native. Trong khi các container trên mỗi vùng không cung cấp lợi thế kinh doanh thực sự cho các ứng dụng, Kubernetes và các dự án liên quan của nó, như OpenShift và Istio, cung cấp các yêu cầu phi chức năng từng là một phần của máy chủ ứng dụng.

Hầu hết các yêu cầu phi chức năng này mà các nhà phát triển đã sử dụng để nhận được từ máy chủ ứng dụng hoặc từ thư viện như Netflix OSS bị ràng buộc với một ngôn ngữ cụ thể, ví dụ, Java. Mặt khác, khi các nhà phát triển chọn đáp ứng các yêu cầu này bằng Kubernetes + OpenShift + Istio, họ không được gắn với bất kỳ ngôn ngữ cụ thể nào, điều này có thể khuyến khích sử dụng công nghệ / ngôn ngữ tốt nhất cho từng trường hợp sử dụng.

Cuối cùng, các máy chủ ứng dụng vẫn có chỗ đứng trong phát triển phần mềm. Tuy nhiên, chúng đang biến đổi trở nên giống với các framework cụ thể hơn về ngôn ngữ, là một lối tắt tuyệt vời khi phát triển các ứng dụng, vì chúng chứa rất nhiều chức năng đã được viết và thử nghiệm.

Một trong những điều tốt nhất khi chuyển sang container, Kubernetes và microservice là không phải chọn một máy chủ ứng dụng, framework, kiểu kiến trúc hoặc thậm chí ngôn ngữ cho ứng dụng. Có thể dễ dàng triển khai một container với JBoss EAP chạy ứng dụng Java EE hiện tại, bên cạnh các container khác có microservice mới sử dụng Wildfly Swarm hoặc Eclipse Vert.x để lập trình phản ứng. Những container này đều có thể được quản lý thông qua Kubernetes. Để thấy khái niệm này hoạt động, hãy xem Red Hat OpenShift Application Runtimes. Sử dụng Launch service để xây dựng và triển khai một ứng dụng mẫu trực tuyến bằng WildFly Swarm, Vert.x, Spring Boot hoặc Node.js. Chọn nhiệm vụ Externalized Configuration để tìm hiểu cách sử dụng Kubernetes ConfigMaps. Điều này sẽ giúp người mới bắt đầu trên con đường của riêng bản thân đến các ứng dụng cloud-native.

Có thể nói rằng Kubernetes / OpenShift là Linux mới hoặc thậm chí “Kubernetes là máy chủ ứng dụng mới”. Nhưng thực tế là một máy chủ ứng dụng / runtime + OpenShift / Kubernetes + Istio đã trở thành nền tảng ứng dụng cloud-native “thực tế”!
Nguồn:
 
Sửa lần cuối bởi điều hành viên:

Kiều Trí Đăng

Bài viết này rõ ràng là dùng công cụ dịch lại. Nên ghi rõ nguồn để ai có nhu cầu xem bản gốc thì click vào nhé.
 
Top