1前書き

このチュートリアルでは、https://kubernetes.io/[

Kubernetes

]のhttps://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/について説明します。[

プローブ

]そして

Actuator





HealthIndicator


を利用する方法を説明]

アプリケーションの状態を正確に把握するため。

このチュートリアルの目的のために、https://www.baeldung.com/spring-boot-actuators[

Spring


Boot


Actuator

]、https://www.baeldung.com/を使用して、以前からの経験を前提とします。 kubernetes[

Kubernetes

]、およびhttps://www.baeldung.com/dockerizing-spring-boot-application[

Docker

]。


2 Kubernetes


プローブ


Kubernetes

は、すべてが期待通りに機能しているかどうかを定期的にチェックするために使用できる2つの異なるプローブを定義します。


2.1. 活力


および


準備


  • Liveness

    および

    Readiness

    プローブを使用すると、https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/[

    Kubelet

    ]は、何かがオフになったことを検出してアプリケーションのダウンタイムを最小限に抑えるとすぐに機能します。 **

どちらも同じように設定されていますが、意味は異なり、

Kubelet

はどちらがトリガーされたかによって異なるアクションを実行します。


  • Readiness



    Readiness

    は、

    Pod

    が開始する準備ができているかどうかを確認します

トラフィックを受信して​​います。私たちの

Pod

は、そのコンテナがすべて揃ったら準備ができています
準備ができて
**

Liveness



readiness

とは反対に、

liveness

は私たちの

Pod

かどうかをチェックします

再起動する必要があります。アプリケーションが実行されていても、処理を進めることができない状態にあるというユースケースを拾うことができます。例えば、それは行き詰まりです

両方のプローブタイプをコンテナレベルで設定します。

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
      timeoutSeconds: 2
      failureThreshold: 1
      successThreshold: 1
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20
      timeoutSeconds: 2
      failureThreshold: 1
      successThreshold: 1

プローブの動作をより正確に制御するために設定できるフィールドがいくつかあります。


  • initialDelaySeconds

    – コンテナを作成した後、** wait

プローブを開始する前の


_n






periodSeconds_



このプローブが実行される頻度

、デフォルトでは

10秒;最小は1秒です


timeoutSeconds



プローブをタイムアウトさせるまでの** 待ち時間

デフォルトは1秒です。最小値は1秒です


failureThreshold

– あきらめる前に


n

回試してください** 。その場合

私たちのポッドは準備ができていないとしてマークされます

liveness

の場合は

Pod

を再起動することを意味します。デフォルトは3です。
失敗数、最小値は1


successThreshold

– これは

連続する最小数です

  • が失敗した後、プローブが成功したと見なされるために成功します。デフォルトは1で、最小値も1です。

この場合、私たちは

tcp

プローブを選びました。** しかし、私たちが使用できる他の種類のプローブもあります。


2.2. プローブ

T

ypes

私たちの使用例によっては、あるプローブタイプが他のものよりも有用であることが証明されるかもしれません。たとえば、コンテナがWebサーバーの場合、

http

プローブを使用する方が

tcp

プローブより信頼性が高い可能性があります。

幸い、

Kubernetes

には3種類のプローブがあります。


  • exec



    コンテナ内の

    bash

    命令を実行します

    。にとって

たとえば、特定のファイルが存在することを確認してください。命令が
失敗コード、プローブは失敗
**

tcpSocket

– コンテナへの

tcp

接続の確立を試みます。

指定されたポート

を使用します。接続に失敗した場合は、
プローブが失敗する


httpGet



実行中のサーバーにHTTP GET要求を送信します

コンテナ内で指定されたポートで待機しています。 200以上400未満のコードはすべて成功を示します


HTTP

プローブには、前述した以外にも追加のフィールドがあります。



  • host


    – 接続するホスト名。デフォルトはポッドのIPです。



  • scheme


    – 接続に使用するスキーム、

    HTTP

    または

    HTTPS

デフォルトは

HTTP

です



path

** – Webサーバー上でアクセスするためのパス



  • httpHeaders


    – リクエストに設定するカスタムヘッダ



  • port


    – コンテナ内でアクセスするポートの名前または番号


3 Spring


アクチュエーター


および


Kubernetes


自己修復


機能

アプリケーションが壊れた状態にあるかどうかを

Kubernetes

がどのように検出できるかについての一般的な概念が得られたので、次のことを見てみましょう。私たちのアプリケーションだけでなく、その依存関係にも注目してください。

これらの例では、https://www.baeldung.com/spring-boot-minikube[

Minikube

]を使用します。

3.1. アクチュエータとその

__HealthIndicator

__s


Kubernetes

のプローブに対する私たちのアプリケーションの依存関係のいくつかの状態を反映して、Springにはいくつかの


_HealthIndicatorの使用準備ができていることを考えると、https://www.baeldung.com/spring-boot-actuators[

Actuator

]を追加するのと同じくらい簡単です。

pom.xmlへの依存関係:_

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>


3.2. 活気の例

正常に起動するアプリケーションから始めましょう。


30



の後に






































)に

表示**


https://www.baeldung.com/spring-boot-

