Hướng dẫn cấu hình Health check K8s chi tiết nhất

Từ kinh nghiệm triển khai và vận hành nhiều cụm Kubernetes cho hệ thống thực tế, mình nhận thấy Health check K8s là một trong những cơ chế kỹ thuật quan trọng nhất để giữ cho ứng dụng ổn định, hạn chế tối đa sự cố khó đoán. Health check trong Kubernetes cho phép cụm kiểm tra tự động trạng thái container và Pod thông qua các probe do kubelet thực thi định kỳ, từ đó quyết định khi nào cần ngừng nhận traffic hoặc khởi động lại container. Trong bài viết này, mình sẽ chia sẻ chi tiết về các loại probe, cách chúng hoạt động và cách cấu hình thực tế để bạn có thể áp dụng hiệu quả vào môi trường của mình.

Những điểm chính

Những nội dung dưới đây được mình chọn lọc xoay quanh các tình huống thường gặp khi triển khai Kubernetes ngoài môi trường thực tế, giúp bạn không chỉ hiểu khái niệm mà còn định hình rõ hướng áp dụng vào hệ thống của chính mình.

• Khái niệm: Hiểu rõ Health check là một cơ chế kiểm tra tự động, giúp bạn đảm bảo Kubernetes có thể phát hiện và xử lý các container không khỏe mạnh để duy trì tính sẵn sàng của ứng dụng.
• Các loại probe: Phân biệt rõ vai trò của Liveness, Readiness và Startup probe, giúp bạn lựa chọn và áp dụng đúng cơ chế kiểm tra cho từng giai đoạn trong vòng đời của ứng dụng.
• Cách thức hoạt động: Nắm vững cơ chế hoạt động của từng loại probe, giúp bạn hiểu rõ cách Kubernetes tự động xử lý sự cố như khởi động lại container hoặc ngừng gửi lưu lượng truy cập để duy trì sự ổn định.
• Cách cấu hình: Nắm vững quy trình 6 bước để cấu hình health check, giúp bạn có thể tự mình khai báo và thiết lập các probe một cách chính xác trong file manifest Kubernetes.
• Cấu hình cho Spring Boot: Tìm hiểu cách tích hợp health check với ứng dụng Spring Boot, giúp bạn áp dụng vào thực tế để tăng cường độ tin cậy cho các ứng dụng Java của mình.
• Thực hành và gỡ lỗi: Nắm vững các phương pháp thực hành với HTTPS và công cụ dòng lệnh, giúp bạn tự tin kiểm tra, gỡ lỗi và đảm bảo các probe hoạt động chính xác trong môi trường thực tế.
• Giới thiệu Vietnix: Biết đến Vietnix là nhà cung cấp dịch vụ Enterprise Cloud, giúp bạn có một nền tảng hạ tầng đáng tin cậy để triển khai các giải pháp Kubernetes.
• Câu hỏi thường gặp: Giải đáp các thắc mắc liên quan đến Health check.

Health check trong Kubernetes là gì?

Health check trong Kubernetes là cơ chế kiểm tra tự động cho phép cụm Kubernetes xác định trạng thái hoạt động của container và Pod thông qua các probe (đầu dò) được kubelet thực thi định kỳ. Về bản chất, đây là các kiểm tra kỹ thuật (HTTP, TCP hoặc lệnh exec) nhằm trả lời hai câu hỏi: Container có đang chạy đúng chức năng hay không và Pod có sẵn sàng nhận traffic hay chưa, từ đó làm cơ sở cho các hành động như loại Pod khỏi Service endpoints hoặc khởi động lại container khi cần thiết.

Có 3 loại probe trong Kubernetes được sử dụng để triển khai health check cho container, trong đó mỗi loại đảm nhiệm một mục tiêu kiểm tra khác nhau trong vòng đời ứng dụng

Readiness probe: Kiểm tra khả năng sẵn sàng nhận request

Readiness probe được dùng để xác định container có đang ở trạng thái sẵn sàng tiếp nhận và xử lý request hay chưa, thường thông qua endpoint HTTP, TCP hoặc lệnh exec do ứng dụng cung cấp. Khi readiness probe trả về kết quả thất bại, Kubernetes không restart container mà loại IP/port của Pod khỏi đối tượng Endpoints, khiến Pod tạm thời không nhận traffic từ Service cho đến khi probe lại thành công và Pod được đưa trở lại danh sách endpoint.

