Skip to content

NimTechnology

Trình bày các công nghệ CLOUD một cách dễ hiểu.

  • Kubernetes & Container
    • Docker
    • Kubernetes
      • Ingress
      • Pod
    • Helm Chart
    • OAuth2 Proxy
    • Isito-EnvoyFilter
    • Apache Kafka
      • Kafka
      • Kafka Connect
      • Lenses
    • Vault
    • Longhorn – Storage
    • VictoriaMetrics
    • MetalLB
    • Kong Gateway
  • CI/CD
    • ArgoCD
    • ArgoWorkflows
    • Argo Events
    • Spinnaker
    • Jenkins
    • Harbor
    • TeamCity
    • Git
      • Bitbucket
  • Coding
    • DevSecOps
    • Terraform
      • GCP – Google Cloud
      • AWS – Amazon Web Service
      • Azure Cloud
    • Golang
    • Laravel
    • Python
    • Jquery & JavaScript
    • Selenium
  • Log, Monitor & Tracing
    • DataDog
    • Prometheus
    • Grafana
    • ELK
      • Kibana
      • Logstash
  • BareMetal
    • NextCloud
  • Toggle search form

[Kubernetes] Discover Health Check on K8s

Posted on April 26, 2023October 18, 2023 By nim No Comments on [Kubernetes] Discover Health Check on K8s

Contents

Toggle
  • Readiness
  • Liveness
    • HTTP Get
    • TCP Socket
    • Exec
      • Real example:
  • Startup

Readiness

Readiness configuration in Kubernetes is used to determine if a container within a pod is ready to accept traffic or serve requests. It ensures that a container is fully initialized and capable of handling requests before being exposed to any incoming traffic. This helps maintain the overall health and reliability of your application.

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

Điều quan trong là readiness không restart pod. Nó sẽ nhả error rất nhiều trong event của pod.

Liveness

Liveness configuration is used to ensure that the containers within a pod are running and healthy.
If a container is unresponsive or unhealthy, Kubernetes can automatically restart it

the following 3 methods:

HTTP Get

a. HTTP Get: The probe sends an HTTP GET request to a specified path and port on the container. If the container returns a status code between 200 and 399, it is considered alive.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 10
  timeoutSeconds: 5
  successThreshold: 1
  failureThreshold: 5

In this example, the livenessProbe field is configured with an httpGet probe. The probe sends an HTTP GET request to the /healthz path on port 8080 of the container.

+ initialDelaySeconds: Khi pod đã start được 15s thì health-check/probe livenessProbe sẽ bắt đầu kiểm tra
+ periodSeconds: health-check sẽ kiểm tra liên tục với interval/every 10s
+ timeoutSeconds: nghĩa là khi health check gửi tín hiện đi thì nó expect là trong 5s sẽ nhận lại kết quả. Nếu quá 5s mà chưa có kết quá thì it will be considered a failure. The default value is 1 second
+ successThreshold: Trước đó nó đã failed, lần tiếp theo check thì nó là success nó căn cứ bào giá trị là bao nhiêu. Nếu successThreshold: 2 thì nó cần 2 lần success liên tiếp thì nó xem sét pod đó là running.
+ failureThreshold: trước đó pod đang running thì lần check tiếp theo là failed thì nó cân cứ vào giá trị. failureThreshold: 5. nếu fail 5 lần liên tiếp thì Kubernetes will take action, such as restarting the container.

TCP Socket

b. TCP Socket: The probe tries to establish a TCP connection to a specified port on the container. If the connection is established successfully, the container is considered alive.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-tcp-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sample-tcp-app
  template:
    metadata:
      labels:
        app: sample-tcp-app
    spec:
      containers:
      - name: tcp-app-container
        image: your-tcp-app-image:latest
        ports:
        - containerPort: 8080
        livenessProbe:
          tcpSocket:
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 10

Exec

c. Exec: The probe executes a command inside the container. If the command returns a 0 exit status, the container is considered alive.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-exec-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sample-exec-app
  template:
    metadata:
      labels:
        app: sample-exec-app
    spec:
      containers:
      - name: exec-app-container
        image: your-exec-app-image:latest
        livenessProbe:
          exec:
            command:
            - /bin/sh
            - -c
            - 'touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600'
          initialDelaySeconds: 5
          periodSeconds: 10

Với ví dụ trên thì bạn sẽ thấy container sẽ restart liên tục vì:
There’s a potential issue with the liveness probe in this configuration. The command in the liveness probe creates a file, waits for a bit, and then removes the file, but there’s no actual check for the application’s health. Plus, after the file is deleted, the container will sleep for 600 seconds before the next loop, but the probe interval is only 10 seconds (periodSeconds: 10), which means Kubernetes will likely consider the application to be unhealthy after the file is deleted and before the next cycle of the command. This can result in the container being restarted unnecessarily.