actuators[

HealthIndicator

]を作成して

boolean

変数が

true

であるかどうかを検証することで、壊れた状態をエミュレートします。

変数を

true

に初期化してから、30秒後に

false

に変更するタスクをスケジュールします。

@Component
public class CustomHealthIndicator implements HealthIndicator {

    private boolean isHealthy = true;

    public CustomHealthIndicator() {
        ScheduledExecutorService scheduled =
          Executors.newSingleThreadScheduledExecutor();
        scheduled.schedule(() -> {
            isHealthy = false;
        }, 30, TimeUnit.SECONDS);
    }

    @Override
    public Health health() {
        return isHealthy ? Health.up().build() : Health.down().build();
    }
}


HealthIndicator

が設定されたら、アプリケーションをドッキングする必要があります。

FROM openjdk:8-jdk-alpine
RUN mkdir -p/usr/opt/service
COPY target/** .jar/usr/opt/service/service.jar
EXPOSE 8080
ENTRYPOINT exec java -jar/usr/opt/service/service.jar

次に、

Kubernetes

テンプレートを作成します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: liveness-example
spec:
  ...
    spec:
      containers:
      - name: liveness-example
        image: dbdock/liveness-example:1.0.0
        ...
        readinessProbe:
          httpGet:
            path:/health
            port: 8080
          initialDelaySeconds: 10
          timeoutSeconds: 2
          periodSeconds: 3
          failureThreshold: 1
        livenessProbe:
          httpGet:
            path:/health
            port: 8080
          initialDelaySeconds: 20
          timeoutSeconds: 2
          periodSeconds: 8
          failureThreshold: 1

  • Actuatorのヘルスエンドポイントを指す

    httpGet

    プローブを使用しています** アプリケーションの状態(およびその依存関係)が変更された場合は、展開の健全性に反映されます。

アプリケーションを

Kubernetes

にデプロイすると、両方のプローブが動作していることがわかります。約30秒後に、

Pod

が未読としてマークされ、ローテーションから削除されます。数秒後、

Pod

が再起動されます。


Pod



kubectl


describe


pod


liveness-example

を実行しているイベントを確認できます。

Warning  Unhealthy 3s (x2 over 7s)   kubelet, minikube  Readiness probe failed: HTTP probe failed ...
Warning  Unhealthy 1s                kubelet, minikube  Liveness probe failed: HTTP probe failed ...
Normal   Killing   0s                kubelet, minikube  Killing container with id ...


3.3. レディネスの例

前の例では、アプリケーションの状態を

Kubernetes

デプロイメントの健全性に反映させるために

HealthIndicator

をどのように使用できるかを説明しました。

別のユースケースでそれを使ってみましょう:私たちのアプリケーションが








トラフィックを

受け取る



前に


time









を** 必要とすると仮定します。たとえば、ファイルをメモリにロードしてその内容を検証する必要があります。

これは

readiness

プローブを利用できるときの良い例です。

前の例の

HealthIndicator

テンプレートと

Kubernetes

テンプレートを変更し、それらを次のユースケースに適応させます。

@Component
public class CustomHealthIndicator implements HealthIndicator {

    private boolean isHealthy = false;

    public CustomHealthIndicator() {
        ScheduledExecutorService scheduled =
          Executors.newSingleThreadScheduledExecutor();
        scheduled.schedule(() -> {
            isHealthy = true;
        }, 40, TimeUnit.SECONDS);
    }

    @Override
    public Health health() {
        return isHealthy ? Health.up().build() : Health.down().build();
    }
}

変数を

false

に初期化し、40秒後にタスクが実行されて

true.

に設定されます。

次に、次のテンプレートを使用してアプリケーションをドッキングしてデプロイします。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: readiness-example
spec:
  ...
    spec:
      containers:
      - name: readiness-example
        image: dbdock/readiness-example:1.0.0
        ...
        readinessProbe:
          httpGet:
            path:/health
            port: 8080
          initialDelaySeconds: 40
          timeoutSeconds: 2
          periodSeconds: 3
          failureThreshold: 2
        livenessProbe:
          httpGet:
            path:/health
            port: 8080
          initialDelaySeconds: 100
          timeoutSeconds: 2
          periodSeconds: 8
          failureThreshold: 1

似ていますが、プローブの設定にはいくつかの変更点があります。

  • 私たちのアプリケーションは、アプリケーションが

トラフィックを受信する準備が整いましたので、


initialDelaySeconds


を増やしました。
40秒まで

私たちの


readiness


プローブ

同様に、


initialDelaySeconds


を増やしました。


Kubernetes

によって時期尚早に殺されるのを避けるために、私たちの


liveness


は100秒まで調べ

40秒経ってもまだ終了しない場合は、約60秒で終了します。その後、

liveness

プローブが__Podを起動して再起動します。


4結論

この記事では、

Kubernetes

プローブと、Springの

Actuator

を使用してアプリケーションの状態監視を改善する方法について説明しました。

これらの例の完全な実装はhttps://github.com/eugenp/tutorials/tree/master/spring-cloud/spring-cloud-kubernetes[Githubに掲載]をご覧ください。