Kubernetes Resilience: Củng cố độ bền bỉ cho Cluster với Chaos Mesh

Table of Contents

Cuộc gọi đánh thức lúc 2 giờ sáng mà lẽ ra bạn có thể tránh được

Điện thoại của bạn rung bần bật trên tủ đầu giường lúc 2 giờ sáng. PagerDuty đang gào thét về một sự cố dịch vụ nghiêm trọng. Bạn đăng nhập với đôi mắt ngái ngủ và nhận ra một mớ hỗn độn: một pod bị crash, kích hoạt một cơn bão thử lại (retry storm) làm sập cơ sở dữ liệu và khiến ingress controller bị ngoại tuyến. Toàn bộ hệ thống tê liệt.

Hầu hết chúng ta đều đã trải qua cơn ác mộng này. Chúng ta giả định hệ thống của mình có khả năng phục hồi vì có các bản sao (replicas) và kiểm tra sức khỏe (health checks), nhưng môi trường production luôn có cách để lộ ra những trường hợp biên (edge cases) mà chúng ta bỏ lỡ. Đây chính là lúc Chaos Engineering (Kỹ thuật hỗn loạn) phát huy tác dụng. Thay vì chờ đợi thảm họa ập đến vào giữa đêm, chúng ta chủ động kích hoạt nó vào lúc 2 giờ chiều trong điều kiện có kiểm soát. Theo kinh nghiệm của tôi, Chaos Mesh là công cụ chính xác nhất cho công việc này.

Khởi động nhanh: Phá vỡ Pod đầu tiên của bạn trong 300 giây

Chaos Mesh là một nền tảng cloud-native giúp điều phối các lỗi trực tiếp trên Kubernetes. Nó sử dụng Custom Resource Definitions (CRDs) để định nghĩa các lỗi dễ dàng như khi bạn định nghĩa một Deployment. Hãy cùng cài đặt và thực hiện thử nghiệm đầu tiên.

1. Cài đặt Chaos Mesh

Cách nhanh nhất để cài đặt là thông qua Helm. Tôi giả định rằng bạn đã có sẵn một cluster và đã cấu hình kubectl.

helm repo add chaos-mesh https://charts.chaos-mesh.org
kubectl create ns chaos-mesh
helm install chaos-mesh chaos-mesh/chaos-mesh -n chaos-mesh --set dashboard.create=true

Kiểm tra tiến độ bằng lệnh kubectl get po -n chaos-mesh. Khi các pod đã chạy, bạn đã sẵn sàng để thử phá vỡ mọi thứ.

2. Định nghĩa một thử nghiệm lỗi Pod (Pod Failure)

Hãy mô phỏng một tình huống đau đầu phổ biến: một pod ngẫu nhiên trong namespace production đột ngột bị chết. Tạo một tệp có tên pod-kill.yaml:

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-failure-example
  namespace: default
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces:
      - app-production
    labelSelectors:
      "app": "web-server"
  scheduler:
    cron: "@every 1m"

3. Chạy thử nghiệm

Áp dụng cấu hình để bắt đầu quá trình hỗn loạn:

kubectl apply -f pod-kill.yaml

Trong vòng 60 giây, Chaos Mesh sẽ chấm dứt một pod có nhãn web-server. Bây giờ, hãy theo dõi hệ thống giám sát của bạn. LoadBalancer của bạn có xử lý các lỗi 502 một cách mượt mà không? Kubernetes có khởi tạo bản thay thế đủ nhanh để duy trì SLA không? Nếu người dùng nhận thấy sự chậm trễ, bạn vừa tìm thấy một điểm yếu trước khi nó trở thành một tình trạng khẩn cấp thực sự.

Cơ chế của sự hỗn loạn

Chaos Mesh không chỉ đơn thuần là giết chết các tiến trình. Nó tận dụng nhân Linux để mô phỏng các lỗi phức tạp. Kiến trúc của nó dựa trên ba thành phần quan trọng:

Chaos Dashboard: Một trung tâm điều khiển trực quan để quản lý các thử nghiệm mà không cần chạm vào YAML.
Chaos Controller Manager: Bộ não điều phối và quản lý vòng đời của các đối tượng chaos.
Chaos Daemon: Một daemonset có đặc quyền chạy trên mọi node. Nó sử dụng eBPF và cgroups để can thiệp vào ngăn xếp mạng và hệ thống tệp.

Thiết kế này cho phép bạn tiêm các lỗi gần như không thể mô phỏng thủ công, chẳng hạn như lệch đồng hồ (clock skew) hoặc lỗi nhân (kernel panics). Khác với các script thủ công, Chaos Mesh có khả năng tự phục hồi. Nếu một thử nghiệm kết thúc hoặc bạn xóa CRD, hệ thống sẽ ngay lập tức quay trở lại trạng thái ban đầu. Không có quy tắc iptables dư thừa hay cấu hình hỏng hóc nào bị để lại.