Liveness probe: Kiểm tra container còn hoạt động bình thường

Liveness probe được sử dụng để phát hiện trường hợp container vẫn ở trạng thái Running nhưng ứng dụng bên trong không còn xử lý được request do các vấn đề như deadlock, vòng lặp vô hạn hoặc lỗi tài nguyên (ví dụ OutOfMemoryError). Nếu liveness probe liên tục trả về mã lỗi (không nằm trong nhóm 2xx/3xx đối với HTTP hoặc không vượt qua kiểm tra TCP/exec), kubelet sẽ coi container không còn healthy và thực hiện restart theo restartPolicy để khôi phục tiến trình ứng dụng.

Startup probe: Kiểm tra giai đoạn khởi động ứng dụng

Startup probe được dùng để theo dõi quá trình khởi chạy ban đầu của ứng dụng, đặc biệt hữu ích với các dịch vụ cần nhiều thời gian init như kết nối nhiều database, khởi tạo cache hoặc nạp cấu hình phức tạp. Khi cấu hình startup probe, Kubernetes sẽ tạm vô hiệu hóa liveness và readiness cho đến khi startup probe trả về thành công. Nếu startup probe thất bại quá ngưỡng cấu hình, container bị coi là khởi động không thành công và bị restart, giúp tránh trường hợp ứng dụng đang khởi động mà bị liveness/readiness đánh fail sớm.

Cách thức hoạt động của health check trong Kubernetes

Health check trong Kubernetes hoạt động dựa trên việc kubelet định kỳ gửi các probe (HTTP, TCP hoặc exec) đến container theo cấu hình trong Pod spec. Dựa vào kết quả phản hồi, hệ thống sẽ xác định trạng thái hoạt động của container.

Mỗi probe được cấu hình với các tham số quan trọng như:

• initialDelaySeconds: Thời gian chờ trước khi bắt đầu kiểm tra
• periodSeconds: Tần suất thực hiện kiểm tra
• timeoutSeconds: Thời gian chờ phản hồi
• failureThreshold / successThreshold: Số lần thất bại hoặc thành công để thay đổi trạng thái

Nhờ các tham số này, Kubernetes kiểm soát chặt chẽ quá trình kiểm tra và đánh giá trạng thái của Pod.

1. Liveness Probe

• Nếu liveness probe thất bại quá số lần cho phép, kubelet sẽ coi container bị lỗi.
• Hệ thống sẽ dừng và khởi động lại container theo restartPolicy.
• Mục tiêu: Loại bỏ tiến trình bị treo hoặc hoạt động sai.

2. Readiness Probe

• Nếu readiness probe thất bại, container không bị restart.
• Tuy nhiên, Pod sẽ bị loại khỏi danh sách Endpoints của Service → không nhận thêm request.
• Khi probe thành công trở lại, Pod sẽ được đưa vào lại hệ thống phục vụ traffic.
• Mục tiêu: Đảm bảo chỉ Pod sẵn sàng mới nhận request.

3. Startup Probe

• Chỉ chạy trong giai đoạn khởi động ứng dụng.
• Trong thời gian này, liveness và readiness tạm thời bị vô hiệu hóa.
• Nếu startup probe:
  • Thất bại quá ngưỡng → container bị restart.
  • Thành công → Kubernetes bắt đầu áp dụng liveness và readiness.
• Mục tiêu: Tránh việc ứng dụng bị restart sớm khi chưa kịp khởi động hoàn tất.

Tóm lại:

• Liveness: Quyết định có restart container hay không.
• Readiness: Quyết định có nhận traffic hay không.
• Startup: Bảo vệ giai đoạn khởi động ban đầu.

Cơ chế này giúp Kubernetes duy trì hệ thống ổn định, tự động phát hiện và xử lý lỗi trong suốt vòng đời ứng dụng.

Cấu hình health check trong manifest Kubernetes

Để cấu hình health check trong manifest Kubernetes, có thể đi theo các bước tuần tự như sau:

Bước 1: Xác định endpoint hoặc cơ chế kiểm tra health của ứng dụng

Trước hết, bạn cần xác định ứng dụng sẽ cung cấp health check theo hình thức nào: endpoint HTTP (ví dụ /health, /actuator/health), kiểm tra cổng TCP hay thực thi lệnh bên trong container (exec). Với các ứng dụng Spring Boot, thường sử dụng các endpoint từ Actuator tách riêng cho liveness và readiness, ví dụ /actuator/health/liveness và /actuator/health/readiness.

