web-dev-qa-db-ja.com

Kubernetes configmapsの自動サブディレクトリ？

（約2年前に非常によく似た質問がありましたが、具体的には秘密についてでしたが、configmapの話が違うとは思えません...しかし、少なくとも、ユースケースと既存の回避策がない理由を提示できます私たちにとって実行可能です。）

単純なカットダウンdeployment.yamlが与えられた場合：

apiVersion: apps/v1beta1
kind: Deployment
metadata: 
  name: example
spec:
  template: 
    spec:
      containers:
      - name: example
        volumeMounts:
        - name: vol
          mountPath: /app/Configuration
      volumes:
        - name: vol
          configMap:
            name: configs

および一致するconfigmap.yaml：

apiVersion: v1
kind: ConfigMap
metadata:
  name: configs
  labels:
    k8s-app: example
data:
    example1.json: |-
        {
            "key1": "value1"
        }

    example2.json: |-
        {
            "key2": "value2"
        }

configmap.yamlのキーは、それが何であれ、ファイルとして作成されるだけで、deployment.yamlを変更したり、mountPath以外の詳細を設定したりする必要はありません。

問題は、実際の構造には、ルート値をオーバーライドする領域固有の値を処理するサブフォルダーがあることです。

Configuration \ example1.json
Configuration \ example2.json
Configuration \ us \ example1.json
Configuration \ us \ ca \ example2.json

これらの数と性質は、考えられる限り多くの国や地域、および個別に構成されたモジュールごとに、明らかに異なる可能性があります。エンドユーザーにこれらの構成をセットアップおよび管理できるツールを提供することを目的としていました。これにより、舞台裏でconfigmap.yamlが自動的に生成され、kubernetesで更新されます。

ただし、まだ見つけていないトリックがない限り、これはいくつかの点でkubernetesの能力の範囲外のようです。

まず第一に、ディレクトリであるconfigmapキーを指定したり、キーにサブディレクトリパスを含めたりすることを可能にする構文はありません。

data:
    # one possible approach (currently complains that it doesn't validate '[-._a-zA-Z0-9]+')
    /us/example1.json: |-
        {
            "key1": "value1"
        }

    # another idea; this obviously results in 'invalid type for io.k8s.api.core.v1.ConfigMap.data: got "map", expected "string"'
    us:
        example2.json: |-
            {
                "key2": "value2"
            }

では、これを達成するためのオプションは何ですかare

Wellll、deployment.yamlのitems: -key: path:ノードでvolumes: -configMap:アプローチを使用して、キーを特定の場所にマッピングできます。

および/またはdeployment.yamlのvolumeMounts:ノードに複数のノードを生成します。

subPath:を使用する（これは基本的にitems: -key: -path:でvolumes: configMap:を使用するのと同じです）、

または、サブディレクトリごとに個別のconfigmapを作成し、それらをすべて異なるvolumesとしてdeployment.yamlにマウントします。

これらの方法はすべて、deployment.yamlに大規模で非常に冗長な変更を加える必要があり、知る理由がないはずの知識を漏らし、変更可能にし、静的ではなく継続的に再生成し、デプロイされた設定の更新のロールアウトを複雑にしますポッドなどなどなど。それは良くありません。そして、サブディレクトリが含まれているという理由だけで、1つのディレクトリをマップしただけです...

確かに、これは想定されている方法ではありませんか？何が足りないのですか？どうすればよいですか？

kubernetesyamlsubdirectory
11
Grank

「コンテナネイティブ」の観点からは、アプリケーションが起動時に処理して正規の構成に到達する構成ファイルの大きなファイルシステムツリーを持つことは、アンチパターンです。単一のファイルを生成するワークフローを用意することをお勧めします。このファイルは、ConfigMapに保存して、最終的な形式で簡単に検査できます。たとえば、nginxingressを参照してください。

しかし、明らかに、誰もがkubernetesアプローチとの整合性を高めるためにアプリを書き直しているわけではありません。デプロイ時に構成ファイルの完全なディレクトリツリーをコンテナに取り込む最も簡単な方法は、initContainersとemptyDirマウントを使用することです。

構成ファイルツリーをコンテナー（「データ専用」コンテナーと呼ばれることもあります）にパッケージ化し、コンテナー開始スクリプトに構成ツリーをemptyDirマウントにコピーするだけにします。その後、アプリケーションは期待どおりにツリーを消費できます。

1
Jonah Benton