Nâng cấp phiên bản cụm BKE

Người dùng có thể nâng cấp cluster BKE đến bản vá mới nhất (ví dụ 1.24.4 thành 1.24.14) cũng như nâng cấp thành phiên bản mới (ví dụ 1.25.4 thành 1.26.4) tại giao diện

BKE hiện tại hỗ trợ 2 kiểu upgrade như sau:

Thủ công: Khi có bản nâng cấp mới, có thể nâng cấp thủ công lên phiên bản mới nhất

Tự động: Khi bật chế độ tự động nâng cấp thì người dùng sẽ cài đặt khoảng thời gian bảo trì. Khi có bản vá mới sẽ cập nhật lên bản vá vào thời gian bảo trì đó. Khi tắt sẽ không nâng cấp bất cứ bản vá hay phiên bản nào.

Lưu ý: Ở chế độ tự động sẽ k nâng cấp lên phiên bản mới nhất, chỉ nâng lên bản vá với nhất (1.18.3 lên 1.18.14). Khi hết thời gian hỗ trợ sẽ tự động nâng cấp lên phiên bản tiếp theo (1.18.z lên 1.19.z). Xem thời gian hỗ trợ tại đây

Quá trình nâng cấp

Trong quá trình nâng cấp, control-plane (master) sẽ được thay thế bằng control-plane của version mới, quá trình diễn ra trong 1 vài phút, trong lúc này thì API server sẽ có thể không truy cập được, các ứng dụng khác đang chạy sẽ k ảnh hưởng

Khi đã nâng cấp control-plane xong thì các node worker được thay thế theo kiểu cuốn chiếu, mỗi lần một worker pool. Kubernetes lên lịch lại các pods của từng node worker, sau đó thay thế node đó bằng một node mới chạy phiên bản mới và gắn lại bất kỳ pod nào vào các node mới. Các node worker mới có địa chỉ IP mới.

Khi các node được nâng cấp, pod chạy trên các cụm với 01 node worker duy nhất sẽ gặp phải thời gian ngừng hoạt động do không có node dự trữ để chuyển tiếp pod sang khi thay thế node

Lưu ý: Mọi dữ liệu được lưu trữ trên rootdisk của các node worker sẽ bị mất trong quá trình nâng cấp. Chúng tôi khuyên bạn nên sử dụng persistent volumes để lưu trữ dữ liệu và không dựa vào rootdisk cho bất kỳ thứ gì khác ngoài dữ liệu tạm thời.

Giảm thiểu sự gián đoạn trong quá trình nâng cấp

Việc nâng cấp cụm của bạn có thể gây ra sự gián đoạn về tính khả dụng của các dịch vụ của bạn. Xem xét các biện pháp sau để cải thiện tính khả dụng của dịch vụ trong quá trình nâng cấp.

Cấu hình PodDisruptionBudget

PodDisruptionBudget (PDB) chỉ định số lượng bản sao tối thiểu mà một ứng dụng có thể chịu đựng được trong quá trình gián đoạn tự nguyện, liên quan đến số lượng bản sao dự định có. Ví dụ: nếu bạn đặt giá trị bản sao cho một lần triển khai thành 5 và đặt PDB thành 1, thì các hành động có khả năng gây gián đoạn như nâng cấp và thay đổi kích thước cụm sẽ xảy ra với không ít hơn bốn nhóm đang chạy.

Tham khảo về PodDisruptionBudget

Graceful Shutdowns

Đảm bảo rằng các container trong pod của bạn đáp ứng các yêu cầu tắt máy theo cách không đột ngột phá hủy dịch vụ. Bạn có thể sử dụng các công cụ như hook preStop phản hồi việc tắt Pod theo lịch trình và chỉ định thời gian gia hạn khác với mặc định 30 giây.

Điều này rất quan trọng vì các nâng cấp cụm sẽ dẫn đến việc tắt Pod, tuân theo vòng đời kết thúc Kubernetes tiêu chuẩn:

  1. Pod được đặt ở trạng thái “Terminating” và bị xóa dưới dạng endpoint.
  2. preStop hook được thực thi, nếu nó tồn tại.
  3. Một tín hiệu SIGTERM được gửi đến Pod, thông báo cho các container rằng chúng sẽ sớm bị tắt. Code của bạn sẽ lắng nghe event này và bắt đầu tắt vào thời điểm này.
  4. Kubernetes đợi thời gian gia hạn trôi qua; thời gian gia hạn mặc định là 30 giây.
  5. Tín hiệu SIGKILL được gửi đến bất kỳ thùng chứa nào vẫn chưa tắt và Pod sẽ bị xóa.

Tham khảo về Graceful Shutdown

Thiết lập Readiness Probes

Readiness Probes hữu ích nếu các ứng dụng đang chạy nhưng không thể phục vụ lưu lượng truy cập, do những thứ như dịch vụ bên ngoài vẫn đang khởi động, tải tập dữ liệu lớn, v.v. Bạn có thể định cấu hình Readiness Probes để báo cáo trạng thái như vậy.

Tham khảo Readiness Probes