Bước 2: Chọn loại probe phù hợp (liveness, readiness, startup)

Tiếp theo, bạn cần quyết định container sẽ dùng những loại probe nào: readiness để kiểm tra khả năng sẵn sàng nhận request, liveness để kiểm tra container còn hoạt động bình thường và startup nếu ứng dụng khởi động chậm hoặc quy trình init phức tạp. Việc lựa chọn đúng loại probe cho từng mục đích giúp manifest phản ánh chính xác cách hệ thống cần đối xử với Pod khi kết quả health check thay đổi.

Bước 3: Khai báo block probe trong phần containers của manifest

Sau khi đã chọn loại probe, bạn cần thêm các trường readinessProbe, livenessProbe và startupProbe vào từng container trong phần spec.template.spec.containers của Deployment hoặc Pod. Mỗi block probe được khai báo độc lập cho từng container, bảo đảm Kubernetes có thể kiểm tra health từng container một cách tách biệt thay vì chỉ dựa trên trạng thái Pod tổng thể.

Bước 4: Cấu hình hành động kiểm tra (httpGet, tcpSocket, exec)

Trong mỗi probe, bạn cần chọn và cấu hình một hành động kiểm tra cụ thể. Nếu dùng HTTP, cần khai báo httpGet với các thuộc tính path, port và scheme (HTTP hoặc HTTPS) trỏ đúng endpoint của ứng dụng. Nếu ứng dụng phù hợp hơn với kiểm tra cổng, có thể dùng tcpSocket chỉ định port hoặc dùng exec.command để chạy lệnh nội bộ (ví dụ script kiểm tra trạng thái phụ thuộc) trong container khi cần kiểm tra logic phức tạp hơn

Bước 5: Thiết lập các tham số thời gian và ngưỡng cho probe

Tiếp đến, bạn cần tinh chỉnh các tham số thời gian cho từng probe, bao gồm initialDelaySeconds (thời gian chờ trước lần kiểm tra đầu tiên), periodSeconds (tần suất chạy probe) và timeoutSeconds (thời gian chờ phản hồi trước khi coi kiểm tra thất bại). Đồng thời, failureThreshold và successThreshold được dùng để xác định số lần thất bại hoặc thành công liên tiếp cần thiết trước khi Kubernetes thay đổi trạng thái container, giúp tránh bị ảnh hưởng bởi các lỗi tạm thời hoặc phản hồi chậm nhất thời.

Bước 6: Kiểm tra manifest và triển khai lên cluster

Sau khi hoàn tất cấu hình probe và các tham số, bạn cần kiểm tra lại manifest để bảo đảm cú pháp YAML đúng, đường dẫn, cổng và scheme trùng khớp môi trường thực tế, rồi áp dụng manifest bằng kubectl apply -f. Khi Pod được tạo hoặc cập nhật, kubelet sẽ bắt đầu thực hiện các probe theo cấu hình. Bạn cũng có thể dùng kubectl describe pod và kubectl get endpoints để quan sát trạng thái liveness, readiness và việc Pod có được đưa vào/loại khỏi Service endpoints hay không.

Cấu hình health check cho ứng dụng Spring Boot trên Kubernetes

Để cấu hình health check cho ứng dụng Spring Boot trên Kubernetes, bạn có thể thực hiện lần lượt theo các bước sau:

Bước 1: Kích hoạt Spring Boot Actuator và endpoint health

Trước hết, bạn cần khai báo dependency spring-boot-starter-actuator trong ứng dụng Spring Boot để bật tính năng Actuator. Sau đó, cấu hình trong application.yml hoặc application.properties để mở endpoint /actuator/health và nếu cần nhóm health riêng cho liveness và readiness (ví dụ management.endpoint.health.group.liveness và management.endpoint.health.group.readiness).

Bước 2: Tách logic health cho liveness và readiness trong Spring Boot

Tiếp theo, bạn cần thiết kế các nhóm health hoặc indicator phù hợp với hai mục đích: liveness chỉ kiểm tra ứng dụng còn chạy (ví dụ thread chính, heap, basic self-check), còn readiness kiểm tra thêm các phụ thuộc như database, cache, message broker để bảo đảm ứng dụng đủ điều kiện nhận request. Cách tách này giúp Spring Boot trả về trạng thái chính xác cho từng endpoint, để khi Kubernetes gọi /actuator/health/liveness hoặc /actuator/health/readiness có thể phân biệt được container cần restart hay chỉ tạm thời không nên nhận traffic.

