レディネスプローブ

新しいポッドが作成されると、サービスはすぐにそれを選択してリクエストをポッドに転送できます。その後、問題が発生します。通常、ポッドの開始には時間がかかります。ポッドの準備ができていない場合（構成の読み込みに時間がかかる場合があります）またはデータ、またはウォームアップ手順などを実行する必要がある場合があります。この時点でリクエストがポッドに転送されると、ポッドはそれを処理できず、リクエストは失敗します。

Kubernetesがこの問題を解決する方法は、ビジネス準備プローブをポッドに追加し、ポッドの準備ができたことを検出した場合にのみ、サービスが要求をポッドに転送できるようにすることです。

レディネスプローブも定期的にポッドを検出し、応答に基づいてポッドの準備ができているかどうかを判断します。ライブネスプローブと同様に、レディネスプローブも次の3つのタイプをサポートします。

Exec：プローブはコンテナ内のコマンドを実行し、コマンド出口のステータスコードをチェックします。ステータスコードが0の場合、準備ができています。
HTTP GET：HTTP GETリクエストをコンテナのIP：Portに送信します。プローブが2xxまたは3xxを受信すると、準備が整います。
TCPソケット：コンテナとのTCP接続を確立しようとします。接続を確立できる場合は、準備ができています。

レディネスプローブのしくみ

レディネスプローブの効果は、エンドポイントを介して実現できます。ポッドの準備ができていない場合は、次の図に示すように、ポッドのIP：ポートをエンドポイントから削除し、準備ができたらポッドをエンドポイントに追加します。

図1レディネスプローブの実現原理

レディネスプローブ

Exec

ExecメソッドはHTTPGETメソッドと一貫性があります。以下に示すように、このプローブはls / readyコマンドを実行します。ファイルが存在する場合は0を返し、ポッドの準備ができていることを示します。存在しない場合は、他のステータスコードを返します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:alpine
        name: container-0
        resources:
          limits:
            cpu: 100m
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        readinessProbe:      # Readiness Probe
          exec:              # 定义 ls /ready 命令
            command:
            - ls
            - /ready
      imagePullSecrets:
      - name: default-secret

上記のデプロイメントの定義をdeploy-read.yamlファイルに保存し、以前に作成したデプロイメントを削除し、deploy-read.yamlを使用してこのデプロイメントを作成します。

# kubectl delete deploy nginx
deployment.apps "nginx" deleted

# kubectl create -f deploy-read.yaml
deployment.apps/nginx created

ここで、nginxイメージには/ readyファイルが含まれていないため、以下に示すように、作成が完了した後、コンテナはReady状態になりません。READY列の値が0/1であることに注意してください。これは、コンテナがReadyではないことを意味します。

# kubectl get po
NAME                     READY     STATUS    RESTARTS   AGE
nginx-7955fd7786-686hp   0/1       Running   0          7s
nginx-7955fd7786-9tgwq   0/1       Running   0          7s
nginx-7955fd7786-bqsbj   0/1       Running   0          7s

サービスを作成します。

apiVersion: v1
kind: Service
metadata:
  name: nginx        
spec:
  selector:          
    app: nginx
  ports:
  - name: service0
    targetPort: 80   
    port: 8080       
    protocol: TCP    
  type: ClusterIP

サービスを見ると、エンドポイント行の値が空であり、エンドポイントがないことを示しています。

$ kubectl describe svc nginx
Name:              nginx
......
Endpoints:         
......

この時点でコンテナに/ readyファイルを作成し、Readiness Probeを成功させると、コンテナはReady状態になります。ポッドとエンドポイントをもう一度見ると、/ readyファイルが作成されたコンテナがReadyであり、エンドポイントも追加されていることがわかりました。

# kubectl exec nginx-7955fd7786-686hp -- touch /ready

# kubectl get po -o wide
NAME                     READY     STATUS    RESTARTS   AGE       IP
nginx-7955fd7786-686hp   1/1       Running   0          10m       192.168.93.169 
nginx-7955fd7786-9tgwq   0/1       Running   0          10m       192.168.166.130
nginx-7955fd7786-bqsbj   0/1       Running   0          10m       192.168.252.160

# kubectl get endpoints
NAME       ENDPOINTS           AGE
nginx      192.168.93.169:80   14d

HTTPGET

レディネスプローブの構成は、リビネスプローブと同じで、ポッドテンプレートのコンテナ内にあります。以下に示すように、このレディネスプローブは、ポッドにHTTPリクエストを送信します。プローブが2xxまたは3xxを受信すると、ポッドの準備ができていることを意味します。。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:alpine
        name: container-0
        resources:
          limits:
            cpu: 100m
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        readinessProbe:           # readinessProbe
          httpGet:                # HTTP GET定义
            path: /read
            port: 80
      imagePullSecrets:
      - name: default-secret

TCPソケット

同様に、TCPソケットタイプのプローブを以下に示します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:alpine
        name: container-0
        resources:
          limits:
            cpu: 100m
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        readinessProbe:             # readinessProbe
          tcpSocket:                # TCP Socket定义
            port: 80
      imagePullSecrets:
      - name: default-secret

レディネスプローブの高度な構成

Liveness Probeと同様に、ReadinessProbeにも同じ高度な構成オプションがあります。上記のnginxポッドのdescribeコマンドには、エコーに次の行があります。

Readiness: exec [ls /var/ready] delay=0s timeout=1s period=10s #success=1 #failure=3

この行は、Readiness Probeの特定のパラメーター構成を表しており、その意味は次のとおりです。

delay = 0sは、コンテナが開始された直後に検出が開始されることを意味し、遅延時間はありません
timeout = 1sは、コンテナが1秒以内にプローブに対応するフィードバックを行う必要があることを意味します。そうでない場合、検出の失敗と見なされます。
period = 10sは、10秒ごとに1回検出することを意味します
＃success = 1は、検出が1回連続して成功したことを意味し、成功を示します
＃failure = 3は、プローブが3回連続して失敗した後、コンテナが再起動されることを意味し
ます。これらは作成時のデフォルト設定であり、以下に示すように手動で構成することもできます。

        readinessProbe:      # Readiness Probe
          exec:              # 定义 ls /readiness/ready 命令
            command:
            - ls
            - /readiness/ready
          initialDelaySeconds: 10    # 容器启动后多久开始探测
          timeoutSeconds: 2          # 表示容器必须在2s内做出相应反馈给probe，否则视为探测失败
          periodSeconds: 30          # 探测周期，每30s探测一次
          successThreshold: 1        # 连续探测1次成功表示成功
          failureThreshold: 3        # 连续探测3次失败表示失败

レディネスプローブのしくみ

Exec

HTTPGET

TCPソケット

レディネスプローブの高度な構成

おすすめ