Ingres を使用して Dapr アプリケーションにアクセスする

前回の記事では、分散ランタイム Dapr の使い方を紹介しました。この例では、状態ストレージ機能が Dapr ランタイムに分離され、アプリケーションは Dapr API を通じてこの機能を使用しました。この記事では、Ingress Controller を介して Dapr アプリケーションにアクセスする方法を紹介します。

プラン

Dapr アプリケーションをパブリックにアクセス可能にする方法は 2 つあります。

1. 従来の使用方法と同様に、アプリケーションのサービスをバックエンドとして構成し、イングレス コントローラーがトラフィックをアプリケーション コンテナーに直接転送します。つまり、自動構成をサポートする L7 ロードバランサーです。
2. アプリケーション コンテナーには直接アクセスされず、Daprd ランタイムを介してアクセスされます。この時点で、イングレス コントローラーを Dapr アプリケーションとして宣言し、そこに Daprd ランタイム コンテナーを挿入する必要があります。現時点で Ingress ルールが指しているバックエンドは、Ingress の Dapr サービスです。

2 つのソリューションにはそれぞれ長所と短所があります。前者はシンプルなアーキテクチャを持っています。後者は Daprd コンテナを導入しますが、アーキテクチャが複雑で、より多くのリソースを消費しますが、タイムアウト、再試行、アクセス制御などの Dapr のサービス ガバナンス機能も使用できます。

次に、例を使用して 2 つのソリューションをそれぞれ検証します。

デモ

前提条件

• 舵
• dapr-cli

エクスポート INSTALL_K3S_VERSION=v1.23.8+k3s2
 curl -sfL https://get.k3s.io | sh -s - --disable traefik --write-kubeconfig-mode 644 --write-kubeconfig ~/.kube/config

Daprをインストールする

 dapr を初期化します --kubernetes --wait

イングレス コントローラのインストール

ここではFlomeshの入口コントローラが使用されています。 valus.yaml​ を通じて、Ingress コントローラーに dapr 関連のアノテーションを追加します。ここで注目すべき点は、デフォルトでは、Daprd ランタイムがリッスンするポートはループバック アドレスにバインドされており、Ingress はバックエンドにリクエストを転送するときに Pod IP を使用することです。したがって、Daprd ランタイムが Pod IP からのリクエストを受信できるように、dapr.io/sidecar-listen-addresses: "[::],0.0.0.0" にアノテーションを付ける必要があります。

 #値.yaml
フスム:
 入口:
 ポッド注釈:
 dapr .io /サイドカー- listen -アドレス: "[::],0.0.0.0"
 dapr .io /有効: "true"
 dapr .io /アプリ- ID : 「ingress」
 dapr .io /アプリ-ポート: "8000"
 dapr .io /有効化- API -ログ記録: "true"
 dapr .io / config : "ingressconfig" 

 helmリポジトリにfsmを追加しますhttps://charts.flomesh.io
 helm リポジトリの更新

ヘルムインストール\
 --namespace flomesh \
 --名前空間を作成 \
 --versinotallow=0.2.1-alpha.3 \
 -f値.yaml \
 フスム フスム/フスム

サンプルアプリケーションをデプロイする

サンプル アプリケーションでは、kennethreitz/httpbin を使用し、それに dapr 関連のアノテーションを追加します。

 kubectl で ns-httpbinを作成します

kubectl apply -n httpbin -f - << EOF
 apiバージョン:アプリ/ v1
種類:デプロイメント
メタデータ:
 ラベル:
 アプリ: httpbin
 名前: httpbin
仕様:
 レプリカ： 1
 セレクター:
 マッチラベル:
 アプリ: httpbin
 戦略： { }
 テンプレート：
 メタデータ:
 注釈:
 dapr .io /有効: "true"
 dapr .io /アプリ- ID : "httpbin"
 dapr.io/app -ポート: "80"
 dapr .io /有効化- API -ログ記録: "true"
 dapr .io / config : "httpbinconfig"
 ラベル:
 アプリ: httpbin
 仕様:
 コンテナ:
 -画像: kennethreitz / httpbin
 名前: httpbin
 リソース： { }
 ---
 APIバージョン: v1
種類:サービス
メタデータ:
 ラベル:
 アプリ: httpbin
 名前: httpbin
 名前空間: httpbin
仕様:
 ポート:
 -ポート: 80
 プロトコル: TCP
 ターゲットポート: 80
 セレクター:
 アプリ: httpbin
終了

解決策1