Bước 3: Xác định endpoint và cổng sẽ dùng cho probe

Sau khi cấu hình Actuator, bạn cần thống nhất endpoint và cổng mà Kubernetes sẽ gọi, ví dụ container lắng nghe trên port 8080 với các endpoint /actuator/health/liveness và /actuator/health/readiness. Việc xác định rõ đường dẫn và port ngay từ bước này giúp tránh sai sót khi khai báo httpGet trong manifest Kubernetes, đặc biệt với môi trường có reverse proxy hoặc context-path riêng.

Bước 4: Khai báo readinessProbe sử dụng endpoint Actuator

Trong manifest Deployment hoặc Pod, tại phần spec.template.spec.containers, bạn cần thêm block readinessProbe cho container chạy ứng dụng Spring Boot. Block này thường sử dụng httpGet với path trỏ tới /actuator/health/readiness, port là cổng container (ví dụ 8080) và các tham số như initialDelaySeconds, periodSeconds, timeoutSeconds, failureThreshold được điều chỉnh theo thời gian khởi động và đặc tính xử lý của ứng dụng, để Pod chỉ được đưa vào Endpoints khi Actuator báo readiness “UP”.

Bước 5: Khai báo livenessProbe để giám sát container đang chạy

Song song với readiness, cần khai báo livenessProbe cho cùng container, cũng tại phần containers trong manifest. Liveness probe thường dùng httpGet trỏ tới /actuator/health/liveness, với bộ tham số thời gian phù hợp để Kubernetes có thể phát hiện trường hợp Spring Boot không còn xử lý request (ví dụ do deadlock, OutOfMemoryError) và thực hiện restart container khi endpoint liveness trả về trạng thái lỗi hoặc mã HTTP không nằm trong nhóm 2xx/3xx.

Bước 6: Cân nhắc thêm startupProbe cho ứng dụng khởi động chậm

Đối với Spring Boot có quá trình init dài (kết nối nhiều database, khởi tạo cache lớn), bạn có thể bổ sung startupProbe để Kubernetes chỉ bắt đầu đánh giá liveness và readiness sau khi ứng dụng khởi động ổn định. Startup probe có thể trỏ vào cùng một endpoint health (liveness hoặc custom) với failureThreshold và periodSeconds được nới rộng, giúp tránh tình trạng Pod bị liveness/readiness đánh fail rồi restart trong khi Spring Boot vẫn đang trong giai đoạn khởi động.

Bước 7: Áp dụng manifest và kiểm tra kết quả trên cluster

Cuối cùng, sau khi đã cấu hình đầy đủ readinessProbe, livenessProbe và nếu dùng startupProbe trong manifest, bạn cần triển khai bằng kubectl apply -f và theo dõi trạng thái Pod. Có thể sử dụng kubectl describe pod để xem log probe, mã trả về từ các endpoint Actuator và kiểm tra kubectl get endpoints để xác nhận Pod chỉ được đưa vào Service khi readiness của Spring Boot đạt yêu cầu, đồng thời container được tự động restart khi liveness thất bại.

Thực hành cấu hình health check với HTTPS và công cụ dòng lệnh

Bước 1: Cấu hình HTTP(S) health endpoint trong ứng dụng

Trước tiên, bạn cần bảo đảm ứng dụng expose một endpoint health qua HTTPS, ví dụ /health, /actuator/health hoặc endpoint riêng cho liveness/readiness, lắng nghe trên cổng 443 hoặc một cổng HTTPS bất kỳ. Endpoint này phải trả mã trạng thái HTTP 2xx/3xx khi ứng dụng ở trạng thái “healthy” và trả mã lỗi hoặc timeout khi có sự cố, để kubelet có căn cứ đánh giá kết quả probe.

Bước 2: Khai báo probe sử dụng HTTPS trong manifest Kubernetes

Tiếp theo, trong manifest Deployment/Pod, tại phần containers, bạn cần khai báo livenessProbe và/hoặc readinessProbe với kiểu httpGet và scheme: HTTPS. Cấu hình này thường bao gồm path trỏ tới endpoint health (ví dụ /darwin-probes hoặc /actuator/health), port trùng với cổng HTTPS container, cùng các tham số initialDelaySeconds, periodSeconds, timeoutSeconds, failureThreshold được điều chỉnh cho phù hợp với thời gian khởi động và khả năng phản hồi của ứng dụng.

