Bridge to Kubernetes のしくみ

[アーティクル]
01/31/2025

手記

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

Bridge to Kubernetes は、Kubernetes を対象とするマイクロサービスアプリケーションを作成するための反復開発ツールです。 Bridge to Kubernetes 拡張機能は、Visual Studio と Visual Studio Code (VS Code) で使用できます。

Bridge to Kubernetes を使用すると、開発用コンピューターでコードを実行およびデバッグできます。そのコンピューターは引き続き、アプリケーションまたはサービスの残りの部分を使用して Kubernetes クラスターに接続されています。相互に依存する多くのサービスとデータベースを備えた大規模なマイクロサービスアーキテクチャを使用している場合、それらの依存関係を開発用コンピューターにレプリケートすることは困難な場合があります。コードの変更ごとに Kubernetes クラスターにコードをビルドしてデプロイするのは、遅く、時間がかかり、難しい場合があります。

Bridge to Kubernetes は、開発用コンピューターとクラスターの間に接続を作成します。この方法では、コードをビルドしてクラスターにデプロイする必要がなくなります。クラスターに接続されたコンテキストでサービスをテストおよび開発できます。この方法では、Docker または Kubernetes の構成をこれ以上作成せずにデバッグできます。

Bridge to Kubernetes は、接続されている Kubernetes クラスターと開発用コンピューターの間でトラフィックをリダイレクトします。 Kubernetes クラスター内のローカルコードとサービスは、同じ Kubernetes クラスター内にあるかのように通信できます。

Bridge to Kubernetes を使用すると、Kubernetes クラスター内の環境変数とマウントされたボリュームを開発コンピューターにレプリケートできます。環境変数とマウントされたボリュームにアクセスすると、それらの依存関係をレプリケートしなくても、コードで作業できます。

必要条件

手記

Bridge to Kubernetes は、Docker for Desktop Kubernetes クラスターでは機能しません。 Bridge to Kubernetes を使用するには、次のいずれかの構成が必要です。

Bridge to Kubernetes 拡張機能がインストールされた VS Code。
Windows 10 以降で実行されている Visual Studio 2019 バージョン 16.7 以降。 ASP.NET と Web 開発 ワークロードがインストールされていることを確認します。 Bridge to Kubernetes Extensionをインストールします。

Bridge to Kubernetes を使用して、Kubernetes クラスターへの接続を確立できます。この接続により、クラスター内の既存のポッドとの間でトラフィックが開発用コンピューターにリダイレクトされます。

手記

Bridge to Kubernetes を使用する場合は、開発用コンピューターにリダイレクトするサービスの名前を求められます。このオプションは、リダイレクト用のポッドを識別するのに便利な方法です。 Kubernetes クラスターと開発環境のコンピューター間のすべてのリダイレクトは、特定のポッドに対して行われます。詳細については、「サービスを利用可能にする」を参照してください。

VS Code では、Bridge to Kubernetes では、ローカルで実行できる限り、すべての言語がサポートされます。 Visual Studio では、Bridge to Kubernetes は .NET Core をサポートしています。 Bridge to Kubernetes は、Windows ノードのサポートを必要とするため、Visual Studio では .NET Framework をサポートしていません。

注意

Bridge to Kubernetes は、開発とテストのシナリオでのみ使用することを目的としています。運用クラスターまたはアクティブな使用中のライブサービスでの使用は意図されていません。また、サポートされていません。

現在の機能と今後の計画については、Bridge to Kubernetes ロードマップを参照してください。

接続の確立

Bridge to Kubernetes がクラスターへの接続を確立すると、次のアクションが実行されます。

クラスターで置き換えるサービス、コードに使用する開発用コンピューター上のポート、およびコードの起動タスクを 1 回限りのアクションとして構成するように求められます。
クラスター上のポッド内のコンテナーを、開発用コンピューターにトラフィックをリダイレクトするリモートエージェントコンテナーに置き換えます。
開発用コンピューターで kubectl port-forward を実行して、クラスタ内で動作しているリモートエージェントにトラフィックを転送します。
リモートエージェントを使用して、クラスターから環境情報を収集します。この環境情報には、環境変数、表示されるサービス、ボリュームマウント、シークレットマウントが含まれます。
開発用コンピューター上のサービスがクラスターで実行されている場合と同じ変数にアクセスできるように、Visual Studio で環境を設定します。
ホスト ファイルを更新して、クラスター上のサービスを開発用コンピューター上のローカル IP アドレスにマップします。これらの ホスト ファイルエントリを使用すると、開発用コンピューターで実行されているコードで、クラスターで実行されている他のサービスに要求を行うことができます。 ホスト ファイルを更新するには、Bridge to Kubernetes で開発用コンピューターに対する管理者アクセス権が必要です。
開発用コンピューターでコードの実行とデバッグを開始します。必要に応じて、Bridge to Kubernetes は、これらのポートを現在使用しているサービスまたはプロセスを停止することで、開発用コンピューター上の必要なポートを解放します。

