`PropertySource` リロード

この機能は、2020.0 リリースでは非推奨になりました。同じ機能を実現する別の方法については、Spring Cloud Kubernetes 構成ウォッチャーコントローラーを参照してください。

一部のアプリケーションでは、外部プロパティソースの変更を検出し、新しい構成を反映するために内部ステータスを更新する必要がある場合があります。Spring Cloud Kubernetes のリロード機能は、関連する ConfigMap または Secret が変更されたときにアプリケーションのリロードをトリガーできます。

デフォルトでは、この機能は無効になっています。これを有効にするには、spring.cloud.kubernetes.reload.enabled=true 構成プロパティ (たとえば、application.properties ファイル内) を使用します。これにより、configmap の監視のみが有効になることに注意してください (つまり、spring.cloud.kubernetes.reload.monitoring-config-maps が true に設定されます)。シークレットの監視を有効にしたい場合は、spring.cloud.kubernetes.reload.monitoring-secrets=true を介して明示的に行う必要があります。

次のレベルのリロードがサポートされています (spring.cloud.kubernetes.reload.strategy プロパティを設定することにより)。

refresh (default): @ConfigurationProperties または @RefreshScope のアノテーションが付けられた構成 Bean のみがリロードされます。このリロードレベルは、Spring Cloud Context のリフレッシュ機能を利用します。
restart_context: Spring ApplicationContext 全体が正常に再起動されます。Bean は新しい構成で再作成されます。再起動コンテキスト機能が適切に動作するには、再起動アクチュエーターエンドポイントを有効にして公開する必要があります。

management:
  endpoint:
    restart:
      enabled: true
  endpoints:
    web:
      exposure:
        include: restart

shutdown: Spring ApplicationContext はコンテナーの再起動をアクティブにするためにシャットダウンされます。このレベルを使用する場合は、すべての非デーモンスレッドのライフサイクルが ApplicationContext にバインドされていること、およびレプリケーションコントローラーまたはレプリカセットが pod を再起動するように構成されていることを確認してください。

リロード機能がデフォルト設定 (refresh モード) で有効になっていると仮定すると、構成マップが変更されると、次の Bean がリフレッシュされます。

@Configuration
@ConfigurationProperties(prefix = "bean")
public class MyConfig {

    private String message = "a message that can be changed live";

    // getter and setters

}

変更が効果的に行われたことを確認するには、次のようにメッセージを定期的に出力する別の Bean を作成します。

@Component
public class MyBean {

    @Autowired
    private MyConfig config;

    @Scheduled(fixedDelay = 5000)
    public void hello() {
        System.out.println("The message is: " + config.getMessage());
    }
}

次のように、ConfigMap を使用して、アプリケーションによって出力されるメッセージを変更できます。

apiVersion: v1
kind: ConfigMap
metadata:
  name: reload-example
data:
  application.properties: |-
    bean.message=Hello World!

pod に関連付けられた ConfigMap 内の bean.message という名前のプロパティへの変更は、出力に反映されます。より一般的に言えば、@ConfigurationProperties アノテーションの prefix フィールドによって定義された値が接頭辞として付けられたプロパティに関連する変更が検出され、アプリケーションに反映されます。ConfigMap と pod の関連付けについては、この章の前半で説明しています。

リロード機能は 2 つの動作モードをサポートしています。

イベント (default): Kubernetes API (Web ソケット) を使用して、構成マップまたはシークレットの変更を監視します。どのイベントでも構成が再チェックされ、変更があった場合はリロードが行われます。構成マップの変更をリッスンするには、サービスアカウントの view ロールが必要です。シークレットには、より高いレベルのロール ( edit など) が必要です (デフォルトでは、シークレットは監視されません)。
ポーリング: 構成マップとシークレットから構成を定期的に再作成し、変更されたかどうかを確認します。ポーリング期間は spring.cloud.kubernetes.reload.period プロパティを使用して構成でき、デフォルトは 15 秒です。監視対象プロパティソースと同じロールが必要です。これは、たとえば、ファイルにマウントされたシークレットソースでのポーリングの使用には特定の権限が必要ないことを意味します。

PropertySource リロード

`PropertySource` リロード