Kubernetes Service là gì ? Tự học Kubernetes từ A-Z – phần 4

Mở đầu

Serverless trên Kubernetes làm giảm việc cấu hình lặp đi lặp lại với nhà cung cấp đám mây. Nó chỉ là kết quả của việc liên tục tự động hóa công việc thủ công.

Khi chúng ta nói về việc serverless trên Kubernetes, cần xem xét hai lĩnh vực khác nhau:

1. Triển khai các ứng dụngs serverless trong cluster (giảm số lượng tệp YAML cần thiết cho mỗi ứng dụng + bộ chứa tự động xây dựng)
2. chạy pods container serverless mà không cần quản lý các nodes/ VM

Serverless

Bạn sẽ tương tác ít hơn với máy chủ và cơ sở hạ tầng cần thiết để chạy các ứng dụng. Khi sử dụng từ “serverless”, nó có chỉ có hai điều khác nhau: CaaS và FaaS.

CaaS — Container as a Service

Bạn tạo container (Docker), quăng nó vào CaaS và nó chạy, nó tự phục vụ và tự scale tự động

Các ví dụ là Azure Container Instances, Google Cloud Run hoặc AWS Fargate.

FaaS — Function as a Service

Bạn viết code, quăng nó vào FaaS và tự chạy, tự phục vụ và tự scale tự động.

Các ví dụ được quản lý là Azure Functions, Functions Google hoặc AWS Lambda.

FaaS hoạt động như thế nào?

Cách FaaS chạy code của bạn có thể xảy ra theo những cách khác nhau. FaaS thực sự build container cho mỗi thay đổi code và sau đó CaaS được sử dụng như thế này:

Một cách khác có thể là FaaS lấy functions sourcecode vào môi trường được xác định trước (container) một cách linh hoạt trong khi khởi động. Môi trường sẽ có sẵn các ngôn ngữ lập trình khác nhau. Khi sử dụng một ngôn ngữ biên dịch như Go, thì việc biên dịch cũng phải thực hiện khi khởi động.

Events / Scaling

FaaS hầu hết thời gian được sử dụng cùng với các hệ thống event(sự kiện) kích hoạt việc khởi tạo functions. Các event có thể bắt nguồn từ API-Gateways, Github, Kafka, RabbitMQ, CronJobs, v.v.

Đối với mỗi event, một function mới được tạo để xử lý. Nếu có nhiều event xảy ra cùng một lúc, nhiều trường hợp sẽ được tạo để xử lý những event này. Bằng cách này, chúng ta có automatic scaling( tự động phóng to thu nhỏ)

FaaS giao tiếp với các nguồn event khác nhau, do đó, các functions mà không cần phải thực hiện. Họ chỉ làm việc với một định dạng event mà FaaS sử dụng, như CloudEvents hoặc vận chuyển qua HTTP.

Dự án CloudEvents mô tả cấu trúc và siêu dữ liệu của các event dưới dạng “standard” (tiêu chuẩn). Nó cũng bao gồm dữ liệu và lược đồ mô tả dữ liệu đó. Các event trên đám mây bao bọc dữ liệu event. Điều này có thể là tuyệt vời nếu được nhiều nhà cung cấp áp dụng để có được khả năng tương tác.

App Kubernetes

Chúng ta hãy xem các bước cần thiết để phát triển một ứng dụng non-serverless chạy trên Kubernetes:

Chúng ta cần xây dựng một container, tạo các tài nguyên Kubernetes khác nhau (các tệp YAML) và sau đó quyết định có bao nhiêu node hoạt động, chúng ta cần để chạy ứng dụng của mình.

Quyết định có bao nhiêu node mà chúng ta cần có thể được xử lý linh hoạt hơn bằng cách định cấu hình autoscaler Cluster / Node. Mặc dù sau đó chúng ta vẫn phải cấu hình nó và cần đặt số lượng node tối thiểu và tối đa.

Chúng ta tương tác với các “servers” bằng cách tiếp cận truyền thống này. Đầu tiên tạo / build container, rồi viết các tệp YAML. Và cũng xác định số lượng và tài nguyên của các node.

App Kubernetes Serverless

Giờ hãy cùng khám phá các phương pháp tiếp cận serverless khi phát triển ứng dụng cho Kubernetes.

CaaS — Container as a Service

Ở đây chúng ta giảm lượng tài nguyên Kubernetes (tệp YAML) sẽ được tạo đáng kể. CaaS sẽ tạo ra tất cả các nguồn con cần thiết như routing tự động, routing Ingress hoặc Istio.

Tất cả những gì chúng ta làm là cung cấp container (Docker) và tạo một tài nguyên k8s duy nhất. CaaS quyết định khi nào start ứng dụng, có thể dựa trên các events hoặc dựa trên định nghĩa.

Chúng ta phải đảm bảo rằng container đã xây dựng có thể nhận và xử lý các events đến từ CaaS có thể thông qua HTTP hoặc CloudEvents chẳng hạn. Điều này có thể yêu cầu một số thư viện bên trong container.

