Posted inDevOps

Debug Microservices Kubernetes với mirrord: Chạy Code Local trong Context Cluster Thực tế

DevOps tutorial - IT technology blog
DevOps tutorial - IT technology blog

Nỗi Ám Ảnh Khi Debug Microservices từ Xa

Bạn vừa đẩy một commit sửa lỗi chỉ vỏn vẹn một dòng lên staging. Tiếp theo là chuỗi 12 phút chờ mòn mỏi để CI build binary, đóng gói Docker image nặng 650 MB và chạy các bước kiểm tra deployment. Khi pod cuối cùng cũng khởi động, service lại lăn ra crash ngay lập tức. Nguyên nhân là do thiếu một secret từ Vault hoặc không phân giải được bản ghi DNS nội bộ. Vòng lặp truyền thống—thêm lệnh print log, commit, chờ CI/CD, theo dõi log pod—đốt cháy hàng tá giờ làm việc của kỹ sư trong mỗi sprint.

Thủ phạm sâu xa ở đây chính là sự sai lệch môi trường (environment drift). Các microservice hiện đại không hề chạy độc lập.

Một backend service điển hình phụ thuộc vào CoreDNS, Istio sidecar, AWS IAM roles cho service accounts (IRSA), các cụm Redis do cloud quản lý và hàng loạt Kubernetes secrets được mount vào pod. Việc cố gắng tái lập toàn bộ mạng lưới hạ tầng phức tạp đó ở môi trường local bằng Docker Compose hoặc Minikube đòi hỏi hàng trăm dòng YAML cồng kềnh và rất nhanh lỗi thời chỉ sau vài tuần. Điều bạn thực sự cần là gắn trực tiếp trình debug của IDE vào luồng traffic thực tế trên cluster—mà không phải deploy code chưa hoàn thiện chỉ để xem nó có chạy được hay không.

Cách Lập Trình Viên Kết Nối Code Local với Kubernetes

Các nhóm kỹ sư thường áp dụng ba chiến lược chính để thu hẹp khoảng cách giữa máy phát triển cá nhân và cụm cluster từ xa.

1. Vòng lặp Build-Push-Deploy

Mỗi thay đổi code đều kích hoạt quy trình build container, push lên registry và cập nhật rolling update. Dù các công cụ tự động hóa như Skaffold hay Tilt có thể rút ngắn thời gian lặp xuống còn 2–3 phút, độ trễ đó vẫn làm đứt gãy trạng thái tập trung sâu. Nhân khoảng thời gian chờ đợi đó với hai mươi lần chỉnh sửa nhỏ trong một buổi chiều xử lý sự cố, bạn sẽ mất hơn một tiếng đồng hồ chỉ để đợi Docker daemon xử lý.

2. Proxy Điều Hướng Traffic (Telepresence & Port-Forwarding)

Sử dụng kubectl port-forward chỉ xử lý được các cuộc gọi outbound đến một pod đơn lẻ, nhưng không thể phân giải các hostname nội bộ trong cluster như order-db.staging.svc.cluster.local, đồng thời các service khác trong cluster cũng không thể gọi ngược về máy của bạn.

Các công cụ proxy hai chiều như Telepresence giải quyết vấn đề này bằng cách tráo đổi deployment từ xa với một pod proxy định tuyến. Tuy nhiên, việc hoán đổi deployment đang chạy sẽ làm thay đổi trạng thái cluster, đòi hỏi quyền cluster-admin mở rộng và thường gây ảnh hưởng đến đồng nghiệp đang chạy kiểm thử QA trên cùng namespace dùng chung đó.

3. Đánh Chặn Syscall Ở Cấp Độ Process (mirrord)

mirrord bỏ qua hoàn toàn bước redeploy container. Thay vì thay thế pod, nó can thiệp trực tiếp vào process ứng dụng ngay trên máy phát triển của bạn thông qua LD_PRELOAD trên Linux hoặc dynamic loader hook trên macOS.

