問題タブ [linkerd]

最近、Nginx イングレス コントローラーを使用して k8s クラスター内にいくつかのマイクロサービスを構築しましたが、それらは正常に動作しています。

マイクロサービス間の通信を扱うときに、gRPC を試してみましたが、うまくいきました。次に、マイクロサービス A -> gRPC -> マイクロサービス B の場合、すべてのリクエストがマイクロサービス B の 1 つのポッドでのみ発生したことを発見しました (たとえば、マイクロサービス B で使用できる合計 10 のポッド)。リクエストをマイクロサービス B のすべてのポッドに負荷分散するために、linkerd を試してみましたが、うまくいきました。しかし、gRPC が内部エラー (例: 100 件のリクエストのうち 1 件のエラー) を生成することがあることに気づき、k8s DNS の方法 (例: my-svc.my-namespace.svc.cluster-domain.example) を使用するように変更しました。その後、リクエストは決して失敗しません。gRPC と linkerd を保持し始めました。

その後、istioに興味を持ちました。クラスターに正常にデプロイしました。ただし、常に独自のロード バランサーが作成されることがわかりました。これは、既存の Nginx イングレス コントローラーとはあまり一致しません。

さらに、プロメテウスとグラファナ、そしてk9sも試してみました。これらのツールを使用すると、ポッドの CPU とメモリの使用状況をよりよく理解できます。

ここで、理解したいいくつかの質問があります:-

1. クラスター リソースを監視する必要がある場合は、prometheus、grafana、および k9s を使用します。それらはサービス メッシュ (linkerd、istio など) と同じ監視の役割を果たしていますか?
2. k8s DNS がすでにロード バランシングを達成できる場合、サービス メッシュはまだ必要ですか?
3. サービス メッシュなしで k8s を使用している場合、通常のプラクティスより遅れていますか?

実は私もサービスメッシュを毎日使いたいと思っています。

ヘッダーに基づいてポッドにトラフィックをルーティングしたいと思います-フォールバックを使用します。

望ましい結果は、ヘッダー値を使用して、同じサービスの複数のバージョンをデプロイおよびルーティングできる k8s クラスターです。

svcA svcB svcC

これらの各サービス (git リポジトリのメイン ブランチ) は、デフォルトの名前空間にデプロイされるか、「main」というラベルが付けられます。各サービスの任意の機能ブランチも、独自の名前空間にデプロイするか、ブランチ名でラベル付けしてデプロイできます。

理想的には、ヘッダーX-svcAをブランチ名と一致する値に設定することで、すべてのトラフィックを一致する名前空間またはラベルにルーティングします。そのような名前空間またはラベルがない場合は、トラフィックをデフォルト (メイン) ポッドにルーティングします。

最初の質問 - istio または linkerd でもこれ (またはそのようなもの) は可能ですか?

AWS EKS クラスターに Linkerd をインストールしようとしています。

すべて正常に動作しますが、Linkerd ダッシュボードにアクセスできません..

私の IDE は AWS Cloud9 で、指示に従いました。

1. curl -sL https://run.linkerd.io/install | sh

2. linkerd version

3. linkerd check --pre

4. linkerd install | kubectl apply -f -

5. linkerd check -> **All Green**

6. linkerd viz install | kubectl apply -f -

7. linkerd viz dashboard --port 33335 &

ブラウザで http://localhost:33335 にアクセスして、ダッシュボードを表示します

http://localhost:33335 にアクセスすると、ERR_CONNECTION_REFUSED

チュートリアルにはダッシュボードが表示されますが、できません...</p>

ありがとうございました。