DevOpsナレッジハブ
DevOpsナレッジハブ

動的な設定管理: ConfigMaps を使用したリアルタイムアプリケーション更新

Kubernetes で、ボリュームとしてマウントされた ConfigMaps を使用して、動的な設定更新を習得しましょう。このガイドでは、アプリケーション設定をコンテナイメージから分離し、実行中の Pods 内の構成ファイルをリアルタイムで変更する方法を詳述します。ボリュームマウントの重要なステップ、Kubelet の伝播間隔の理解、およびサービス中断なしで新しい設定を検出し採用するためのアプリケーション側ロジックの実装について学びます。

36 ビュー

ダイナミック設定管理：ConfigMapを使用したリアルタイムアプリケーション更新

Kubernetesはアプリケーションの状態を管理するための堅牢なメカニズムを提供しますが、アプリケーション設定の変更には、イメージの再ビルドやデプロイメントPodの再起動が必要になることがよくあります。多くのマイクロサービスにとって、このダウンタイムや中断は許容できません。ここでConfigMapが非常に重要になります。ConfigMapは、機密性のない設定データをキーと値のペアで保存するために設計されたKubernetesオブジェクトであり、設定をアプリケーションコードから切り離します。

本記事では、ダイナミック設定管理を可能にするためのConfigMapの高度な使用法を探ります。これらの設定をボリュームマウント経由で実行中のPodに注入し、Podの再起動を必要とせずにアプリケーションが設定変更をほぼ瞬時に読み取れるようにする方法について詳しく説明します。この技術を習得することは、回復力が高く、継続的に進化するクラウドネイティブアプリケーションを構築するために不可欠です。

ConfigMapの理解：基礎

A ConfigMapを使用すると、設定データを一連のキーと値として保存できます。Secretとは異なり、ConfigMapはロギングレベル、外部サービスのエンドポイント、フィーチャーフラグなどの機密性のない設定データを対象としています。

サンプルConfigMapの作成

設定データはYAMLマニフェスト内に直接定義することも、既存のファイルやディレクトリから作成することもできます。アプリケーション固有のパラメーターを含むapp-settingsという名前のConfigMapを作成してみましょう。

例：YAMLでのConfigMapの定義

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-settings
data:
  # キーと値のペア
  LOG_LEVEL: "INFO"
  API_ENDPOINT: "https://api.default.svc.cluster.local"
  # 複数行の設定ファイルの内容
  application.properties: |
    server.port=8080
    feature.toggle.new_ui=false

このConfigMapは、2つの単純なキーと値のペアと、設定ファイルをシミュレートする1つの複雑なエントリ（application.properties）という3つのデータ項目を公開します。

Podへの設定の注入

ConfigMapは環境変数を設定できますが、動的更新の鍵は、それらをPodのファイルシステム内にボリュームとしてマウントすることにあります。ボリュームとしてマウントされると、KubernetesはConfigMap内の各キーを指定されたディレクトリ内のファイルとして扱います。

方法1：ボリュームマウントの使用（ダイナミックなアプローチ）

動的な更新を達成するには、Podの仕様内にConfigMapをマウントします。

例：ConfigMapボリュームマウントを使用したPod仕様

apiVersion: v1
kind: Pod
metadata:
  name: dynamic-app-pod
spec:
  containers:
  - name: my-app
    image: my-registry/my-app:latest
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config 
  volumes:
  - name: config-volume
    configMap:
      name: app-settings

このセットアップでは：

  1. ConfigMap app-settingsがconfig-volumeという名前のボリュームにリンクされます。
  2. ボリュームはコンテナ内の/etc/configにマウントされます。
  3. Kubernetesは、ConfigMapのキーに対応するファイルを/etc/config内に自動的に作成します。
    • /etc/config/LOG_LEVELには値INFOが含まれます。
    • /etc/config/application.propertiesには複数行の設定が含まれます。

方法2：環境変数の使用（静的なアプローチ）

よりシンプルで静的な値については、それらを環境変数として注入できます。注：このように設定された環境変数は、ConfigMapが変更されても自動的に更新されません。Podを再起動する必要があります。

# Deployment specからの抜粋
containers:
- name: my-app
  image: my-registry/my-app:latest
  env:
  - name: LOG_LEVEL
    valueFrom:
      configMapKeyRef:
        name: app-settings
        key: LOG_LEVEL

ベストプラクティス： 動的更新のためには、設定ファイルには常にボリュームマウントを利用してください。

リアルタイム更新の実現：変更の監視

