Kubernetes Structural Patterns: Adapter và Ambassador Container

Ngày đăng

Jul 4, 2023 8:00 AM

Tác giả

Quân Huỳnh

Giới thiệu

Trong bài này chúng ta sẽ tìm hiểu về Adapter Pattern và Ambassador Pattern, đây là một dạng Pattern mở rộng của Sidecar.

Mục lục

Adapter
Ambassador
Kết luận
Bài viết liên quan

Structural Patterns sẽ bao gồm:

Init Container
Sidecar
Adapter
Ambassador

Adapter

Adapter Pattern ra đời để giải quyết vấn đề không đồng nhất của các ứng dụng, mục đích của Pattern này là cung cấp cho các ứng dụng của ta một Adapter đồng nhất. Để các ứng dụng khác có thể dễ dàng truy cập được các ứng dụng đằng sau Adapter.

Vấn đề

Vấn đề mà ta hay gặp nhất khi ta phát triển hệ thống Microservice là ban đầu ta sẽ phát triển ứng dụng bằng một ngôn ngữ. Và khi hệ thống của ta cần mở rộng ta sẽ phát hiện ngôn ngữ mà ta đang xài có thể không thích hợp cho Service mới và có một ngôn ngữ khác phù hợp hơn. Do đó ta chọn phát triển Service mới với ngôn ngữ khác.

Từ từ hệ thống của ta cứ mở rộng ra, lúc này hệ thống của ta sẽ có rất nhiều Service với các ngôn ngữ khác nhau. Vấn đề ở đây là các ngôn ngữ khác nhau sẽ có cách truy cập với tương tác khác nhau, điều này dẫn tới các Service của ta không đồng nhất và rất khó để truy cập.

Ví dụ nếu ta cần giám sát các Service nhưng Metric của từng Service tạo ra lại khác nhau thì khiến các công cụ giám sát rất khó để thu thập dữ liệu.

Giải pháp

Để giải quyết vấn đề trên thì ta có thể sử dụng Adapter. Nó sẽ cung cấp một Interface thống nhất để các ứng dụng bên ngoài có thể dễ dàng truy cập được các ứng dụng đằng sau Adapter. Ta không cần biết các ứng dụng đằng sau Adapter nó có các cách truy cập khác nhau như thế nào, ta chỉ cần biết là ta có thể truy cập được các ứng dụng đó thông qua Adapter với một cách thống nhất.

Quay lại với bài toán giám sát, ta sẽ cần một Adapter để chuyển các Metric khác nhau thành một định dạng thống nhất để công cụ giám sát có thể thu thập được. Ta sử dụng Adapter Container cho bài toán này.

Ví dụ

Ta có một Container chạy HTTP Server đơn giản, với mỗi Request của người dùng thì Container trên sẽ ghi log vào tệp tin logs của nó. Một Container khác sẽ có nhiệm vụ là đọc log từ tệp tin logs của HTTP Server và chuyển nó thành dạng Metric mà Prometheus có thể đọc được. Lúc này HTTP Server không cần quan tâm tới việc Metric của nó sẽ được đọc từ Prometheus hay bất kì công cụ giám sát nào khác.

Tạo một tệp tin với tên là adapter.yaml.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: random-generator
spec:
  replicas: 1
  selector:
    matchLabels:
      app: random-generator
  template:
    metadata:
      labels:
        app: random-generator
    spec:
      containers:
        - image: k8spatterns/random-generator:1.0
          name: random-generator
          env:
            - name: LOG_FILE
              value: /logs/random.log
          ports:
            - containerPort: 8080
              protocol: TCP
          volumeMounts:
            - mountPath: /logs
              name: log-volume
        - image: k8spatterns/random-generator-exporter
          name: prometheus-adapter
          env:
            - name: LOG_FILE
              value: /logs/random.log
          ports:
            - containerPort: 9889
              protocol: TCP
          volumeMounts:
            - mountPath: /logs
              name: log-volume
      volumes:
        - name: log-volume
          emptyDir: {}

Ở tệp tin cấu hình trên ta tạo một EmptyDir Volume tên là log-volume và gắn nó vào bên trong cả hai Container ở thư mục logs. HTTP Server ghi log vào tệp tin /logs/random.log và prometheus-adapter đọc log này sau đó chuyển nó thành định dạng mà Prometheus đọc được.

Adapter Container là một Reverse Proxy cho các ứng dụng bên ngoài có thể truy cập được các ứng dụng đằng sau nó một cách dễ dàng.

Ambassador

Ambassador Pattern là Pattern ngược lại so với Adapter. Ambassador có mục đích là cung cấp cho ta một Interface thống nhất để các ứng dụng đằng sau Ambassador có thể dễ dàng truy cập được các ứng dụng bên ngoài.

Vấn đề

Vấn đề mà ta hay gặp là khi ta cần truy cập các ứng dụng mà nó có các cách truy cập khác nhau. Thông thường ta phải viết các đoạn code khác nhau để truy cập được các ứng dụng khác nhau.

Ví dụ hệ thống ta sử dụng cả Memcached và Redis để dùng làm Cache. Với Memcached khi truy cập ta không cần phải thực hiện bước Authentication nhưng Redis thì có.

Giải pháp

Thay vì phải viết code để kết nối với các ứng dụng khác nhau thì nên để việc đó cho một Container khác. Sau đó bên trong ứng dụng chỉ cần kết nối tới Container này thông qua một Interface duy nhất. Còn công việc kết nối với các ứng dụng khác nhau như thế nào thì để Container đó xử lý. Container này được gọi là Ambassador Container.

Ví dụ

Ví dụ ta có ứng dụng cần truy cập cả Memcached và Redis. Ta xây dựng một Ambassador Container và để công việc kết tới Memcached và Redis cho nó thực hiện. Sau đó ứng dụng của ta chỉ cần kết nối tới Ambassador bằng URL localhost:8080.