Kubernetes: health checks with Liveness, Readiness, and Startup probes

The three kinds of probe: Liveness, Readiness, and Startup probes

Kubernetes (since version 1.16) has three types of probe, which are used for three different purposes:

  • Liveness probe. This is for detecting whether the application process has crashed/deadlocked. If a liveness probe fails, Kubernetes will stop the pod, and create a new one.
  • Readiness probe. This is for detecting whether the application is ready to handle requests. If a readiness probe fails, Kubernetes will leave the pod running, but won't send any requests to the pod.
  • Startup probe. This is used when the container starts up, to indicate that it's ready. Once the startup probe succeeds, Kubernetes switches to using the liveness probe to determine if the application is alive. This probe was introduced in Kubernetes version 1.16.

Source: Andrew Lock

Cài đặt chính xác phiên bản kubectl client

Với hệ thống Kubernetes, bạn cần sử dụng kubectl client không khác quá 1 phiên bản minor với phía server, ví dụ:

  • kube-apiserver sử dụng version 1.21
  • kubectl client có thể sử dụng version: 1.21, 1.20 (cũ hơn 1 version), 1.22 (mới hơn 1 version)

reference

Trường hợp sử dụng version không theo khuyến cáo, lệnh kubectl version trả về kết quả kèm theo cảnh báo:

...
WARNING: version difference between client (1.24) and server (1.21) exceeds the supported minor version skew of +/-1

Migrating your ingresses to K3s 1.20+ API format

Source: https://www.civo.com/learn/migrating-your-ingresses-in-k3s-1-20

Kubernetes version 1.20+ introduces the networking.k8s.io API version as stable. If you have ingresses that predate K3S 1.20, you have until Kubernetes 1.22 to update them. Until then, if you use old-style ingress definitions, you will receive a warning like Warning: networking.k8s.io/v1beta1 Ingress is deprecated in v1.19+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress when you apply the ingress to a cluster.

What is the difference between |+ and |- when creating a configmap from a file in kubernetes yaml definitions? (block chomping indicator)

first one

apiVersion: v1
data:
  file1.yaml: |+
    parameter1=value1
kind: ConfigMap
metadata:
  name: my-configmap

second one

apiVersion: v1
data:
  file1.yaml: |-
    parameter1=value1
kind: ConfigMap
metadata:
  name: my-configmap

what is the difference between |+ and |- ?

Comparing Ingress controllers for Kubernetes