Flomesh Ingressのドキュメント[1]を参照して、バックエンドとしてService httpbinを使用してIngressルールを作成します。

 kubectl apply -n httpbin -f - << EOF
 apiバージョン:ネットワーク.k8s .io / v1
種類:イングレス
メタデータ:
 名前: httpbin
 注釈:
 pipy .ingress .kubernetes .io /を書き換え-ターゲット- from : ^/ httpbin / ?
 pipy .ingress .kubernetes .io /を次のターゲットに書き換えます: /
仕様:
 イングレスクラス名: pipy
 ルール:
 - http :
 パス:
 -バックエンド:
 サービス：
 名前: httpbin
 ポート:
 番号： 80
 パス: / httpbin
 パスタイプ:プレフィックス
終了

/httpbin/get にアクセスするには、Ingress コントローラーのホスト IP アドレスとポート 80 を使用します。上記で設定されたパスの書き換えにより、最終リクエスト /get がターゲット Pod に送信されます。

 curl HOST_IP : 80 / httpbin / get
 {
 「引数」 : { } ,
 「ヘッダー」 : {
 "受け入れる" ： "*/*" 、
 「接続」 ： 「キープアライブ」 、
 「コンテンツの長さ」 : 「0」 、
 「ホスト」 : 「20.239.95.81:80」 、
 「ユーザーエージェント」 : 「curl/7.86.0」
 } 、
 「オリジン」 : 「10.42.0.18」 、
 「URL」 : 「http://20.239.95.81:80/get」
 }

解決策2

ソリューション 2 でもイングレス ルールの構成が必要ですが、今回はバックエンド サービスがイングレス コントローラーの Dapr サービスを構成します。 kubectl get svc -n flomesh を使用すると、-dapr サフィックスを持つサービスを見つけることができます。

 kubectl 適用- n flomesh - f - << EOF
 apiバージョン:ネットワーク.k8s .io / v1
種類:イングレス
メタデータ:
 名前: dapr
 注釈:
 pipy .ingress .kubernetes .io /を書き換え-ターゲット-から: ^/ dapr / ?
 pipy .ingress .kubernetes .io /を次のターゲットに書き換えます: /
仕様:
 イングレスクラス名: pipy
 ルール:
 - http :
 パス:
 -バックエンド:
 サービス：
 名前: Ingress - dapr
 ポート:
 番号： 80
 パス: / dapr
 パスタイプ:プレフィックス
終了

httpbinへのアクセスパスは依然として/getですが、アクセス方法はDaprサービスのAPI呼び出しに従う必要があります[2]：リクエストヘッダーでdapr-app-idをhttpbin.httpbinとして指定します。イングレス コントローラーとターゲット アプリケーションは同じ名前空間にないため、アプリケーション ID にはその名前空間を含める必要があります。

結果も正常に返されますが、最終的なアプリケーションがリクエスト ヘッダーでより多くの情報を受け取っていることがわかります。この情報は Daprd ランタイムから取得されます。たとえば、Dapr-Caller-App-Id や "Dapr-Callee-App-Id​ は、要求の開始者と受信者を示します。Forwarded は、要求を開始したホスト名を識別します。トレースが有効になっている場合は、リンクに関連する情報も表示されます (この例では有効になっていません)。

 curl HOST_IP : 80 / dapr / get - H 'dapr-app-id:httpbin.httpbin'
 {
 「引数」 : { } ,
 「ヘッダー」 : {
 "受け入れる" ： "*/*" 、
 「Accept-Encoding」 : 「gzip」 、
 「接続」 ： 「キープアライブ」 、
 "Dapr-App-Id" : "httpbin.httpbin" ,
 "Dapr-Callee-App-Id" : "httpbin" ,
 「Dapr-Caller-App-Id」 : 「ingress」 、
 「転送済み」 : 「for=10.42.0.18;by=10.42.0.18;host=fsm-ingress-pipy-864d8d9c76-4kb7r」 、
 「ホスト」 : 「127.0.0.1:80」 、
 「プロトコル」 : 「HTTP/1.1」 、
 「プロトメジャー」 : 「1」 、
 「プロトマイナー」 : 「1」 、
 「リファラー」 : 「」 、
 "Traceparent" : "00-0000000000000000000000000000000-0000000000000000-00" ,
 「ユーザーエージェント」 : 「curl/7.86.0」 、
 「X-転送ホスト」 : 「fsm-ingress-pipy-864d8d9c76-4kb7r」
 } 、
 「オリジン」 : 「10.42.0.18」 、
 「URL」 : 「http://fsm-ingress-pipy-864d8d9c76-4kb7r/get」
 }

アクセス制御

記事の冒頭で、ソリューション 2 は遅延を招き、複雑さが増すものの、Dapr のサービス ガバナンス機能を使用できることが述べられています。ここではDaprのアクセス制御機能[3]を例に挙げます。

Ingress コントローラーとサンプル アプリケーションをデプロイするときに、dapr.io/config: xxx​ というアノテーションがあることに気づいたかどうかわかりません。このアノテーションは、アプリケーションの Daprd ランタイムの構成を指定します。ランタイムが起動すると、xxx という名前の構成リソースから構成が読み取られます。

次のコマンドを実行して、httpbin アプリケーションのアクセス制御ルールを設定します。デフォルトですべてのリクエストを拒否し、flomesh 名前空間の ID が ingress のアプリケーションのみが GET を介してパス /get にアクセスできるようにします。詳細なアクセス制御設定については、Daprアクセス​​制御の公式ドキュメント[4]を参照してください。

 kubectl apply -n httpbin -f - << EOF
 apiバージョン: dapr.io/v1alpha1
種類:構成
メタデータ:
 名前: httpbinconfig
仕様:
 アクセス制御:
 デフォルトアクション:拒否
 信頼ドメイン: "public"
 ポリシー:
 -アプリID :イングレス
 デフォルトアクション:拒否
 信頼ドメイン: 'public'
 名前空間: "flomesh"
 操作:
 -名前: /取得
 http動詞: [ 'GET' ]
 アクション:許可
終了

設定を適用した後、アプリケーションを再起動する必要があります。

 kubectl ロールアウト 再起動 デプロイ httpbin - n httpbin

再起動が完了するまで待ってから /get パスにアクセスすると、正常に応答します。

 curl HOST_IP : 80 / dapr / get - H 'dapr-app-id:httpbin.httpbin'
 {
 「引数」 : { } ,
 「ヘッダー」 : {
 "受け入れる" ： "*/*" 、
 「Accept-Encoding」 : 「gzip」 、
 「接続」 ： 「キープアライブ」 、
 "Dapr-App-Id" : "httpbin.httpbin" ,
 "Dapr-Callee-App-Id" : "httpbin" ,
 「Dapr-Caller-App-Id」 : 「ingress」 、
 「転送済み」 : 「for=10.42.0.40;by=10.42.0.40;host=fsm-ingress-pipy-864d8d9c76-jctcx」 、
 「ホスト」 : 「127.0.0.1:80」 、
 「プロトコル」 : 「HTTP/1.1」 、
 「プロトメジャー」 : 「1」 、
 「プロトマイナー」 : 「1」 、
 「リファラー」 : 「」 、
 "Traceparent" : "00-0000000000000000000000000000000-0000000000000000-00" ,
 「ユーザーエージェント」 : 「curl/7.86.0」 、
 「X-転送ホスト」 : 「fsm-ingress-pipy-864d8d9c76-jctcx」
 } 、
 「オリジン」 : 「10.42.0.40」 、
 「URL」 : 「http://fsm-ingress-pipy-864d8d9c76-jctcx/get」
 }

ただし、パス /headers​ にアクセスすると、次の応答が返されます: /headers へのアクセスは禁止されています。

 curl HOST_IP:80/dapr/headers -H 'dapr-app-id:httpbin.httpbin'
 {
 "エラーコード": "ERR_DIRECT_INVOKE",
 「メッセージ」: 「呼び出しに失敗しました。ID: httpbin.httpbin、エラー: rpc エラー: コード = PermissionDenied 説明 = アクセス制御ポリシーにより、appid: ingress 操作: ヘッダー 動詞: GET へのアクセスが拒否されました」
 }

要約する

この記事で使用されている 2 つのエントリ ソリューションには、それぞれ長所と短所があります。ソリューション 1 はシンプルなアーキテクチャを備えており、当社でもよく使用されるソリューションです。ソリューション 2 は、エントリ コントローラーを Dapr アプリケーションとして宣言することと同じです。実際、Dapr API を公開しており、実装においてはグローバル アプリケーション ランタイムに似ています。

参考文献

[1] ドキュメント: https://fsm-docs.flomesh.io/docs/demos/ingress_basics

[2] Daprサービス呼び出しAPI: https://docs.dapr.io/developing-applications/building-blocks/service-invocation/howto-invoke-discover-services/

[3] Daprのアクセス制御機能: https://docs.dapr.io/operations/configuration/invoke-allowlist/

[4] Daprアクセス​​制御公式ドキュメント: https://docs.dapr.io/operations/configuration/invoke-allowlist/