Đồng thời, mirrord khởi chạy một agent pod tạm thời (hoặc ephemeral container) với đặc quyền tối thiểu bên cạnh workload mục tiêu trong cluster. Mỗi khi code local phát sinh network call, yêu cầu biến môi trường hoặc đọc file, mirrord sẽ đánh chặn syscall ngay tại local và chuyển tiếp qua agent trên cluster.

Ưu & Nhược Điểm Của mirrord

Ưu điểm

  • Không làm thay đổi cluster: mirrord triển khai một agent tạm thời chỉ tiêu tốn khoảng 15–30 MB bộ nhớ và biến mất ngay khi bạn dừng debug. Công cụ hoàn toàn không can thiệp vào deployment manifest, service definition hay số lượng replica.
  • Mirror traffic thực tế: Ở chế độ duplicate, mirrord sao chép các gói tin TCP và HTTP gửi đến pod mục tiêu rồi chuyển thẳng về cổng local của bạn. Pod thực tế trên cluster vẫn tiếp tục xử lý traffic staging bình thường mà không bị gián đoạn.
  • Tự động đưa context vào runtime: Biến môi trường, secrets được mount và ConfigMaps tự động được phân giải mà không cần tạo hay duy trì file .env thủ công.
  • Đặt breakpoint không gây nghẽn: Bạn có thể dừng tiến trình chạy trong VS Code, GoLand hoặc IntelliJ suốt 10 phút để soi memory. Pod thật trên cluster vẫn tiếp tục phục vụ các request khác mà không gây lỗi 504 gateway timeout cho các upstream service.
  • Đảm bảo tính ổn định của staging: Nhiều lập trình viên có thể kết nối vào cùng một namespace staging dùng chung đồng thời mà không lo giẫm chân lên nhau hay làm sai lệch dữ liệu cluster.

Nhược điểm

  • Nguy cơ ghi trùng dữ liệu vào database: Khi mirror traffic một cách thụ động, các thao tác ghi dữ liệu sẽ thực thi hai lần—một lần trên pod thật và một lần trên máy local. Bạn cần sử dụng tính năng traffic stealing kết hợp bộ lọc HTTP header đối với các luồng có lưu trạng thái (stateful) để tránh trùng lặp dữ liệu.
  • Đánh chặn syscall trên Go runtime: Các chương trình Go bỏ qua thư viện C runtime tiêu chuẩn (libc) và gọi trực tiếp kernel syscall. Để đánh chặn, mirrord phải patch trực tiếp instruction trên bộ nhớ hoặc sử dụng ptrace, gây ra độ trễ nhỏ trong các tác vụ I/O cường độ cao.
  • Rào cản về phân quyền RBAC: Lập trình viên vẫn cần có quyền Kubernetes để tạo ephemeral container hoặc khởi tạo job/pod trong namespace mục tiêu.

Cấu Hình Khuyến Nghị: Selective Traffic Stealing (Chiếm Dụng Traffic Có Chọn Lọc)

Trên các cluster staging dùng chung, bạn nên cấu hình mirrord để chỉ chuyển tiếp các request debug có chủ đích, trong khi vẫn giữ nguyên các luồng traffic thông thường. Kết hợp thiết lập này với quyền truy cập filesystem từ xa ở chế độ chỉ đọc (read-only) để ứng dụng local có thể đọc cấu hình thực tế mà không vô tình sửa đổi bộ nhớ dùng chung.

Cấu hình này mang lại bốn lớp bảo vệ cốt lõi:

  • Process local chỉ đánh chặn các request có gắn HTTP header tùy chỉnh (ví dụ: x-debug-session: true).
  • Traffic kiểm thử định kỳ từ CI pipeline và đội ngũ QA vẫn gửi đến pod thật bình thường.
  • Secrets và file cấu hình được đọc trực tiếp từ volume mount của pod từ xa trong thời gian chạy.
  • Dữ liệu ghi vào database chỉ thực hiện một lần duy nhất, nằm an toàn trong phiên debug riêng biệt của bạn.

Lưu cấu hình sau vào file .mirrord/mirrord.json tại thư mục gốc của dự án:

