問題タブ [istio]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
docker - bookinfo サンプルアプリが istio でクラッシュする
istio を評価し、istio のインストールで提供される bookinfo サンプル アプリを展開しようとしています。そうしているうちに、次の問題に直面しています。
問題：
istio クライアントとコントロール プレーン コンポーネントのインストールは問題なく完了しました。
コントロール プレーンも正常に起動します。
しかし、bookinfo アプリを起動すると、アプリのプロキシ初期化コンテナーがクラッシュし、不可解な「iptables: Chain already exists」というログ メッセージが表示されます。
trace - Istio トレースの問題
Istio サイトの bookinfo アプリに似た簡単な 3 層サービスを作成しました。zipkin または jaeger を使用したトレースを除いて、すべて正常に動作しているようです。
明確にするために、私は 3 つのサービス S1、S2、S3 を持っています。これらはすべて、かなり似ていて些細な要求を下流に渡し、何らかの作業を行っています。トレースに S1 と S2 が表示されますが、S3 は表示されません。これをもう少し絞り込みました。Istio バージョン 0.5.0 を使用すると、トレースに S3 も表示されますが、しばらくしてからですが、Istio バージョン 0.5.1 では S1 と S2 しか表示されません。トレースでは、サービスが正常に機能しており、呼び出しが S3 までずっと伝播しているにもかかわらずです。
私が見ることができる唯一の違いは、これが問題であるかどうかはわかりませんが、istio バージョン 0.5.0 を使用した S3 の istio-proxy でのこの出力ですが、0.5.1 ではありません。
"GET /readiness HTTP/1.1" 200 - 0 39 1 1 "-" "kube-probe/1.9+" "0969a5a3-f6c0-9f8e-a449-d8617c3a5f9f" "10.XX18:8080" "127.0.0.1:8080"
必要に応じて、正確な yaml ファイルを追加できます。また、istio ドキュメントに示されているように、トレースが istio-proxy から来ていると想定されているかどうかはわかりませんが、私の場合、istio-proxy は表示されず、istio-ingress のみが表示されます。
kubernetes - ヘッダーユーザーエージェントに基づくIstio RouteRuleが機能しない
minikube で 2 つのサービスを実行していFooますBar。サービスにアクセスすると、サービスにデータを取得するFooように要求します。サービスには と の 2 つのバージョンがあります。すべてのリクエストを次の場所にルーティングするようにデフォルト設定をセットアップしました。BarBar"1.0""2.0"RouteRuleistio"1.0"
正常に動作し、すべてのリクエストが に転送されていることがわかります"1.0"。RouteRuleここで、ヘッダーに基づいて別のヘッダーを追加したいので、Chromeブラウザーからのすべてのリクエストは次の場所に転送され"2.0"ます。
そして、それは機能しません。すべての要求は引き続き にルーティングされ"1.0"ます。RouteRuleが作成されていることがわかります。
UserAgentブラウザの開発者ツールで、ヘッダーが存在することがわかります。に転送されない理由を確認するためにリクエストをデバッグするにはどうすればよい"2.0"ですか?
grpc - envoy、nomad、consul を使用して gRPC リクエストの動的ルーティングを構成する方法
nomadを使用して、 gRPCエンドポイントを提供するアプリケーションをタスクとしてデプロイします。その後、タスクはnomad の service stanzaを使用してConsulに登録されます。
アプリケーションのルーティングは、envoy proxyを使用して実現されます。IP で負荷分散された中央の envoy インスタンスを実行しています10.1.2.2。
host現在、ルーティング先のエンドポイント/タスクの決定はヘッダーに基づいており、すべてのタスクは の下にサービスとして登録されています<$JOB>.our.cloud。これは 2 つの問題につながります。
サービスにアクセスするときは、ロードバランサー IP の DNS 名を登録する必要があります。これにより、次の
/etc/hostsようなエントリが生成されます。この問題は を使用することで部分的に軽減されます
dnsmasqが、新しいサービスを追加するときはまだ少し面倒です同じ gRPC サービスを提供する複数のサービスを同時に実行することはできません。たとえば、サービスの新しい実装をテストすることにした場合
job、同じ名前で同じサービスを実行する必要があり、gRPC サービス ファイルで定義されているすべてのサービスを実装する必要があります。
私たちが議論してきた可能な解決策はtags、serviceスタンザの を使用して、提供された gRPC サービスを定義するタグを追加することです。
しかし、これはConsulによって推奨されていません:
今、私たちは、のようなタグでそれを行うことを考えていましたgrpc-my-company-firstpackage__ServiceA...これは本当に嫌に見えますが:-(
だから私の質問は：
- 誰かがそのようなことをしたことがありますか？
- その場合、Consul で自動検出される gRPC サービスにルーティングする方法に関する推奨事項は何ですか?
- 誰かがこれについて他のアイデアや洞察を持っていますか?
- これは、たとえばistioでどのように達成されますか?