Kubernetes giới hạn số lần khởi động lại nhóm đồng thời trên toàn bộ cụm

Chúng tôi có một cụm Kubernetes 6 nút chạy khoảng 20 khối lượng công việc tập hợp bản sao lớn (các dịch vụ Java). Mỗi nhóm khối lượng công việc (1 nhóm cho mỗi khối lượng công việc) mất trung bình khoảng 30 giây để khởi động và sử dụng rất nhiều CPU. Điều này làm cho việc bắt đầu nhiều nhóm/khối lượng công việc cùng lúc trở thành một vấn đề - đến mức khi 2 hoặc 3 nhóm bắt đầu cùng lúc trên cùng một nút, chúng sẽ mất vài phút để bắt đầu và cuối cùng bị tiêu diệt bởi thăm dò mức độ sẵn sàng. Việc thăm dò mức độ sẵn sàng khá thoải mái, nhưng việc kéo dài thời gian gia hạn vô thời hạn có vẻ không phải là một thông lệ tốt.

Như mọi người có thể tưởng tượng, điều này làm cho việc tạo chuỗi và thoát một nút trở thành vấn đề - nếu chúng ta rút một nút, tất cả các nhóm sẽ khởi động lại cùng lúc ở một nơi khác và có thể làm quá tải một công nhân (hoặc khiến nó dừng lại gây ra nhiều lần khởi động lại, cuối cùng dẫn đến khóa cơ sở dữ liệu ).

Để giải quyết vấn đề này, tôi đã viết một tập lệnh shell sử dụng kubectl để liệt kê các nhóm, khởi động lại từng nhóm (bằng cách vá dữ liệu meta), đợi trạng thái khả dụng và chuyển sang nhóm tiếp theo.

Các tập lệnh hoạt động tốt để vá lỗi máy chủ hoặc nâng cấp khối lượng công việc, nhưng không giải quyết được vấn đề ngừng hoạt động của nút - mọi thứ đều chạy trong AWS và khi một nút bị lỗi, một nút mới được tạo thông qua tính năng tự động thay đổi quy mô, nhưng điều đó có nghĩa là 4 nhóm sẽ thử và khởi động lại cùng một lúc thời gian (tất nhiên là vào sáng chủ nhật lúc 3 giờ sáng).

Một ý tưởng là có một bộ chứa init nhận biết được các khối lượng công việc bắt đầu khác - nếu không có khối lượng công việc nào khác hiện đang bắt đầu trên cùng một nút, thì bộ chứa init sẽ thoát ra cho phép bộ chứa chính bắt đầu. Điều này sẽ yêu cầu tài khoản dịch vụ và quyền, nhưng có thể là một giải pháp thay thế, nhưng tôi tự hỏi liệu có cách nào tiêu chuẩn hơn để thực hiện việc này thông qua cấu hình (quy tắc về mối quan hệ, v.v.) không?

Đây là loại vấn đề mà người ta gặp phải khi các nhóm có thể lên lịch ở bất kỳ đâu. Bạn đang đi đúng hướng với các quy tắc về mối quan hệ.

Bạn có thể làm cho các nhóm này thể hiện mối quan hệ đối kháng với nhau bằng cách tạo các nhóm trong bộ bản sao của triển khai thể hiện mối quan hệ tiêu cực với nhau (để chúng lan truyền giữa các nút). Điều này làm cho việc lập lịch trình hơi nặng nề, nhưng hoàn thành việc giữ cho các nhóm không gây ra lỗi xếp tầng khi một nút bị mất. Nó cũng thực hiện khá tốt việc đảm bảo rằng chúng lan truyền giữa các miền lỗi, nhưng đó chỉ là một tác dụng phụ.

Tuy nhiên, có một cách tốt hơn để thực hiện điều này - thông qua các ràng buộc về trải rộng cấu trúc liên kết nhóm. Bằng cách chỉ định một ràng buộc trải rộng, bộ lập lịch trình sẽ đảm bảo rằng các nhóm được cân bằng giữa các miền lỗi (có thể là AZ hoặc nút) và việc không cân bằng các nhóm sẽ dẫn đến việc lập lịch trình không thành công.

Người ta có thể viết điều này theo cách đảm bảo các nhóm được phân phối giữa các nút và lỗi nút sẽ không gây ra "nhóm". Hãy xem nhóm ví dụ này:

loại: Vỏ
phiên bản api: v1
metadata:
  tên: mypad
  nhãn:
    foo: thanh
thông số kỹ thuật:
  topoSpreadConstraints:
  - Độ nghiêng tối đa: 1
    khóa cấu trúc liên kết: vùng
    whenUnsatisfiable: DoNotSchedule
    nhãnSelector:
      trận đấuNhãn:
        foo: thanh
  - Độ nghiêng tối đa: 1
    khóa cấu trúc liên kết: nút
    whenUnsatisfiable: DoNotSchedule
    nhãnSelector:
      trận đấuNhãn:
        foo: thanh
  hộp đựng:
  - tên: tạm dừng
    hình ảnh: k8s.gcr.io/pause:3.1

Điều này có thể được kết hợp với các quy tắc mối quan hệ nếu bạn cũng không muốn các triển khai và bộ bản sao của chúng được lên lịch với các triển khai khác trên cùng một nút, giúp giảm hiệu ứng "gộp" hơn nữa. Anti-affinity mềm thường thích hợp trong trường hợp như vậy, vì vậy bộ lập lịch trình sẽ "cố gắng không" sắp xếp các khối lượng công việc đó khi có thể.