FaaS — Function as a Service

FaaS function.yml sẽ chứa resource K8s từ hệ thống FaaS. Trong resource, chúng ta đặt những thứ như tên hàm, vị trí của mã nguồn, thời gian chạy ngôn ngữ và trigger events

Nếu chúng ta upload code thông qua một giao diện web thì việc tạo FaaS function.yaml không cần thiết.

Với FaaS, chúng ta cũng có mọi thứ mà giải pháp CaaS cung cấp. Bây giờ chúng ta giảm công việc hơn nữa bởi vì có các công cụ chạy trong cluster Kubernetes có thể thực thi / xây dựng mã nguồn ứng dụng trực tiếp.

Container được build đã bao gồm các thư viện cần thiết HTTP hoặc CloudEvents, để nhận các event từ FaaS. Chúng ta không phải lo lắng về điều đó.

Source có thể được lưu trữ trong repo Git, được tải lên qua webinterface hoặc có sẵn ở một nơi khác. FaaS truy cập code, listen các thay đổi, xây dựng vùng chứa và sau đó chuyển đến CaaS phục vụ event.

Cold và warm starts

Cold starts(khởi đầu lạnh) có nghĩa là không có nhóm nào đang chạy để xử lý một event, do đó, nó sẽ mất một chút thời gian để tạo ra nó. Thông thường, các pod này sẽ tồn tại một chút sau khi chúng được sử dụng lần cuối và có thể được sử dụng lại.

Warm start(khởi đầu ấm áp) luôn được sẵn sàng chạy và tiếp nhận bất kì event. Warm start nhanh hơn nhưng cũng tốn tài nguyên.

Fission / Môi trường dựa FaaS

Một ví dụ FaaS của K8s, Fission, không thực sự xây dựng các containers bất biến cho mỗi function nhưng sử dụng ý tưởng về các containers môi trường có thể thay đổi để lấy codemột cách linh hoạt để sau đó chuyển đổi chúng thành các function cụ thể của pod

Khả năng quan sát

Chuyển từ các microservices được đóng gói sang các function có thể dẫn đến việc phải quản lý các services thậm chí nhiều hơn và nhỏ hơn trước đây. Điều này được gây ra bởi tạo các chức năng quá dễ dàng chỉ listen và xử lý một event duy nhất.

Để quản lý số lượng service hoặc function cao hơn cần thiết để giữ khả năng quan sát (số liệu, logging, tracing). Đây là lý do tại sao hầu hết Kubernetes FaaS và CaaS đã tích hợp với ví dụ Prometheus, Jaeger và service mesh như Istio hoặc Linkerd.

Node Kubernetes Serverless

Trong phần trước chúng ta đã nói về các ứng dụng serverless của K8s và chúng ta đã thấy các quy trình công việc khi sử dụng CaaS hoặc FaaS. Những điều này đơn giản hóa các quy trình và giảm công việc lặp đi lặp lại rất nhiều.

Nhưng các nhà phát triển hoặc nhà khai thác vẫn đang tương tác với các máy chủ: các VM được sử dụng làm các node hoạt động trong cluster. Họ vẫn cần thiết lập có bao nhiêu node và tài nguyên của họ (CPU / bộ nhớ).

Virtual Kubelet mô phỏng một node hoạt động thành Kubernetes. Sau đó có thể được sử dụng cho các pod trên, giống như với bất kỳ node bình thường nào khác.

Tại sao sử dụng Kubernetes?

Kubernetes cung cấp các khối xây dựng tuyệt vời và linh hoạt. Được tạo ra để dễ dàng tương tác và người dùng cuối. Điều này làm cho K8s phức tạp và đòi hỏi nhiều công việc lặp đi lặp lại khi sử dụng trực tiếp.

Kubernetes trở thành một tiêu chuẩn độc lập của nhà cung cấp đám mây. Sử dụng các frameworks serverless ở phần trên có ý nghĩa để giữ sự độc lập này khi serverless.

Bằng cách sử dụng serverless trên K8s, chúng ta có thể giảm công việc lặp đi lặp lại với tỷ lệ rất cao. Vì vậy chúng ta có thể dành nhiều thời gian hơn để xây dựng các việc khác hơn.

Tóm tắt

Kết luận

Tôi nghĩ rằng kiến ​​trúc serverless đã chứng minh điều đó. Và sẽ ngày càng trở nên thịnh hành trong những năm tới. Hãy sử dụng trên các tiêu chuẩn mở như K8 để đảm bảo khả năng tương tác cao hơn.

Serverless trên Kubernetes chỉ là kết quả của việc liên tục tự động hóa công việc thủ công.

Xem toàn series Kubernetes :

• Kubernetes Service là gì ? Tự học Kubernetes từ A-Z – phần 1
• Kubernetes Service là gì ? Tự học Kubernetes từ A-Z – phần 2
• Kubernetes Service là gì ? Tự học Kubernetes từ A-Z – phần 3