Kubernetes Cross Cluster Communication

Ngày đăng

Aug 3, 2024 12:39 PM

Tác giả

Quân Huỳnh

Bài này nói về cách giao tiếp giữa các EKS Cluster khác nhau. Một vài câu hỏi quan trọng ở phần này là: làm thế nào để Pod nằm ở EKS này gọi sang Pod nằm ở EKS khác? Ingress và Gateway API? Internal DNS giữa các tài khoản AWS khác nhau? Ta điều hướng truy cập của người dùng từ bên ngoài vào hệ thống của ta thế nào?

Giao tiếp giữa Pod với Pod khác Kubernetes Cluster

Trong Kubernetes để giao tiếp giữa Pod với Pod trong nội bộ một Kubernetes Cluster ta thường dùng Service dạng ClusterIP.

Tiếp đó để bên ngoài có thể gọi được vào Pod ở trong Kubernetes Cluster ta thường dùng Service dạng LoadBalancer hoặc Ingress.

Nên để Pod nằm ở Kubernetes Cluster này gọi sang Pod nằm ở Kubernetes Cluster khác cách đơn giản nhất là ta triển khai Ingress trên từng Cluster. Khi Pod ở Cluster này cần gọi qua Pod nằm ở Cluster khác thì nó gọi vào Ingress và ta cấu hình Ingress để điều hướng truy cập đi vào trong Pod.

Ingress và Gateway API

Ingress là cách phổ biến để quản lý truy cập bên ngoài vào các dịch vụ chạy bên trong Kubernetes Cluster. Tuy nhiên nó có hạn chế là chỉ hỗ trợ các giao thức Layer 7 như HTTP và HTTPS, còn với các giao thức ở tầng khác như TCP và UDP ở Layer 4 thì không. Do đó nếu cần điều hướng truy cập giao thức TCP và UDP thì ta cần dùng Service dạng Network Load Balancer.

EKS từ bản 1.24 trở lên giới thiệu Gateway API hỗ trợ cả giao thức ở Layer 7 (HTTP và HTTPS) và Layer 4 (TCP và UDP). Gateway API gồm GatewayClass, Gateway và HTTPRoute để ta quản lý truy cập vào bên trong Kubernetes giống với Ingress.

Hệ thống Vikki sử dụng Istio để định nghĩa Gateway cho giao tiếp giữa các Kubernetes Cluster thay vì Ingress. Khi ta triển Istio Gateway trên EKS thì nó sẽ được triển khai dưới dạng AWS Network Load Balancer.

Lúc này khi giao tiếp thì Pod sẽ gọi vào NLB và request sẽ được Istio Gateway điều hướng vào Service nhất định.

DNS Mapping

AWS Network Load Balancer (NLB) sử dụng một tên miền mặc định dài và không thân thiện, do đó, việc tạo một tên miền tùy chỉnh và trỏ các bản ghi cho từng NLB là rất cần thiết để dễ dàng quản lý và cấu hình. Đặc biệt, khi làm việc với các NLB giữa các Amazon EKS (Elastic Kubernetes Service), tên miền này phải được cấu hình là private để chỉ có thể phân giải trong mạng nội bộ giữa các VPC (Virtual Private Cloud). Để thực hiện điều này, chúng ta sử dụng DNS Private Hosted Zone.

Ở bài Networking for Multi AWS Accounts ta có đề cập mọi quản lý về mạng nên được triển khai trong tài khoản Network. Do đó, DNS Private Hosted Zone cần được tạo trong tài khoản này. AWS cho phép liên kết một Private Hosted Zone với một VPC và sau đó mở rộng nó tới nhiều VPC khác, giúp đơn giản hóa việc quản lý tên miền cho các dịch vụ nội bộ.

Tổng quan

Để dễ hình dung, dưới đây là ví dụ về cách triển khai Tracing với OpenTelemetry (OTLP) và Elastic APM. Trong kịch bản này, Elastic APM triển khai trên EKS của tài khoản Observability, trong khi OpenTelemetry Collector (OTLP Collector) được triển khai trên EKS của các tài khoản khác nhau. Mục tiêu là gửi dữ liệu tracing từ OTLP Collector đến Elastic APM trong EKS của tài khoản Observability.

Đầu tiên ta định nghĩa route để điều hướng request từ Istio Gateway đi vào Elastic APM trong EKS của tài khoản Observability bằng Istio Virtual Service:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: elastic-apm
spec:
  hosts:
  - elastic-apm.vikki.in
  http:
  - route:
    - destination:
        host: elastic-apm

Tiếp theo trên DNS Hosted Zone ta trỏ tên miền tới NLB.

elastic-apm.vikki.in -> NLB

Lúc này OTLP Collector trong EKS của các tài khoản khác sẽ dùng tên miền elastic-apm.vikki.in để giao tiếp với Elastic APM trong EKS của tài khoản Observability. Và tên miền trên là private nên chỉ có thể được phân giải trong nội bộ VPC. Điều này có nghĩa là bên ngoài VPC sẽ không thể truy cập hoặc phân giải được tên miền này.

Điểm hẹn ngân hàng số Vikki by HDBank

Android: Tải App IOS: Tải App

Loạt bài viết ngắn chia sẻ về kiến trúc hạ tầng của hệ thống ngân hàng trên Cloud (AWS). Đây chỉ là những kiến thức mình học được thông qua sản phẩm NGÂN HÀNG SỐ VIKKI của bên mình, nên kiến trúc có thể phù hợp và không phù hợp với doanh nghiệp của các bạn.

1. AWS Account Management
2. Provisioning Infrastructure for Multi AWS Accounts
3. Networking for Multi AWS Accounts
4. Kubernetes for Multi AWS Accounts: Kubernetes Infrastructure for Scale
5. Kubernetes for Multi AWS Accounts: Kubernetes Cross Cluster Communication
6. Chaos Engineering
7. On-call
8. Core Banking on Cloud
9. Security Consider
10. Log Analytics with Generative AI (PoC)