4

最近、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 を使用している場合、通常のプラクティスより遅れていますか?

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

4

2 に答える 2

4

簡単な答えは

Kubernetes サーバーのサービス メッシュは必要ありません

今あなたの質問に答えるために

クラスター リソースを監視する必要がある場合は、prometheus、grafana、および k9s を使用します。それらはサービス メッシュ (linkerd、istio など) と同じ監視の役割を果たしていますか?

K9s は、cli ツールの単なる代替であるkubectlcli ツールです。監視ツールではありません。Prometheus と grafana は、アプリケーション (ポッド) によって提供されるデータを使用する必要がある監視ツールであり、チャート、グラフなどとして視覚化できる時系列データを構築します。ただし、アプリケーションは監視データを Prometheus に提供する必要があります。サービス メッシュはサイドカーを使用し、監視に役立つデフォルトのメトリクスを提供する場合がありますnumber of requests handled in a second。アプリケーションは、メトリクスの知識や実装を持っている必要はありません。したがって、サービス メッシュはオプションであり、監視や承認などの一般的なものをオフロードします。

k8s DNS がすでにロード バランシングを達成できる場合、サービス メッシュはまだ必要ですか?

ロード バランシングにサービス メッシュは必要ありません。クラスターで複数のサービスを実行していて、すべてのサービスに単一のエントリ ポイントを使用してメンテナンスを簡素化し、コストを節約したい場合は、Nginx、Traefik、HAProxy などの Ingress コントローラーが使用されます。また、Istio などのサービス メッシュには、独自のイングレス コントローラーが付属しています。

サービス メッシュなしで k8s を使用している場合、通常のプラクティスより遅れていますか?

いいえ、現在サービス メッシュがなく、まだ Kubernetes を使用しているクラスターが存在する可能性があります。

将来、Kubernetes はサービス メッシュからいくつかの機能をもたらす可能性があります。

于 2021-01-27T06:06:55.593 に答える