Real example:

Các pods sẽ sử dụng chung 1 persistent volume.
Bài toán đặt ra là mình sẽ liên tục check xem pod có mount được xuống PV hay không.


Tạo 1 file tự xuống volume và xóa.

 ####         
          livenessProbe:
            exec:
              command:
                - /bin/sh
                - '-c'
                - 'touch /app/downloaded/healthy; sleep 1; rm -rf /app/downloaded/healthy; sleep 1'
            failureThreshold: 3
            initialDelaySeconds: 5
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 5

Dùng command “test -d” để test folder

          livenessProbe:
            exec:
              command:
                - /bin/sh
                - '-c'
                - test -d /app/downloaded || exit 1
            failureThreshold: 3
            initialDelaySeconds: 5
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 5

Startup

Cài này dùng khá là ít

Startup probes in Kubernetes are used to check if a container within a pod has successfully started and is ready to perform its primary functions. It is particularly useful for slow-starting containers or applications that require a significant amount of time for initialization. Startup probes help Kubernetes determine when the container has successfully started, without impacting liveness or readiness probes.

startupProbe:
  httpGet:
    path: /startup
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 30
  • It is used to indicate if the application inside the Container has started.
  • If a startup probe is provided, all other probes are disabled.
  • Once the startup probe has succeeded once, the liveness probe takes over to provide a fast response to container deadlocks.
  • In the given example, if the request fails, it will restart the container.
  • If not provided the default state is Success.
Kubernetes

Post navigation

Previous Post: [Fluent Bit / Datadog] How does Fluent bit collect logs and send them to multiple backend.
Next Post: [Kubernetes] Don’t believe kubectl top

More Related Articles

[Metrics Server] Failed to make webhook authorizer request: the server could not find the requested resource Kubernetes
[Kubernetes] How to delete POD is Terminating and very stubborn Kubernetes
[Kubernetes] RBAC Demo Kubernetes
[KOS] Use KOS to install kubernetes so easily! Kubernetes
[Vault] Using Service Acount of Kubernetes to login Vault system. Kubernetes
[HPA/Kubernetes] Scale Up As Usual, Scale Down Very Gradually – behavior in HPA K8s Kubernetes

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Tham Gia Group DevOps nhé!
Để Nim có nhiều động lực ra nhiều bài viết.
Để nhận được những thông báo mới nhất.

Recent Posts

  • [Laravel] Laravel Helpful June 26, 2025
  • [VScode] Hướng dẫn điều chỉnh font cho terminal June 20, 2025
  • [WordPress] Hướng dấn gửi mail trên WordPress thông qua gmail. June 15, 2025
  • [Bitbucket] Git Clone/Pull/Push with Bitbucket through API Token. June 12, 2025
  • [Teamcity] How to transfer the value from pipeline A to pipeline B June 9, 2025

Archives

  • June 2025
  • May 2025
  • April 2025
  • March 2025
  • February 2025
  • January 2025
  • December 2024
  • November 2024
  • October 2024
  • September 2024
  • August 2024
  • July 2024
  • June 2024
  • May 2024
  • April 2024
  • March 2024
  • February 2024
  • January 2024
  • December 2023
  • November 2023
  • October 2023
  • September 2023
  • August 2023
  • July 2023
  • June 2023
  • May 2023
  • April 2023
  • March 2023
  • February 2023
  • January 2023
  • December 2022
  • November 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021

Categories

  • BareMetal
    • NextCloud
  • CI/CD
    • Argo Events
    • ArgoCD
    • ArgoWorkflows
    • Git
      • Bitbucket
    • Harbor
    • Jenkins
    • Spinnaker
    • TeamCity
  • Coding
    • DevSecOps
    • Golang
    • Jquery & JavaScript
    • Laravel
    • NextJS 14 & ReactJS & Type Script
    • Python
    • Selenium
    • Terraform
      • AWS – Amazon Web Service
      • Azure Cloud
      • GCP – Google Cloud
  • Kubernetes & Container
    • Apache Kafka
      • Kafka
      • Kafka Connect
      • Lenses
    • Docker
    • Helm Chart
    • Isito-EnvoyFilter
    • Kong Gateway
    • Kubernetes
      • Ingress
      • Pod
    • Longhorn – Storage
    • MetalLB
    • OAuth2 Proxy
    • Vault
    • VictoriaMetrics
  • Log, Monitor & Tracing
    • DataDog
    • ELK
      • Kibana
      • Logstash
    • Fluent
    • Grafana
    • Prometheus
  • Uncategorized
  • Admin

Copyright © 2025 NimTechnology.