Bridge to Kubernetes の使用

クラスターへの接続を確立したら、コンテナー化せずに、コンピューター上でコードをネイティブに実行してデバッグします。コードはクラスターと対話します。リモートエージェントが受信するすべてのネットワークトラフィックは、接続中に指定されたローカルポートにリダイレクトされます。ネイティブで実行されているコードは、そのトラフィックを受け入れて処理できます。クラスターの環境変数、ボリューム、シークレットは、開発用コンピューターで実行されているコードで使用できます。

Bridge to Kubernetes では、ホスト ファイルエントリとポートフォワーディングが開発者コンピューターに追加されます。コードでは、クラスターのサービス名を使用して、クラスターで実行されているサービスにネットワークトラフィックを送信できます。そのトラフィックは、クラスターで実行されているサービスに転送されます。接続されている間は、開発用コンピューターとクラスターの間でトラフィックがルーティングされます。

さらに、Bridge to Kubernetes には、KubernetesLocalProcessConfig.yaml ファイルを使用して、開発用コンピューター上のクラスター内のポッドで使用できる環境変数とマウントされたファイルをレプリケートする方法が用意されています。このファイルを使用して、新しい環境変数とボリュームマウントを作成することもできます。

手記

クラスターへの接続に加えて 15 分間、Bridge to Kubernetes は、ローカルコンピューターの管理者アクセス許可 EndpointManager と呼ばれるプロセスを実行します。

複数のサービスを使用して、並列でデバッグできます。デバッグするサービスと同じ数の Visual Studio インスタンスを起動します。各サービスによって異なるポートがローカルでリッスンされていることを確認します。それらを個別に構成してデバッグします。このシナリオでは、分離はサポートされていません。

追加の構成

KubernetesLocalProcessConfig.yaml ファイルを使用すると、クラスター内のポッドで使用できる環境変数とマウントされたファイルをレプリケートできます。 Visual Studio を使用する場合、KubernetesLocalConfig.yaml ファイルは、サービスのプロジェクトファイルと同じディレクトリに存在する必要があります。詳細については、「Bridge to Kubernetesの構成」を参照してください。

分離して開発するためのルーティング機能の使用

既定では、Bridge to Kubernetes は、サービスのすべてのトラフィックを開発用コンピューターにリダイレクトします。代わりに、ルーティング機能を使用して、サブドメインから開発用コンピューターにのみ要求をリダイレクトできます。これらのルーティング機能を使用すると、Bridge to Kubernetes を使用して分離して開発し、クラスター内の他のトラフィックを中断しないようにすることができます。

次のアニメーションは、同じクラスターで単独で作業している 2 人の開発者を示しています。

アニメーションは分離を示し、2 人の開発者が同じクラスターで作業しています。

分離して作業を有効にすると、Bridge to Kubernetes は Kubernetes クラスターへの接続に加えて次のアクションを実行します。

Kubernetes クラスターで Azure Dev Spaces が有効になっていないことを確認します。
選択したサービスをクラスター内の同じ名前空間にレプリケートし、routing.visualstudio.io/route-from=SERVICE_NAME ラベルと routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME 注釈を追加します。
Kubernetes クラスター上の同じ名前空間でルーティングマネージャーを構成して起動します。ルーティングマネージャーは、名前空間でルーティングを構成するときに、ラベルセレクターを使用して routing.visualstudio.io/route-from=SERVICE_NAME ラベルと routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME 注釈を検索します。

手記

Bridge to Kubernetes は、Kubernetes クラスターで Azure Dev Spaces が有効になっているかどうかを確認します。 Bridge to Kubernetes を使用する前に、Azure Dev Spaces を無効にするように求められます。

ルーティングマネージャーは、起動時に次のアクションを実行します。