Các loại lỗi cốt lõi

PodChaos: Mô phỏng việc crash pod/container hoặc các trạng thái “Pending”.
NetworkChaos: Tiêm trễ mạng, mất gói tin hoặc lỗi dữ liệu. Đây là thủ phạm chính gây ra hiện tượng “vòng xoáy tử thần” (death spirals) trong microservices.
IOChaos: Mô phỏng hiệu suất đĩa chậm hoặc lỗi hệ thống tệp.
StressChaos: Đẩy CPU hoặc bộ nhớ lên mức tối đa để kiểm tra khả năng phản ứng của Horizontal Pod Autoscaler (HPA).

Sử dụng nâng cao: Mô phỏng Microservice chập chờn

Việc giết một pod chỉ là bài kiểm tra cơ bản. Giá trị thực sự nằm ở việc mô phỏng một mạng lưới bị suy giảm giữa hai dịch vụ cụ thể. Hãy tưởng tượng Dịch vụ A gọi Dịch vụ B. Bạn cần biết điều gì sẽ xảy ra nếu kết nối đột ngột bị trễ 200ms.

Tiêm trễ mạng (Network Latency)

Tạo tệp network-latency.yaml:

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: network-latency-test
spec:
  action: delay
  mode: all
  selector:
    namespaces:
      - app-production
    labelSelectors:
      "app": "service-a"
  delay:
    latency: "200ms"
    jitter: "50ms"
  direction: to
  target:
    selector:
      labelSelectors:
        "app": "service-b"
    namespaces:
      - app-production

Thử nghiệm này chỉ nhắm mục tiêu vào lưu lượng truy cập đi từ Dịch vụ A đến Dịch vụ B. Nó không làm ảnh hưởng đến phần còn lại của cluster. Độ chính xác này rất quan trọng để kiểm tra logic ngắt mạch (circuit breaker) và thời gian chờ (timeout) mà không làm sập toàn bộ môi trường staging của bạn.

Những bài học xương máu từ thực tế

Chạy các thử nghiệm hỗn loạn có thể nguy hiểm nếu bạn thực hiện một cách mù quáng. Đây là những quy tắc tôi tuân thủ để giữ cho mọi thứ hiệu quả:

1. Thiết lập trạng thái cơ sở (Baseline)

Bạn không thể đo lường những gì bạn không giám sát. Trước khi phá vỡ bất cứ điều gì, hãy đảm bảo bảng điều khiển Grafana hiển thị “trạng thái ổn định” của bạn — tỷ lệ lỗi bình thường và độ trễ p99. Nếu bạn chưa có khả năng quan sát (observability), hãy dừng lại ở đây và xây dựng nó trước.

2. Kiểm soát phạm vi ảnh hưởng (Blast Radius)

Đừng bao giờ chạy thử nghiệm đầu tiên trên toàn bộ cluster production. Hãy bắt đầu trong một namespace QA riêng biệt. Khi đã tự tin, hãy chuyển sang môi trường staging mô phỏng lưu lượng truy cập thực tế. Chỉ sau đó bạn mới nên cân nhắc các buổi diễn tập “Game Days” trên môi trường live.

3. Tự động hóa Chaos

Độ bền bỉ không phải là việc kiểm tra một lần là xong. Khi bạn triển khai mã mới, các lỗ hổng mới sẽ xuất hiện. Hãy tích hợp Chaos Mesh vào pipeline CI/CD của bạn. Ví dụ: chạy thử nghiệm PodKill mỗi khi bạn deploy lên môi trường integration. Nếu các bài test thất bại, mã đó chưa sẵn sàng cho thế giới thực.

4. Luôn sẵn sàng nút dừng khẩn cấp (Kill Switch)

Chaos Mesh rất giỏi trong việc dọn dẹp, nhưng bạn nên luôn có kế hoạch hủy bỏ thủ công. Việc xóa đối tượng YAML sẽ dừng lỗi ngay lập tức:

kubectl delete -f pod-kill.yaml

Tổng kết

Độ tin cậy không phải là một tính năng bạn xây dựng; đó là một thói quen bạn duy trì. Bằng cách sử dụng Chaos Mesh để chủ động săn tìm các điểm yếu, bạn đã chuyển gánh nặng phát hiện lỗi từ khách hàng sang đội ngũ của mình. Sửa một lỗi timeout vào chiều thứ Ba sẽ tốt hơn nhiều so với việc bị đánh thức bởi nó vào sáng Chủ nhật. Hãy bắt đầu thử nghiệm ngay hôm nay — giấc ngủ của bạn sẽ cảm ơn bạn vì điều đó.