Quản lý cấu hình với ConfigMap và Secret: Tính năng cập nhật nóng không đồng nghĩa với việc thay đổi tùy tiện

Kubernetes giúp quản lý cấu hình trở nên dễ dàng hơn, khi ConfigMap và Secret được cập nhật, dịch vụ có thể đọc lại cấu hình mới. Tuy nhiên, sự thuận tiện không có nghĩa là có thể thay đổi một cách tùy tiện. Trong hệ thống AI backend, các thông số như định tuyến mô hình, mẫu Prompt, ngưỡng an toàn, chiến lược giới hạn đều có thể được lưu trữ trong cấu hình, nếu thay đổi sai sót sẽ ảnh hưởng trực tiếp đến hành vi của hệ thống đang chạy.

Cấu hình cũng cần được xem như một bản phát hành. Nó cần có phiên bản, kiểm tra, quay lại và theo dõi. Đừng vì nó không phải là mã nguồn mà bỏ qua kỷ luật kỹ thuật.

Một, phân loại cấu hình

Cấu hình có thể chia thành cấu hình thông thường, cấu hình nhạy cảm, chính sách cấu hình và cấu hình thử nghiệm. Mỗi loại có rủi ro khác nhau khi thay đổi.

flowchart TD
  A[Chuẩn bị] --> B[Chuẩn bị thông thường]
  A --> C[Chuẩn bị nhạy cảm Secret]
  A --> D[Chuẩn bị chính sách]
  A --> E[Chuẩn bị thử nghiệm]
  D --> F[Đòi hỏi kiểm tra và triển khai từng bước]
  C --> G[Đòi hỏi mã hóa và thay thế định kỳ]

Ngưỡng an toàn mô hình, mức độ giới hạn, tỷ lệ định tuyến thuộc loại cấu hình chính sách, không thể thay đổi tùy tiện như thay đổi cấp độ ghi log.

Hai, cấu hình cần có kiểm tra

Khi khởi động dịch vụ hoặc tải lại cấu hình, cần kiểm tra định dạng và phạm vi của cấu hình. Nếu cấu hình sai, hãy từ chối tải, đừng để hệ thống chạy trong trạng thái không xác định.

type Policy struct {
    Delay int `yaml:"delay"`
    MaxNum int `yaml:"max_num"`
}

func (p Policy) Check() error {
    if p.Delay < 100 || p.Delay > 12000 {
        return fmt.Errorf("delay out of range")
    }
    if p.MaxNum <= 0 || p.MaxNum > 8192 {
        return fmt.Errorf("max_num out of range")
    }
    return nil
}

Kiểm tra cấu hình là phanh cho cơ sở hạ tầng. Không có phanh, việc cập nhật nóng chỉ là nhanh hơn đưa lỗi vào môi trường thực tế.

Ba, Secret cần kế hoạch xoay vòng

Mã truy cập mô hình, mật khẩu cơ sở dữ liệu, khóa Webhook nên được lưu trữ trong Secret và có kế hoạch xoay vòng. Trong giai đoạn xoay vòng, dịch vụ cần hỗ trợ cả khóa cũ và mới trong thời gian ngắn, tránh ngắt kết nối đột ngột.

secret_rotation:
  phase_1: insert_new_key
  phase_2: update_services_to_support_both
  phase_3: change_outbound_to_use_new
  phase_4: remove_old_key

Secret không nên xuất hiện trong nhật ký, thông báo lỗi hay biến môi trường phía trước. Yêu cầu này rất cơ bản nhưng vẫn thường xảy ra trong các sự cố.

Bốn, thay đổi cấu hình cần truy nguyên

Ai đã thay đổi cấu hình, tại sao thay đổi, phạm vi ảnh hưởng là gì, thời điểm nào có thể quay lại, những điều này cần được ghi lại. GitOps là phương pháp tốt: cấu hình đưa vào kho, đi qua PR, tự động đồng bộ.

Sau khi thay đổi cấu hình, cần theo dõi các chỉ số quan trọng. Ví dụ, sau khi giảm ngưỡng giới hạn, tỷ lệ từ chối có tăng lên không; sau khi điều chỉnh định tuyến mô hình, chi phí và độ trễ có thay đổi không?

Cấu hình cũng cần phân theo môi trường. Môi trường phát triển, kiểm thử và sản xuất có thể chia sẻ cấu trúc nhưng không chia sẻ giá trị. Đặc biệt là khóa mô hình, địa chỉ gọi lại, mức độ giới hạn và công tắc thử nghiệm, việc tách biệt môi trường có thể ngăn chặn nhiều lỗi do thao tác sai.

configurations:
  dev:
    delay_time: 30000
    limit_per_minute: 20
  prod:
    delay_time: 15000
    limit_per_minute: 1000

Cuối cùng, cập nhật nóng cần có khả năng quay lại. Sau khi tải cấu hình mới, nếu tỷ lệ lỗi tăng, hệ thống cần có thể nhanh chóng quay về phiên bản trước. Việc lưu trữ phiên bản lịch sử trong trung tâm cấu hình đáng tin cậy hơn việc tìm kiếm giá trị cũ trong nhóm chat.

Năm, tổng kết

ConfigMap và Secret giúp quản lý cấu hình dễ dàng hơn, nhưng cấu hình vẫn là một phần của quá trình phát hành. Phân loại loại cấu hình, kiểm tra định dạng, lập kế hoạch xoay vòng cho Secret, ghi lại thay đổi và có khả năng quay lại.

Khả năng cập nhật nóng là năng lực, nhưng biết được những cấu hình nào không thể thay đổi tùy tiện là phán đoán kỹ thuật.