ConfigMapが更新されると、KubernetesはボリュームとしてマウントされているコンシューミングPodに変更を伝播させようとします。動作はボリュームの種類と、ファイル変更を検出するアプリケーションの能力に依存します。

Kubeletによる更新の伝播方法

ボリュームとして使用されているConfigMapが変更された場合：

  1. Kubeletは定期的に更新をチェックします（通常は10秒ごと）。
  2. 更新が検出されると、Kubeletはホストのファイルシステム上のマウントされたファイルを更新します。
  3. 実行中のコンテナについては、コンテナのボリュームマウントディレクトリ内のファイルがインプレースで更新されます。

アプリケーション側での検出

重要なステップは、コンテナ内で実行されているアプリケーションコードが、これらのファイル変更を検出し、それに対応できるように設計されていることです。

例：ファイル監視のためのアプリケーションロジック（概念的なPython）

ほとんどの最新のアプリケーションは、ファイルシステムイベントを監視するために内部メカニズムまたはライブラリ（例：Linux上のinotify）を使用します。

import time
import os

CONFIG_PATH = "/etc/config/application.properties"

def load_config(path):
    # ファイルの内容を読み取り、解析する関数
    with open(path, 'r') as f:
        print(f"\n--- 設定がリロードされました ---\n{f.read()}")
        # 新しい設定を使用してサービスを再初期化するロジック

# 初期ロード
load_config(CONFIG_PATH)

# 継続的な監視ループ
last_modified = os.path.getmtime(CONFIG_PATH)

while True:
    current_modified = os.path.getmtime(CONFIG_PATH)
    if current_modified != last_modified:
        print("ファイル変更が検出されました。設定をリロードしています...")
        load_config(CONFIG_PATH)
        last_modified = current_modified
    time.sleep(5) # 5秒ごとにチェック

この例は、ファイルの変更時刻（mtime）をポーリングする方法を示しています。Kubeletがファイルを更新すると、アプリケーションはその変更を検出し、設定を動的にリロードできます。

ポーリング間隔に関する警告： Kubeletは（約10秒ごとに）頻繁にチェックを行いますが、ポーリングだけに頼るとわずかな遅延が発生する可能性があります。高性能アプリケーションでは、ほぼ瞬時の検出のために、ネイティブのファイルシステムイベント通知API（inotifyやFSEventsなど）を利用する必要があります。

ダイナミック更新ワークフロー：ステップバイステップの例

実行中のPodに触れることなく、LOG_LEVELをINFOからDEBUGに更新する手順を追って説明します。

ステップ1：初期状態

Podが実行されており、ボリュームマウント経由でConfigMapを使用していることを確認します。

ステップ2：ConfigMapの更新

kubectl editまたはkubectl applyを使用して、既存のConfigMapを変更します。

# kubectl editを使用して値を直接変更
kubectl edit configmap app-settings

# 以下の行を見つけて変更します:
# LOG_LEVEL: "INFO"
# 次のように変更します:
LOG_LEVEL: "DEBUG"

ステップ3：伝播の監視

Kubeletの同期サイクル（最大10秒）を待ちます。

アプリケーションが/etc/config/LOG_LEVELを監視している場合：

  1. Kubeletが基盤となるファイルを更新します。
  2. アプリケーションが変更を検出します（監視メカニズムに基づく）。
  3. アプリケーションは内部ロギング設定をDEBUGにリロードします。

重要なのは、Pod自体は変更されず、サービスのダウンタイムがゼロになることです。

設定管理の概要と考慮事項

ボリュームマウントを使用したConfigMapの使用は、Kubernetesワークロードで動的な設定更新を達成するための最も標準的な方法です。ただし、次の点に注意してください。

  • セキュリティ： ConfigMapはデータをプレーンテキストで保存します。機密情報にはSecretを使用してください。
  • 不変性： 重要な設定については、意図しないランタイム変更を防ぐために、作成後にConfigMapを不変（仕様でimmutable: true）にすることを検討してください。
  • アプリケーションの認識： ダイナミズムが可能になるのは、実行中のコンテナが設定ファイルをどのように監視し、リロードするかを知っている場合のみです。
  • ロールバック： 設定変更のロールバックには、ConfigMapを以前の状態に戻して更新し、アプリケーションの検出を待つ必要があります。

設定をデプロイメント成果物から切り離し、ボリュームマウントを活用することで、Kubernetesワークロードにおける設定パラメーターの堅牢でゼロダウンタイムの更新が可能になります。