ConfigMapは、コンテナに設定を挿入するためのKubernetesリソースです。スタックの設定をコードとは別に維持できます。 ConfigMapを操作して、ポッドに提供する方法は次のとおりです。
ConfigMapsの目的は何ですか？
ConfigMapsは、機密性の低い少量の構成データをカプセル化するように特別に設計されています。これらは、任意のキーと値のペアをポッドに取り込むためのメカニズムです。これらは通常、データベースサーバーのIPアドレス、アプリケーションの送信メールアドレス、およびポッドの外部で構成する必要があるその他のアプリケーション固有の設定を保存するために使用されます。
ConfigMapを使用すると、専用のKubernetesリソースでこのデータを管理できます。ポッドは、マウントされたボリューム内の環境変数またはファイルとしてキーと値のペアを受け取ります。
それらを使用しない理由
ConfigMapがすべきでない状況がいくつかあります。 使用されます。
ConfigMapは安全に保存されておらず、その値には暗号化がありません。漏洩した場合にセキュリティまたはプライバシーのリスクを構成する機密データや機密データが含まれていてはなりません。
パスワード、APIキー、または暗号化キーをConfigMapに入れないでください。代わりにKubernetesシークレットを使用してください。これらは、ConfigMapと同様に機能しますが、保護が追加されています。データベース接続が必要なシステムでは、ホスト名をConfigMapに配置し、クレデンシャルを別のシークレットに配置する必要があります。
個々のConfigMapのサイズは1MBを超えることはできません。より多くの構成キーを必要とするシステムは、ボリュームを介して手動で生成された構成ファイルを挿入するなどの代替アプローチによってより適切に提供される可能性があります。
ConfigMapを使い続けたい場合は、構成を複数のConfigMapリソースに分割することを検討してください。このアプローチでは、1 MBの上限を回避しながら、各ポッドに必要な最小限の構成キーのセットを提供できるようにする必要があります。
ConfigMap値は、UTF-8文字列またはbase64文字列としてエンコードされたバイナリデータのいずれかです。キー名には英数字の。を含めることができます （ピリオド）、- （ハイフン）、および _ （アンダースコア）文字。一部のプログラミング言語とフレームワークでは、構成変数の規則が異なる場合があるため、Kubernetesとアプリの両方でサポートされている形式を使用してください。
ConfigMapの作成
ConfigMapには単純なYAMLマニフェストがあります。各ConfigMapにはnameが必要です 標準のKubernetes形式とdata キーと値のペアを含むフィールド：
apiVersion: v1 kind: ConfigMap metadata: name: example-configmap data: database_host: "192.168.0.10" system_email: "[email protected]"
data フィールドは、文字列値でキーを指定するためのものです。 binaryDataを使用できます 代わりに、または data base64でエンコードされたバイナリ値を追加します。キーは、両方の dataで一意である必要があります およびbinaryData 。
kubectlを使用してマニフェストをクラスターに適用します またはお好みのツール。
ConfigMapとポッドのリンク
ConfigMapはそれ自体では何もしません。クラスタにいくつかのデータを追加しました。それでは、ポッドにリンクしましょう：
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
- name: example-container
image: example-image:latest
envFrom:
- configMapRef:
name: example-configmap
envFrom フィールドは、別の参照リソースによって定義された環境変数を取り込みます。この場合、 configMapRef 以前に作成されたConfigMapを識別します。ポッドのコンテナはdatabase_hostで開始されます およびsystem_email 定義された環境変数。
envFrom ConfigMapのすべてのキーを使用する必要があり、ポッドの他の環境変数との競合がないことが確実な場合に便利です。より制御された状況では、通常の envを使用します セクションで、個々のキーを定義し、ConfigMapから各キーの値を取得します。
env:
- name: DATABASE_HOST_IP
valueFrom:
configMapKeyRef:
name: example-configmap
key: database_host
この例は、 database_hostだけでポッドを開始する方法を示しています。 ConfigMapからのキー。キーはインジェクションの前にも名前が変更されるため、ポッドはキーを DATABASE_HOST_IPとして受け取ります。 。
ConfigMapは、ポッド内にファイルとしてマウントできます。 Kubernetesはボリュームを作成し、ConfigMapのコンテンツをファイルのセットとして挿入し、ボリュームをポッドにマウントします。
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
- name: example-container
image: example-image:latest
volumeMounts:
- name: app-config
mountPath: "/etc/config-data"
readOnly: true
volumes:
- name: app-config
configMap:
name: example-configmap
このポッドマニフェストは、 app-configというボリュームを作成します 。 configMap フィールドは、指定されたConfigMapのデータを使用してボリュームを事前入力します。
ポッドはボリュームを/etc / config-dataにマウントします 。コンテナは、ディレクトリ内のファイルを読み取って、構成値にアクセスできます。各ConfigMapキーには、マウントポイント内に独自のファイルがあります。
ConfigMap値の更新
ConfigMapは標準のKubernetesAPIリソースであるため、マニフェストを変更してクラスターに再適用することで、いつでも値を更新できます。新しい値がポッドに到達する方法は、使用しているインジェクションメカニズムによって異なります。
ボリュームを介してポッドにマウントされたConfigMapは、Kubernetesによって更新されます。 ConfigMapsへの変更は定期的にチェックされます。差異が検出されると、ボリューム内のファイルが更新されるため、ポッドは新しいデータを受け取ります。遅延は、ワーカーノード上のKubeletインスタンスに構成されている同期間隔によって異なります。
ポッドの環境変数を変更することはできないため、ConfigMapの変更は、このメカニズムを介してキーを参照している既存のポッドには届きません。新しいデータを使用するには、ポッドを交換する必要があります。
新しく作成されたポッドは、ボリュームまたは環境変数のどちらを使用しているかに関係なく、常に現在のConfigMapデータを受け取ります。構成の更新を強制する必要がある場合は、ポッドのアノテーションを変更して、Kubernetesがそれを再作成するようにします。
ConfigMapには、オプションの immutable があります それらが更新されないようにするフィールド。このフィールドが設定されている場合、ConfigMapのデータを更新したり、不変のステータスを削除したりすることはできません。
apiVersion: v1 kind: ConfigMap metadata: name: immutable-configmap data: foo: bar immutable: true
これは、構成値が変更されないことが確実な場合に役立ちます。誤って編集する可能性を排除することにより、安全性を向上させます。値の変更をポッドに伝播するためにKubernetesがConfigMapを監視する必要がなくなるため、パフォーマンスも向上する可能性があります。
ConfigMapsは、機密性の低い構成キーをKubernetesポッドに提供するための頼りになるものです。これらは、環境変数またはボリューム内のマウントされたファイルとして使用できるファーストクラスのAPIリソースです。
パスワードおよびその他の資格情報はシークレットに属します。これらはConfigMapsと非常によく似て機能し、同じ方法でポッドによって参照されます。 configMapRefに置き換えます secretRefを使用 ConfigMapではなく名前付きシークレットからキーをプルします。