Cloud Service Mesh での Istio スケーリングの問題の解決

このセクションでは、Cloud Service Mesh の一般的な問題とその解決方法について説明します。さらにサポートが必要な場合は、サポートの利用をご覧ください。

スケーリング ファクタ

Istiod は、有効期間が長い gRPC ストリームを使用して各サイドカーに構成を送信します。スケーリングに影響する特性がいくつかあります。

  • 生成する構成のサイズ:
    • Service / Pod と Istio リソースの合計数
    • 大規模な場合は、サイドカーの設定を調整して、構成サイズを減らします。
  • 環境の変化率:
    • 新しいサービスが作成されるか、Istio 構成が変更されると、完全な更新がプロキシに送信されます。
    • 新しいエンドポイントを追加すると、増分更新のみが送信されるため、パフォーマンスが低下します。
  • 構成が生成されるプロキシの数。
    • サイドカーを含むゲートウェイと Pod の数によって影響を受けます。

スケーリングに関する考慮事項

Istio は垂直方向（大きなリクエスト）と水平方向（複数のレプリカ）で適切にスケーリングされます。CPU の使用を過度に制限しないでください。Istio が CPU の上限に達すると、構成の配布に影響を及ぼす可能性があります。パフォーマンスの問題が発生した場合は、最新バージョンの Cloud Service Mesh へのアップグレードを検討してください。これにより、パフォーマンスの最適化が行われます。

負荷分散されていない負荷

クラスタのサイズを大幅に変更したとき、長時間存続する接続が原因で一時的に負荷が分散されない可能性があります。この問題は、最大接続時間を 30 分に設定することによって回避できます。これにより、gRPC config stream closed: 13 などのエラー メッセージが Envoy に出力され、負荷が自然に分散されます。

この問題は、Istiod のレプリカを複数作成することで軽減できます（デフォルトでは 2 つのレプリカがあります）。クラスタの大幅なスケールアップが予想される場合は、事前にスケーリングしてください。