Bước 3: Triển khai manifest và kiểm tra resource bằng kubectl

Sau khi cấu hình probe dùng HTTPS, tiến hành triển khai bằng kubectl apply -f deployment.yml và tạo Service nếu cần, sau đó dùng kubectl get pods, kubectl get svc để kiểm tra Pod, Service đã được tạo đúng chưa. Tiếp tục, bạn sử dụng kubectl describe pod <pod-name> để xem chi tiết events liên quan đến liveness/readiness/startup, bao gồm các lần probe thất bại, mã lỗi và thông điệp giúp xác định Pod có đang bị loại khỏi Endpoints hay container đang bị restart do liveness fail.

Bước 4: Dùng curl kiểm tra trực tiếp endpoint HTTPS

Để xác thực rằng endpoint health hoạt động đúng ngoài ngữ cảnh Kubernetes, bạn có thể sử dụng curl từ một máy có quyền truy cập mạng đến cluster. Ví dụ, Apptio minh họa lệnh curl -i https://darwin-app:443/darwin-probes hoặc dùng IP và nodePort khi chưa có DNS, cho phép quan sát trực tiếp mã trạng thái HTTP, header và nội dung trả về từ endpoint health, từ đó so khớp với hành vi mà kubelet mong đợi.

Bước 5: Kiểm tra Endpoints và trạng thái routing của Service

Khi readiness probe dùng HTTPS được cấu hình, bạn có thể theo dõi việc Pod được thêm/bớt khỏi Endpoints bằng lệnh kubectl get endpoints -w. Lệnh này hiển thị danh sách IP:port của Pod gắn với Service; nếu readiness probe fail, Endpoints có thể tạm thời là <none> và khi probe pass, dòng Endpoints sẽ xuất hiện trở lại với địa chỉ Pod, chứng minh rằng cơ chế health check đang kiểm soát tuyến traffic đúng như kỳ vọng.

Bước 6: Kết hợp log ứng dụng, log probe và công cụ dòng lệnh để debug

Cuối cùng, khi phát hiện probe liên tục thất bại hoặc Pod không vào Endpoints như mong muốn, bạn có thể dùng kubectl logs <pod_name> để xem log ứng dụng và so sánh với thời điểm lỗi trong kubectl describe pod. Kết hợp thêm việc gọi lại endpoint HTTPS bằng curl (cùng URL mà probe sử dụng) giúp xác định lỗi nằm ở chứng chỉ, đường dẫn, port, logic health hoặc ở cấu hình probe, từ đó điều chỉnh manifest và ứng dụng.

Vietnix – Nền tảng Enterprise Cloud vững chắc cho hạ tầng Kubernetes chuyên nghiệp

Với những hệ thống Kubernetes đòi hỏi tính sẵn sàng cao, autoscaling liên tục và lưu lượng biến động mạnh, việc vận hành trên một nền tảng Enterprise Cloud ổn định, hiệu năng tốt sẽ giúp các cơ chế health check phát huy tối đa hiệu quả, hạn chế tối đa tình trạng pod bị fail do nghẽn tài nguyên hạ tầng. Nhờ cụm tài nguyên riêng, khả năng mở rộng linh hoạt và kiến trúc tối ưu cho workload container hóa, Vietnix giúp đội ngũ DevOps chủ động hơn trong việc thiết kế, thử nghiệm và tinh chỉnh cấu hình liveness/readiness/startup probe cho các cụm Kubernetes ở mọi môi trường.

Thông tin liên hệ:

• Website: https://vietnix.vn/
• Hotline: 1800 1093
• Email: sales@vietnix.com.vn
• Địa chỉ: 265 Hồng Lạc, Phường Bảy Hiền, Thành Phố Hồ Chí Minh

Health check K8s là một cơ chế không thể thiếu để xây dựng các ứng dụng có khả năng tự phục hồi và tính sẵn sàng cao. Việc hiểu rõ cách thức hoạt động, cấu hình và kết hợp hợp lý các loại probe sẽ là chìa khóa để quản trị viên và nhà phát triển tối ưu hóa sự ổn định, độ tin cậy và hiệu suất của các ứng dụng trong môi trường Cloud Native.