サブドメインの GENERATED_NAME を使用して、名前空間内にあるロードバランサーのイングレスを含むすべてのイングレスを複製します。
各サービス用に、GENERATED_NAME サブドメインで複製されたイングレスに関連付けられたエンボイポッドを作成します。
独立して作業中のサービス向けに別のエンヴォイポッドを作成します。この構成により、サブドメインを含む要求を開発用コンピューターにルーティングできます。
サブドメインを使用するサービスのルーティングを処理するように、各 envoy ポッドのルーティング規則を構成します。

次の図は、Bridge to Kubernetes がクラスターに接続する前の Kubernetes クラスターを示しています。

Bridge to Kubernetes のないクラスターの図。

次の図は、Bridge to Kubernetes が分離モードで有効になっている同じクラスターを示しています。ここでは、重複するサービスと、分離したルーティングをサポートするエンボイポッドを確認できます。

Bridge to Kubernetes が有効になっているクラスターの図。

クラスターは、GENERATED_NAME サブドメインで要求を受信すると、kubernetes-route-as=GENERATED_NAME ヘッダーを要求に追加します。エンボイポッドは、クラスター内の適切なサービスに要求するルーティングを処理します。分離して処理されているサービスへの要求の場合、クラスターはリモートエージェントによって開発用コンピューターに要求をリダイレクトします。

クラスターは、GENERATED_NAME サブドメインなしで要求を受信しても、要求にヘッダーを追加しません。エンボイポッドは、クラスター内の適切なサービスに要求するルーティングを処理します。置き換えられるサービスの要求の場合、ポッドはリモートエージェントではなく元のサービスにルーティングします。

重要

クラスター上の各サービスは、追加の要求を行うときに、kubernetes-route-as=GENERATED_NAME ヘッダーを転送する必要があります。たとえば、serviceA が要求を受信すると、serviceB に要求を行い、その後で応答を返します。この例では、serviceA がリクエストに含まれる kubernetes-route-as=GENERATED_NAME ヘッダーを serviceBに転送する必要があります。 ASP.NETなどの一部の言語には、ヘッダー伝達を処理するためのメソッドが含まれる場合があります。

クラスターから切断すると、既定では Bridge to Kubernetes によってすべてのエンボイポッドと重複するサービスが削除されます。

手記

ルーティングマネージャーのデプロイとサービスは、名前空間で引き続き実行されます。デプロイとサービスを削除するには、名前空間に対して次のコマンドを実行します。

kubectl delete deployment routingmanager-deployment -n NAMESPACE
kubectl delete service routingmanager-service -n NAMESPACE

診断とログ記録

Bridge to Kubernetes を使用してクラスターに接続すると、コンピューターによって診断がログに記録されます。開発用コンピューターの TEMP ディレクトリの Bridge to Kubernetes フォルダーに格納されます。

Kubernetes RBAC 認可

Kubernetes には、ユーザーとグループのアクセス許可を管理するためのロールベースのアクセス制御 (RBAC) が用意されています。詳細については、Kubernetes のドキュメントを参照してください。 RBAC 対応クラスターのアクセス許可を設定するには、YAML ファイルを作成し、kubectl を使用してクラスターに適用します。

クラスターに対するアクセス許可を設定するには、permissions.ymlなどの YAML ファイルを作成または変更します。 <namespace> の名前空間と、アクセスを必要とするユーザーとグループを使用します。

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: bridgetokubernetes-<namespace>
  namespace: development
subjects:
  - kind: User
    name: jane.w6wn8.k8s.ginger.eu-central-1.aws.gigantic.io
    apiGroup: rbac.authorization.k8s.io
  - kind: Group
    name: dev-admin
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io

次のコマンドを使用してアクセス許可を適用します。

kubectl -n <namespace> apply -f <yaml file name>

制限

Bridge to Kubernetes には、次の制限があります。

ポッドには、Bridge to Kubernetes が正常に接続するために、そのポッドで実行されているコンテナーが 1 つだけ存在する場合があります。
現時点では、Bridge to Kubernetes ポッドは Linux コンテナーである必要があります。 Windows コンテナーはサポートされていません。
Bridge to Kubernetes は、開発用コンピューターでの実行および hosts ファイルの編集のために、昇格されたアクセス許可が必要です。
Azure Dev Spaces が有効になっているクラスターでは、Bridge to Kubernetes を使用できません。

次の手順

Bridge to Kubernetes を使用してローカル環境の開発用コンピューターをクラスターに接続する方法については、Bridge to Kubernetes の使用 (VS) または Bridge to Kubernetes の使用 (VS Code) に関する記事を参照してください。

次の方法で共有