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

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

スケーリング係数

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

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

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

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

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

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

この問題は、Istiod の複数のレプリカ（デフォルトは 2 つのレプリカ）を使用することで発生します。クラスタの過度なスケールアップが予想される場合は、事前スケーリングを行ってください。