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:
- Pod được đặt ở trạng thái “Terminating” và bị xóa dưới dạng endpoint.
- preStop hook được thực thi, nếu nó tồn tại.
- 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.
- Kubernetes đợi thời gian gia hạn trôi qua; thời gian gia hạn mặc định là 30 giây.
- 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.
Chỉ nâng cấp Control plane
Khi sử dụng tính năng chỉ nâng cấp control plane khi nâng cấp thì hệ thống sẽ chỉ nâng cấp thành phần quản lý lên phiên bản mới, toàn bộ các Worker Pool được giữ nguyên không ảnh hưởng.
Các Worker Pool được tạo mới sau khi đã nâng cấp sẽ sử dụng phiên bản mới.