Tạm biệt “cơn đau đầu” Kubernetes: Hướng dẫn thực hành HashiCorp Nomad

Cuộc gọi lúc 2 giờ sáng: Liệu Kubernetes có đáng để bạn bị stress?

Đó là lúc 2 giờ sáng ngày thứ Ba khi thông báo PagerDuty bắt đầu kêu inh ỏi. Cụm microservice của chúng tôi, được quản lý bởi một nhà cung cấp Kubernetes danh tiếng, đã gặp sự cố. Trạng thái etcd bị trễ, ingress controller liên tục báo lỗi 504, và tôi thì ngập trong 400 dòng YAML chỉ để tìm hiểu tại sao một pod Nginx đơn giản lại không thể khởi chạy. Trong khoảnh khắc đầy caffeine đó, tôi nhận ra chúng tôi đang trả cái giá quá đắt cho những tính năng mà chúng tôi thực sự chẳng bao giờ dùng đến.

Kubernetes là một “gã khổng lồ” cho quy mô cực lớn. Tuy nhiên, với nhiều đội ngũ, nó giống như việc lái một chiếc xe tải đầu kéo chỉ để đi mua một chiếc pizza. Đó là lý do tại sao tôi bắt đầu chuyển các workload của mình sang HashiCorp Nomad.

Khác với K8s, Nomad chỉ là một file binary duy nhất nặng 75MB. Nó xử lý container, raw binary và Java JAR một cách dễ dàng như nhau. Bạn không cần một bằng cấp chuyên sâu về cloud-native networking để điều phối lưu lượng. Nếu bạn đã kiệt sức vì việc bảo trì control plane của K8s, Nomad chính là giải pháp thay thế tinh gọn mà bạn đang tìm kiếm.

Tại sao Nomad phù hợp với hạ tầng quy mô vừa

Nomad tuân theo triết lý Unix kinh điển: làm một việc và làm thật tốt. Nó tập trung hoàn toàn vào việc lập lịch (scheduling). Nó không cố gắng trở thành database, service mesh hay nhà cung cấp cloud của bạn cùng một lúc. Trong khi một node Kubernetes điển hình có thể ngốn tới 2GB RAM chỉ để chạy không tải, một Nomad client thường chỉ tiêu tốn dưới 100MB.

Trước khi khởi tạo một cluster, tôi luôn lập bản đồ kiến trúc mạng của mình. Tôi thường sử dụng Subnet Calculator này để xác định các khối CIDR cho Nomad client. Đây là một công cụ tiện lợi vì nó chạy cục bộ ngay trên trình duyệt. Điều này có nghĩa là cấu trúc mạng nội bộ của bạn không bao giờ chạm tới máy chủ từ xa, giúp giữ kín các chi tiết hạ tầng.

Cài đặt: Từ con số không đến một Cluster hoàn chỉnh trong chưa đầy 5 phút

Vì Nomad được viết bằng Go, việc triển khai cực kỳ nhanh chóng. Bạn có thể tải file binary về và chạy ngay lập tức. Tuy nhiên, đối với môi trường production, sử dụng repository chính thức của HashiCorp là lựa chọn thông minh hơn. Dưới đây là cách thiết lập trên Ubuntu.

# Thêm HashiCorp GPG key
wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg

# Thêm repository
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list

# Cài đặt Nomad
sudo apt update && sudo apt install nomad

Kiểm tra lại kết quả bằng lệnh:

nomad version

Cấu hình Server và Client

Nomad hoạt động ở hai chế độ. **Server** đưa ra các quyết định lập lịch điều hành. **Client** là những “người thợ” thực sự thực thi các tác vụ. Mặc dù bạn có thể chạy cả hai trên một instance t3.micro duy nhất để thử nghiệm, bạn nên tách riêng chúng trên production để đảm bảo tính ổn định.

Cấu hình Nomad sử dụng HCL (HashiCorp Configuration Language). Nó dễ nhìn hơn nhiều so với JSON. Nếu bạn đang chuyển đổi các cấu hình cũ, Công cụ chuyển đổi YAML ↔ JSON này sẽ giúp kiểm tra nhanh chóng mà không lo rò rỉ dữ liệu sang máy chủ bên thứ ba.

Mở file /etc/nomad.d/nomad.hcl và dán cấu hình cơ bản này vào:

datacenter = "dc1"
data_dir   = "/opt/nomad/data"

server {
  enabled          = true
  bootstrap_expect = 1 # Đặt thành 3 hoặc 5 để có tính sẵn sàng cao (high availability)
}

client {
  enabled = true
  servers = ["127.0.0.1"]
}

ui {
  enabled = true
}

Khởi chạy dịch vụ với systemd:

sudo systemctl enable nomad
sudo systemctl start nomad
sudo systemctl status nomad

Triển khai Job đầu tiên của bạn

Trong thế giới của Nomad, bạn không làm việc với Pod. Bạn viết các **Job**. Một Job chứa các **Group**, và Group chứa các **Task**. Cấu trúc này giúp xác định rõ ràng dịch vụ nào đang chạy cùng nhau trên cùng một host.

Hãy tạo file webapp.nomad để triển khai Nginx. Trước khi đẩy bất kỳ image nào lên production, tôi luôn xác minh mã hash của artifact. Sử dụng Trình tạo Hash cho phép bạn kiểm tra kỹ xem file binary bạn đã tải xuống có khớp chính xác với mã checksum của nhà cung cấp hay không.

job "web-server" {
  datacenters = ["dc1"]
  type        = "service"

  group "nginx-group" {
    count = 2 

    network {
      port "http" {
        static = 8080
      }
    }

    task "nginx-task" {
      driver = "docker"

      config {
        image = "nginx:1.25.3"
        ports = ["http"]
      }

      resources {
        cpu    = 500 # 500 MHz
        memory = 256 # 256 MB
      }
    }
  }
}

Chạy job chỉ với một lệnh duy nhất:

nomad job run webapp.nomad

Giám sát và Debug

Truy cập vào http://your-server-ip:4646 để mở giao diện UI tích hợp. Nó nhanh, sạch sẽ và cung cấp cái nhìn tức thì về sức khỏe của cluster. Không giống như dashboard của Kubernetes thường tạo cảm giác như một phần bổ trợ rời rạc, UI của Nomad là một phần của trải nghiệm cốt lõi.

Việc debug cũng nhanh chóng không kém. Bạn không phải vật lộn với các context kubectl phức tạp. Chỉ cần sử dụng allocation ID:

# Tìm allocation ID của bạn
nomad job status web-server

# Xem log theo thời gian thực
nomad alloc logs <allocation_id>

Quản lý secret giữa môi trường Dev và Prod là mảnh ghép cuối cùng. Tôi sử dụng Trình tạo mật khẩu để tạo các chuỗi 32 ký tự cho thông tin đăng nhập database. Vì công cụ này chạy phía client, các secret của bạn nằm lại trong trình duyệt và không bao giờ xuất hiện trong file log trên máy chủ của người khác.

Lời kết

Nomad không chỉ giúp chấm dứt những cuộc gọi lúc 2 giờ sáng. Nó còn tinh gọn toàn bộ quy trình triển khai của chúng tôi. Chúng tôi ngừng việc đối phó với bộ điều phối (orchestrator) và bắt đầu tập trung vào việc phát triển tính năng. Nếu bạn có một đội ngũ tinh gọn hoặc nhu cầu của bạn không cần đến hệ sinh thái khổng lồ của Kubernetes, hãy thử Nomad. Sự đơn giản của một file binary duy nhất hoạt động trơn tru là một lợi thế vận hành cực lớn.