Posted inFedora

Quản lý Auto-update Fedora CoreOS: Đừng để Cluster “dắt tay nhau” Reboot

Fedora tutorial - IT technology blog
Fedora tutorial - IT technology blog

Khi tính năng tự động hóa “phản chủ”

Dùng Fedora làm máy dev thì rất sướng vì package luôn mới nhất. Thế nhưng, khi mình mang Fedora CoreOS (FCOS) lên production, triết lý “tự động hoàn toàn” của nó lại gây ra một rắc rối dở khóc dở cười. FCOS mặc định sẽ tự tải bản vá, tự cài đặt và tự khởi động lại để áp dụng kernel mới.

Hãy tưởng tượng bạn vận hành cụm Web Server gồm 3 node. Đúng 3 giờ sáng, cả 3 node cùng thấy có bản update. Chúng đồng loạt tải về và đồng loạt… reboot. Kết quả là toàn bộ dịch vụ sập hoàn toàn trong khoảng 3-5 phút chỉ vì hệ thống quá “chăm chỉ”. Với các hệ thống nhạy cảm như Etcd, việc mất cùng lúc 2/3 node sẽ gây mất quorum và làm tê liệt cả cluster.

Tại sao Zincati mặc định là chưa đủ?

Trong hệ sinh thái FCOS, Zincati là agent chịu trách nhiệm check bản phát hành mới và điều phối rpm-ostree. Vấn đề là Zincati hoạt động rất độc lập. Nó không quan tâm các node lân cận đang sống hay chết.

Cơ chế “Atomic Update” buộc máy chủ phải khởi động lại để kích hoạt deployment mới. Nếu giữ cấu hình mặc định, bạn sẽ gặp 3 rủi ro lớn:

  • Cả cluster reboot cùng lúc gây gián đoạn dịch vụ (downtime).
  • Không có thứ tự ưu tiên node dự phòng.
  • Dễ gây hỏng trạng thái của các ứng dụng phân tán (như Kubernetes hay Database cluster).

Giải pháp: Điều phối reboot bằng FleetLock

Để kiểm soát tình hình, chúng ta cần một cơ chế “xin phép” trước khi reboot. FleetLock đóng vai trò như một người gác cổng. Trước khi khởi động lại, Zincati phải gửi yêu cầu lấy “khóa” (lock). Nếu máy chủ FleetLock đồng ý, node đó mới được đi tiếp. Ngược lại, nó phải xếp hàng chờ đến lượt.

Bước 1: Dựng FleetLock Server

Bạn cần một service nhỏ để quản lý trạng thái khóa. Cách nhanh nhất là chạy fleetlock-server dưới dạng container. Bạn có thể đặt nó trên một máy quản lý riêng hoặc chạy ngay trong cluster nếu có cơ chế chịu lỗi cao.

# Chạy FleetLock server bằng Podman
podman run -d --name fleetlock-server \
  -p 8080:8080 \
  -v ./fleetlock.toml:/config/fleetlock.toml:Z \
  quay.io/coreos/fleetlock-server:latest

Trong file fleetlock.toml, hãy giới hạn số lượng node được phép reboot cùng lúc. Thông thường, chúng ta chỉ cho phép 1 node (slots = 1) để đảm bảo an toàn:

[groups.production]
slots = 1

Bước 2: Cấu hình Zincati trên các node FCOS

Chúng ta cần yêu cầu Zincati trên từng node ngưng việc tự ý reboot. Thay vào đó, nó phải hỏi ý kiến FleetLock server. Bạn nên cấu hình việc này thông qua file Butane trước khi khởi tạo node.

Đây là đoạn cấu hình mình thường dùng để trỏ về FleetLock:

variant: fcos
version: 1.4.0
storage:
  files:
    - path: /etc/zincati/config.d/50-fleetlock.toml
      contents:
        inline: |
          [updates]
          strategy = "fleetlock"
          [updates.fleetlock]
          base_url = "http://192.168.1.100:8080/"
          group = "production"

Lưu ý quan trọng:

  • strategy = "fleetlock": Chỉ định Zincati dùng giao thức FleetLock thay vì reboot tự do.
  • base_url: Địa chỉ IP của máy chủ FleetLock bạn vừa dựng.
  • group: Tên nhóm máy chủ để quản lý khóa riêng biệt (ví dụ: staging, production).

Bước 3: Kiểm tra vận hành

Sau khi áp dụng cấu hình, bạn có thể kiểm tra trạng thái agent bằng lệnh:

systemctl status zincati

Khi có bản cập nhật, log của Zincati sẽ hiển thị trạng thái “Waiting for lock”. Node đầu tiên lấy được lock sẽ reboot. Sau khi nó online trở lại, lock được giải phóng và node tiếp theo mới bắt đầu quy trình. Cluster của bạn sẽ luôn có ít nhất 2 node hoạt động (với cụm 3 node).

Kinh nghiệm thực tế từ hiện trường

Qua quá trình vận hành thực tế, mình rút ra 3 lưu ý để hệ thống ổn định hơn:

  1. Thiết lập Maintenance Window: Dù đã có FleetLock, bạn vẫn nên giới hạn thời gian cập nhật vào giờ thấp điểm (ví dụ 2h – 4h sáng) bằng cấu hình updates.periodic.window.
  2. Giám sát qua Prometheus: Hãy theo dõi metric zincati_pushed_updates_total để biết node nào đang bị kẹt hoặc đang đợi cập nhật quá lâu.
  3. Tính sẵn sàng của FleetLock: Nếu FleetLock server bị sập, Zincati sẽ chọn giải pháp an toàn là… không làm gì cả. Điều này giúp tránh reboot đồng loạt nhưng sẽ khiến server bị chậm cập nhật bản vá bảo mật.

Kết hợp Zincati và FleetLock giúp biến Fedora CoreOS thành một hạ tầng có kỷ luật. Thay vì lo lắng mỗi khi có bản vá mới, giờ đây mình có thể yên tâm để hệ thống tự sửa lỗi mà không sợ bị gọi dậy lúc nửa đêm vì sập dịch vụ.

Share:
Tags: