Bridge to Kubernetes のしくみ

[アーティクル]
10/17/2023

Note

Microsoft は、Bridge to Kubernetes プロジェクトを積極的に維持することを計画しています。今後数か月で、プロジェクトをアーカイブ状態に移行します。それまでの間、プロジェクトは引き続き使用およびダウンロードできます。この期間中、私たちは、今後のご利用のために Bridge to Kubernetes と同様のメリットを提供するコミュニティプロジェクトを調査し、推奨したいと考えています。ご質問がある場合は、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 クラスター内の環境変数とマウントされたボリュームを開発用コンピューターに複製できます。環境変数およびマウントされたボリュームにアクセスすることで、それらの依存関係を複製せずにコードを操作できます。

要件

Note

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 拡張機能をインストールします。

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

注意

Bridge to Kubernetes を使用するときは、開発用コンピューターにリダイレクトするサービスの名前の指定を求められます。このオプションを利用して、リダイレクト用のポッドを簡単に見分けることができます。 Kubernetes クラスターと開発用コンピューターの間のすべてのリダイレクトは、ポッドを対象としています。詳細については、「サービスを利用できるようにする」を参照してください。

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

注意事項

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

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

接続の確立

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

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

Bridge to Kubernetes の使用

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

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

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

注意

クラスターへの接続が行われている間とその後 15 分間、Bridge to Kubernetes により、ローカルコンピューター上で管理者権限を使用して EndpointManager という名前のプロセスが実行されます。

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

追加構成

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

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

既定では、Bridge to Kubernetes によって 1 つのサービスのすべてのトラフィックが開発用コンピューターにリダイレクトされます。代わりに、ルーティング機能を使用して、サブドメインからの要求のみを開発用コンピューターにリダイレクトすることができます。これらのルーティング機能により、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 サブドメインで複製されたイングレスに関連付けられたエンボイポッドを作成します。
分離して作業しているサービス用に別のエンボイポッドを作成します。この構成により、サブドメインを指定した要求を開発用コンピューターにルーティングすることができます。
サブドメインを持つサービスのルーティングを処理するために、各エンボイポッド用のルーティング規則を構成します。

次の図は、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 つのポッドには、そのポッドで実行されているコンテナーが 1 つだけ与えられます。
現時点では、Bridge to Kubernetes ポッドは、Linux コンテナーである必要があります。 Windows コンテナーはサポートされていません。
ホストファイルを編集する目的で開発コンピューターで実行するには、管理者特権が Bridge to Kubernetes に必要になります。
Azure Dev Spaces が有効なクラスターでは、Bridge to Kubernetes を使用できません。

次のステップ

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

次の方法で共有