{
  "$schema": "https://raw.githubusercontent.com/metalbear-co/mirrord/main/mirrord-schema.json",
  "target": {
    "path": {
      "deployment": "payment-service"
    },
    "namespace": "staging"
  },
  "feature": {
    "network": {
      "incoming": {
        "mode": "steal",
        "http_filter": {
          "header_filter": "x-debug-session: true"
        }
      },
      "outgoing": true,
      "dns": true
    },
    "fs": {
      "mode": "read"
    },
    "env": true
  }
}

Hướng Dẫn Triển Khai: Từng Bước Debug Service

Bước 1: Cài đặt mirrord CLI

Cài đặt binary trên máy phát triển bằng script cài đặt chính thức hoặc trình quản lý package:

# Script cài đặt cho Linux và macOS
curl -fsSL https://inputs.metalbear.co/mirrord/install.sh | bash

# Hoặc qua Homebrew trên macOS
brew install metalbear-co/mirrord/mirrord

Kiểm tra xem binary đã hoạt động ổn định và xác nhận phiên bản vừa cài đặt:

mirrord --version

Bước 2: Xác Thực với Kubernetes Context

mirrord sử dụng thông tin xác thực đang kích hoạt trong ~/.kube/config. Hãy kiểm tra context của cluster mục tiêu và xác nhận pod cần debug đang ở trạng thái healthy:

kubectl config current-context
kubectl get pods -n staging -l app=payment-service

Bước 3: Chạy Process Local Trong Context Của Cluster

Khởi chạy code local thông qua mirrord thay vì đóng gói container image. mirrord sẽ gắn vào process local, khởi động cluster agent và tự động thiết lập chuyển hướng I/O:

# Chạy service Python FastAPI tại local
mirrord exec --config-file .mirrord/mirrord.json -- uvicorn app:app --port 8080

# Hoặc chạy microservice Node.js
mirrord exec --config-file .mirrord/mirrord.json -- npm run dev

Trong quá trình khởi động, CLI sẽ hiển thị xác nhận các thông số kết nối:

mirrord: đã kết nối tới deployment mục tiêu payment-service trong namespace staging
mirrord: đã sẵn sàng mirror network traffic và chuyển tiếp biến môi trường
[Local Server] Đang chạy tại http://localhost:8080

Bước 4: Kiểm Tra Biến Môi Trường và Phân Giải Tên Miền Cluster

Kiểm tra xem process local có thể truy cập tài nguyên nội bộ Kubernetes mà không cần thiết lập bất kỳ tunnel port-forwarding thủ công nào:

import os
import requests

# Hostname được phân giải trực tiếp qua CoreDNS của Kubernetes
DB_HOST = os.getenv("DATABASE_HOST", "postgres.internal.svc.cluster.local")
API_KEY = os.getenv("PAYMENT_GATEWAY_SECRET")

def check_status():
    print(f"Database host từ biến môi trường của pod: {DB_HOST}")
    print(f"Secret được đưa vào từ cluster: {API_KEY[:4]}****")
    
    # Request gửi ra ngoài xuất phát từ cluster agent pod, kế thừa toàn bộ security group và network policy của pod đó
    resp = requests.get("http://auth-service.staging.svc.cluster.local/health", timeout=5)
    print(f"Trạng thái health của auth service: {resp.status_code}")

if __name__ == "__main__":
    check_status()

Bước 5: Kiểm Thử với Traffic Có Bộ Lọc

Gửi hai lệnh curl khác nhau đến endpoint ingress của môi trường staging để kiểm tra bộ lọc header:

# 1. Request thông thường: đi thẳng đến pod Kubernetes từ xa
curl -X POST https://staging.example.com/api/v1/payments \
  -H "Content-Type: application/json" \
  -d '{"amount": 49.99}'

# 2. Request debug: bị chiếm dụng và điều hướng thẳng về debugger local
curl -X POST https://staging.example.com/api/v1/payments \
  -H "Content-Type: application/json" \
  -H "x-debug-session: true" \
  -d '{"amount": 49.99}'

Trình debugger ở local sẽ bắt ngay request thứ hai. Bạn có thể step qua từng dòng code, kiểm tra memory và xác thực bản sửa lỗi với các service thực tế chỉ trong vài giây—hoàn toàn không cần build lại Docker image, push image hay restart pod.

Share:
Tags: