Bridge to Kubernetes の構成

[アーティクル]
02/07/2025

手記

Bridge to Kubernetes は、2025 年 4 月 30 日に廃止されます。提供終了とオープンソースの代替方法の詳細については、GitHub の問題を参照してください。

2 つの方法を使用して、ローカル Bridge to Kubernetes プロセスを構成できます。クラスター上のサービスに注釈を付けることができ、ローカル構成を指定できます。

Kubernetes の構成

Kubernetes 構成 (kubeconfig) ファイルは既定で ~/.kube/configに格納されますが、KUBECONFIG 環境変数を使用して設定できます。

Visual Studio を使用している場合は、デバッグプロパティの デバッグ起動プロファイル UI を使用して、IDE で Bridge to Kubernetes 起動プロファイルを編集できます。「起動プロファイルの編集」を参照してください。

そこから、次の画面を開くことができます。この画面では、最も一般的な構成プロパティの一部を編集できます。

Bridge to Kubernetes が特定のポートを転送できないようにする

サービスに bridgetokubernetes/ignore-ports 注釈を追加して、Kubernetes サービスの特定のポートをマシンにマッピングすることを無視するように Bridge to Kubernetes を構成します。

apiVersion: v1
kind: Service
metadata:
  annotations:
    bridgetokubernetes/ignore-ports:445,23

(KubernetesLocalProcessConfig.yaml) を使用したローカル構成

KubernetesLocalProcessConfig.yaml ファイルを使用すると、クラスター内のポッドで使用できる環境変数とマウントされたファイルをレプリケートできます。 KubernetesLocalProcessConfig.yaml ファイルでは、次のアクションを指定できます。

ボリュームをダウンロードし、そのボリュームへのパスを環境変数として設定します。
クラスターで実行されているサービスを、開発用コンピューターで実行されているプロセスで使用できるようにします。
定数値を使用して環境変数を作成します。

既定の KubernetesLocalProcessConfig.yaml ファイルは自動的に作成されないため、プロジェクトのルートにファイルを手動で作成する必要があります。

ボリュームをダウンロードする

envで、ダウンロードしたい各ボリュームに対して、名と値を指定します。名は、開発用コンピューターで使用される環境変数です。値は、開発用コンピューター上のボリューム名とパスです。 [value] の値は、$(volumeMounts:VOLUME_NAME)/PATH/TO/FILES の形式を取ります。

例えば：

version: 0.1
env:
  - name: ALLOW_LIST_PATH
    value: $(volumeMounts:allow-list)/allow-list

上の例では、コンテナーから allow-list ボリュームをダウンロードし、その場所に環境変数 ALLOW_LIST_PATHへのパスを設定します。既定の動作では、開発用コンピューターの一時ディレクトリで指定したパスにファイルをダウンロードします。上記の例では、ALLOW_LIST_PATH は /TEMPORARY_DIR/allow-listに設定されています。

手記

ボリュームをダウンロードすると、設定したパスに関係なく、そのボリュームの内容全体がダウンロードされます。パスは、開発用コンピューターで使用する環境変数を設定するためにのみ使用されます。トークンの末尾に /allow-list または /path/to/files を追加しても、実際にはボリュームの永続化される場所には影響しません。環境変数は、アプリがそのボリューム内の特定のファイルへの参照を必要とする場合に便利です。

また、一時ディレクトリを使用する代わりに、開発用コンピューターにボリュームマウントをダウンロードする場所を指定することもできます。特定の場所ごとに、[volumeMounts] で [name] と [localPath] を指定します。 [name] は照合するボリューム名であり、[localPath] は開発用コンピューター上の絶対パスです。例えば：

version: 0.1
volumeMounts:
  - name: default-token-*
    localPath: /var/run/secrets/kubernetes.io/serviceaccount
env:
  - name: KUBERNETES_IN_CLUSTER_CONFIG_OVERRIDE
    value: $(volumeMounts:default-token-*)

上記の例では、env のエントリを使用して、default-token-*に一致するボリュームをダウンロードします。たとえば default-token-1111 や default-token-1234-5678-90abcdefなどです。複数のボリュームが一致する場合は、最初に一致するボリュームが使用されます。 volumeMountsのエントリを利用して、すべてのファイルが /var/run/secrets/kubernetes.io/serviceaccount に開発用コンピュータにダウンロードされます。 KUBERNETES_IN_CLUSTER_CONFIG_OVERRIDE 環境変数は /var/run/secrets/kubernetes.io/serviceaccountに設定されます。

サービスを利用できるようにする

開発用コンピューターで使用できるようにするサービスごとに、[env] で [name] と [value] を指定します。名は、開発用コンピューターで使用される環境変数です。値は、クラスターからのサービスの名前とパスです。 [value] の値は、$(services:SERVICE_NAME)/PATH の形式を取ります。

例えば：

version: 0.1
env:
  - name: MYAPP1_SERVICE_HOST
    value: $(services:myapp1)/api/v1/

上の例では、myapp1 サービスを開発用コンピューターで使用できるようにします。MYAPP1_SERVICE_HOST 環境変数は、/api/v1 パス (つまり、127.1.1.4/api/v1) を持つ myapp1 サービスのローカル IP アドレスに設定されます。 myapp1 サービスには、環境変数、myapp1、または myapp1.svc.cluster.local を使用してアクセスできます。

手記

開発用コンピューターでサービスを使用できるようにすると、設定したパスに関係なく、サービス全体を使用できるようになります。パスは、開発用コンピューターで使用する環境変数を設定するためにのみ使用されます。 特定の Kubernetes 名前空間からサービスを使用できるようにするには、$(services:SERVICE_NAME.NAMESPACE_NAME) を使用します。 例えば：

version: 0.1
env:
  - name: MYAPP2_SERVICE_HOST
    value: $(services:myapp2.mynamespace)

上の例では、mynamespace 名前空間の myapp2 を開発用コンピューターで使用できるようにし、MYAPP2_SERVICE_HOST 環境変数を、mynamespace 名前空間の myapp2 のローカル IP アドレスに設定します。

定数値を使用して環境変数を作成する

環境で、開発用コンピュータに作成したい環境変数ごとに、名と値を指定します。名は、開発用コンピューターで使用される環境変数であり、値値です。例えば：

version: 0.1
env:
  - name: DEBUG_MODE
    value: "true"

上の例では、値が [true] の [DEBUG_MODE] という名前の環境変数を作成します。

サービスの依存関係を追加する

サービスの宣言方法と同様に、汎用の依存関係フィールドを使用して、データベースやキャッシュなどのサービス依存関係を指定できます。デバッグするサービスがクラスターで実行されていないリソースに接続する必要がある場合は、ここで依存関係を指定します。次の例のように依存関係を宣言します。

version: 0.1
volumeMounts:
env:
  - name: DB_HOST
    value: $(externalendpoints:server-bridgetest123.database.windows.net:1433)

依存関係のホスト DNS 名 (例ではserver-bridgetest13.database.windows.net) とポート (例では 1433) を指定します。

データベースなどの依存関係を指定すると、リダイレクト認証モデルは機能しません。たとえば、Azure SQL Database の場合は、接続ポリシーを ("リダイレクト" または "既定" ではなく) "プロキシ" に設定する必要があります。

KubernetesLocalProcessConfig.yaml の例

完全な KubernetesLocalProcessConfig.yaml ファイルの例を次に示します。

version: 0.1
volumeMounts:
  - name: default-token-*
    localPath: /var/run/secrets/kubernetes.io/serviceaccount
env:
  - name: KUBERNETES_IN_CLUSTER_CONFIG_OVERRIDE
    value: $(volumeMounts:default-token-*)
  - name: ALLOW_LIST_PATH
    value: $(volumeMounts:allow-list)/allow-list
  - name: MYAPP1_SERVICE_HOST
    value: $(services:myapp1)/api/v1/
  - name: MYAPP2_SERVICE_HOST
    value: $(services:myapp2.mynamespace)
  - name: DEBUG_MODE 
    value: "true"

次の手順

Bridge to Kubernetes を使用してローカル開発コンピューターにクラスターに接続する方法については、「Visual Studio Code で Bridge to Kubernetes を使用すると、Visual Studio で Bridge to Kubernetes を使用するを参照してください。

次の方法で共有