2

kubernetes にデプロイされたアプリケーションがあります。これがtechstackです： Java 11、Spring Boot 2.3.xまたは2.5.x、hikari 3.xまたは4.xを使用

スプリング アクチュエータを使用してヘルスチェックを行います。application.yaml 内livenessの構成は次のとおりです。readiness

  endpoint:
    health:
      group:
        liveness:
          include: '*'
          exclude:
            - db
            - readinessState
        readiness:
          include: '*'

DBがダウンした場合の動作 -

  1. 影響を受けないようlivenessにします。つまり、DB が停止しても、アプリケーション コンテナーは実行し続ける必要があります。
  2. readinesssトラフィックがコンテナーにヒットしないようにします。

livenessおよびreadinessコンテナ仕様の構成:

livenessProbe:
  httpGet:
      path: actuator/health/liveness
      port: 8443
      scheme: HTTPS
  initialDelaySeconds: 30
  periodSeconds: 30
  timeoutSeconds: 5
readinessProbe:
  httpGet:
      path: actuator/health/readiness
      port: 8443
      scheme: HTTPS
  initialDelaySeconds: 30
  periodSeconds: 30
  timeoutSeconds: 20

アプリケーションが開始され、数時間正常に実行されます。

私がしたこと：

DBをダウンさせました。

指摘された問題:

DB がダウンしている場合、90 秒以上経過すると、さらに 3 つのポッドがスピンアップします。ポッドが記述されると、次のようなステータスと状態が表示されます。

Status:       Running
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True

実行中のすべてのポッドを一覧表示すると:

NAME                                                  READY   STATUS    RESTARTS   AGE
application-a-dev-deployment-success-5d86b4bcf4-7lsqx    0/1     Running   0          6h48m
application-a-dev-deployment-success-5d86b4bcf4-cmwd7    0/1     Running   0          49m
application-a-dev-deployment-success-5d86b4bcf4-flf7r    0/1     Running   0          48m
application-a-dev-deployment-success-5d86b4bcf4-m5nk7    0/1     Running   0          6h48m
application-a-dev-deployment-success-5d86b4bcf4-tx4rl    0/1     Running   0          49m

私の類推/発見:

構成ごとReadinessProbe:periodSecondsは 30 秒に設定され、failurethresholdk8s ドキュメントごとにデフォルトで 3 に設定されています。

application.yaml ごとreadinessに db チェックが含まれています。これは、30 秒ごとにreadinessチェックが失敗したことを意味します。3回失敗すると、failurethreshold満たされ、新しいポッドがスピンアップします。

再起動ポリシーは、デフォルトで Always に設定されています。

質問:

  1. なぜ新しいポッドを回転させたのですか?
  2. 1 つ、2 つ、4 つ、または任意の数ではなく、具体的に 3 つのポッドのみを回転させたのはなぜですか?
  3. これは何か関係がありrestartpolicyますか？
4

2 に答える 2

1
  1. あなたが自分自身に答えたように、それは に従って 3 回試行した後、新しいポッドをスピンしましたfailureThreshold。に変更できます。これrestartPolicyにより、ジョブが失敗した場合、またはクラスターを再起動したくない場合OnFailureにのみ、ジョブを再起動できます。ここでNever見つけることができるステータスの違い。これに注意してください：

restartPolicyはPod 内のすべてのコンテナーに適用されます。restartPolicyは、同じノード上のkubelet によるコンテナの再起動のみを参照します。Pod 内のコンテナーが終了した後、kubelet は指数関数的なバックオフ遅延 (10 秒、20 秒、40 秒、…) でコンテナーを再起動します。これは 5 分に制限されています。コンテナが問題なく 10 分間実行されると、kubelet はそのコンテナの再起動バックオフ タイマーをリセットします。

  1. Deploymentファイル全体を共有してください。replicas番号を に設定したと思います3。

  2. 1番目の質問の回答で回答しました。

これがうまくいく場合は、これにも注意してください。

起動プローブは、サービスが開始されるまでに時間がかかるコンテナを持つ Pod に役立ちます。長い活性間隔を設定するのではなく、コンテナーの起動時にコンテナーをプローブするための別の構成を構成して、活性間隔よりも長い時間を許可することができます。

通常、コンテナが initialDelaySeconds + failureThreshold × periodSeconds よりも長く開始する場合は、liveness プローブと同じエンドポイントをチェックするスタートアップ プローブを指定する必要があります。periodSeconds のデフォルトは 10 秒です。次に、liveness プローブのデフォルト値を変更せずに、コンテナを起動できるように十分に高い値に failureThreshold を設定する必要があります。これは、デッドロックを防ぐのに役立ちます。

于 2021-11-30T20:20:17.893 に答える