Các hệ thống phân tán có thể khó quản lý vì chúng có nhiều yếu tố chuyển động, thay đổi mà tất cả đều cần hoạt động bình thường để hệ thống hoạt động. Nếu một trong các yếu tố bị lỗi, hệ thống phải phát hiện nó, bỏ qua nó và sửa chữa nó, đồng thời tất cả những điều này phải được thực hiện tự động. Trong loạt bài Thực tiễn tốt nhất về Kubernetes này, chúng ta sẽ tìm hiểu cách thiết lập các bài kiểm tra Mức độ sẵn sàng và Sự sống động để kiểm tra tình trạng của cụm Kubernetes.
Kiểm tra tình trạng là một cách đơn giản để cho hệ thống biết phiên bản ứng dụng của bạn có chạy hay không. Nếu phiên bản ứng dụng của bạn không hoạt động thì các dịch vụ khác sẽ không thể truy cập hoặc gửi yêu cầu tới nó. Thay vào đó, yêu cầu phải được gửi đến một phiên bản khác của ứng dụng đang chạy hoặc sẽ được khởi chạy sau. Ngoài ra, hệ thống sẽ khôi phục chức năng bị mất của ứng dụng của bạn.
Theo mặc định, Kubernetes sẽ bắt đầu gửi lưu lượng truy cập đến một nhóm khi tất cả các vùng chứa trong nhóm đang chạy và khởi động lại các vùng chứa khi chúng gặp sự cố. Hành vi hệ thống mặc định này có thể đủ tốt để bắt đầu, nhưng bạn có thể cải thiện độ tin cậy của việc triển khai sản phẩm bằng cách sử dụng các biện pháp kiểm tra độ chính xác tùy chỉnh.
May mắn thay, Kubernetes khiến việc này khá dễ thực hiện, vì vậy không có lý do gì để bỏ qua những bước kiểm tra này. Kubernetes cung cấp hai loại Kiểm tra tình trạng và điều quan trọng là phải hiểu sự khác biệt trong cách sử dụng từng loại.
Kiểm tra mức độ sẵn sàng được thiết kế để cho Kubernetes biết rằng ứng dụng của bạn đã sẵn sàng xử lý lưu lượng truy cập. Trước khi cho phép dịch vụ gửi lưu lượng truy cập đến nhóm, Kubernetes phải xác minh rằng quá trình kiểm tra mức độ sẵn sàng đã thành công. Nếu quá trình kiểm tra Mức độ sẵn sàng không thành công, Kubernetes sẽ ngừng gửi lưu lượng truy cập đến nhóm cho đến khi quá trình kiểm tra vượt qua.
Kiểm tra Liveness cho Kubernetes biết ứng dụng của bạn còn sống hay đã chết. Trong trường hợp đầu tiên, Kubernetes sẽ để yên, trong trường hợp thứ hai, nó sẽ xóa nhóm chết và thay thế bằng một nhóm mới.
Hãy tưởng tượng một tình huống trong đó ứng dụng của bạn mất 1 phút để khởi động và khởi chạy. Dịch vụ của bạn sẽ không bắt đầu hoạt động cho đến khi ứng dụng được tải và chạy hoàn toàn, mặc dù quy trình làm việc đã bắt đầu. Bạn cũng sẽ gặp vấn đề nếu muốn mở rộng quy mô triển khai này thành nhiều bản sao vì những bản sao đó sẽ không nhận được lưu lượng truy cập cho đến khi chúng hoàn toàn sẵn sàng. Tuy nhiên, theo mặc định, Kubernetes sẽ bắt đầu gửi lưu lượng truy cập ngay khi các quá trình bên trong vùng chứa bắt đầu.
Khi sử dụng Readiness test, Kubernetes sẽ đợi cho đến khi ứng dụng chạy hoàn toàn trước khi cho phép dịch vụ gửi lưu lượng truy cập đến bản sao mới.
Hãy tưởng tượng một tình huống khác trong đó ứng dụng bị treo trong thời gian dài, ngừng cung cấp các yêu cầu phục vụ. Khi quá trình tiếp tục chạy, theo mặc định Kubernetes sẽ cho rằng mọi thứ đều ổn và tiếp tục gửi yêu cầu đến nhóm không hoạt động. Nhưng khi sử dụng Liveness, Kubernetes sẽ phát hiện ứng dụng không còn phục vụ yêu cầu nữa và sẽ khởi động lại nhóm chết theo mặc định.
Hãy xem mức độ sẵn sàng và khả năng tồn tại được kiểm tra như thế nào. Có ba phương pháp thử nghiệm - HTTP, Command và TCP. Bạn có thể sử dụng bất kỳ trong số họ để kiểm tra. Cách phổ biến nhất để kiểm tra người dùng là thăm dò HTTP.
Ngay cả khi ứng dụng của bạn không phải là máy chủ HTTP, bạn vẫn có thể tạo một máy chủ HTTP nhẹ bên trong ứng dụng của mình để tương tác với bài kiểm tra Liveness. Sau đó, Kubernetes sẽ bắt đầu ping pod và nếu phản hồi HTTP nằm trong phạm vi 200 hoặc 300 ms, điều đó sẽ cho biết pod vẫn hoạt động tốt. Nếu không, mô-đun sẽ được đánh dấu là "không tốt".
Đối với các bài kiểm tra Lệnh, Kubernetes chạy lệnh bên trong vùng chứa của bạn. Nếu lệnh trả về với mã thoát bằng 1 thì vùng chứa sẽ được đánh dấu là khỏe mạnh, nếu không, khi nhận được số trạng thái thoát từ 255 đến XNUMX, vùng chứa sẽ được đánh dấu là “bị bệnh”. Phương pháp kiểm tra này hữu ích nếu bạn không thể hoặc không muốn chạy máy chủ HTTP nhưng có thể chạy lệnh kiểm tra tình trạng ứng dụng của bạn.
Cơ chế xác minh cuối cùng là kiểm tra TCP. Kubernetes sẽ cố gắng thiết lập kết nối TCP trên cổng được chỉ định. Nếu thực hiện được điều này thì vật chứa được coi là khỏe mạnh, nếu không thì vật chứa đó được coi là không thể tồn tại được. Phương pháp này có thể hữu ích nếu bạn đang sử dụng tình huống trong đó việc kiểm tra bằng yêu cầu HTTP hoặc thực thi lệnh không hoạt động tốt. Ví dụ: các dịch vụ chính để xác minh bằng TCP sẽ là gRPC hoặc FTP.
Các thử nghiệm có thể được cấu hình theo nhiều cách với các thông số khác nhau. Bạn có thể chỉ định tần suất chúng sẽ được thực thi, ngưỡng thành công và thất bại là bao nhiêu cũng như thời gian chờ phản hồi. Để biết thêm thông tin, hãy xem tài liệu về các bài kiểm tra Sẵn sàng và Sống động. Tuy nhiên, có một điểm rất quan trọng trong việc thiết lập kiểm tra Liveness - cài đặt ban đầu của độ trễ kiểm tra initDelaySeconds. Như tôi đã đề cập, việc kiểm tra này không thành công sẽ dẫn đến việc mô-đun bị khởi động lại. Vì vậy, bạn cần đảm bảo rằng quá trình kiểm tra không bắt đầu cho đến khi ứng dụng sẵn sàng hoạt động, nếu không, quá trình kiểm tra sẽ bắt đầu quay vòng qua các lần khởi động lại. Tôi khuyên bạn nên sử dụng thời gian khởi động P99 hoặc thời gian khởi động ứng dụng trung bình từ bộ đệm. Hãy nhớ điều chỉnh giá trị này khi thời gian khởi động ứng dụng của bạn nhanh hơn hoặc chậm hơn.
Hầu hết các chuyên gia sẽ xác nhận rằng Health Checks là bước kiểm tra bắt buộc đối với bất kỳ hệ thống phân tán nào và Kubernetes cũng không ngoại lệ. Việc sử dụng tính năng kiểm tra tình trạng dịch vụ đảm bảo Kubernetes hoạt động đáng tin cậy, không gặp sự cố và người dùng không gặp khó khăn gì.
Sẽ sớm được tiếp tục...
Một số quảng cáo 🙂
Cảm ơn bạn đã ở với chúng tôi. Bạn có thích bài viết của chúng tôi? Bạn muốn xem nội dung thú vị hơn? Hỗ trợ chúng tôi bằng cách đặt hàng hoặc giới thiệu cho bạn bè, , một dạng tương tự duy nhất của các máy chủ cấp đầu vào do chúng tôi phát minh ra dành cho bạn: (có sẵn với RAID1 và RAID10, tối đa 24 lõi và tối đa 40GB DDR4).
Dell R730xd rẻ hơn gấp 2 lần tại trung tâm dữ liệu Equinix Tier IV ở Amsterdam? Chỉ ở đây ở Hà Lan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - từ $99! Đọc về
Nguồn: www.habr.com