設定スコープ

4分の読書時間ページのテスト

サービスメッシュをプログラムするために、Istioコントロールプレーン（Istiod）は、ServiceやNodeなどのコアKubernetesタイプ、およびGatewayなどのIstio独自のタイプを含む、さまざまな構成を読み取ります。これらは、データプレーンに送信されます（詳細については、アーキテクチャを参照してください）。

デフォルトでは、コントロールプレーンはすべての名前空間のすべての構成を読み取ります。各プロキシインスタンスも、すべての名前空間の構成を受け取ります。これには、メッシュに登録されていないワークロードに関する情報も含まれます。

このデフォルト設定は、すぐに正しい動作を保証しますが、スケーラビリティのコストが伴います。各構成には、維持および最新の状態に保つためのコスト（主にCPUとメモリ）があります。大規模な環境では、過剰なリソース消費を避けるために、構成スコープを制限することが重要です。

スコープメカニズム

Istioは、さまざまなユースケースに対応するために、構成のスコープを制御するのに役立ついくつかのツールを提供しています。要件に応じて、これらを単独で使用することも、組み合わせて使用することもできます。

Sidecarは、特定のワークロードが構成のセットをインポートするためのメカニズムを提供します。
exportToは、構成をワークロードのセットにエクスポートするためのメカニズムを提供します。
discoverySelectorsは、Istioが構成のセットを完全に無視できるようにするメカニズムを提供します。

`Sidecar` インポート

Sidecarのegress.hostsフィールドを使用すると、インポートする構成のリストを指定できます。指定された条件に一致する構成のみが、Sidecarリソースの影響を受けるサイドカーに表示されます。

例：

apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
  name: default
spec:
  egress:
  - hosts:
    - "./*" # Import all configuration from our own namespace
    - "bookinfo/*" # Import all configuration from the bookinfo namespace
    - "external-services/example.com" # Import only 'example.com' from the external-services namespace

`exportTo`

IstioのVirtualService、DestinationRule、およびServiceEntryは、spec.exportToフィールドを提供します。同様に、Serviceはnetworking.istio.io/exportToアノテーションを使用して構成できます。

ワークロードの所有者がどのような依存関係を持つかを制御できるSidecarとは異なり、exportToは逆の方法で機能し、サービス所有者が独自のサービスの可視性を制御できるようにします。

たとえば、この構成では、details Serviceは、それ自身の名前空間とclient名前空間でのみ表示されます。

apiVersion: v1
kind: Service
metadata:
  name: details
  annotations:
    networking.istio.io/exportTo: ".,client"
spec: ...

`DiscoverySelectors`

上記の制御はワークロードまたはサービスオーナーのレベルで動作しますが、DiscoverySelectorsは、構成の可視性に対するメッシュ全体の制御を提供します。ディスカバリーセレクターを使用すると、コントロールプレーンに表示する必要がある名前空間の条件を指定できます。一致しない名前空間は、コントロールプレーンによって完全に無視されます。

これは、インストール中にmeshConfigの一部として構成できます。例：

meshConfig:
  discoverySelectors:
    - matchLabels:
        # Allow any namespaces with `istio-discovery=enabled`
        istio-discovery: enabled
    - matchLabels:
        # Allow "kube-system"; Kubernetes automatically adds this label to each namespace
        kubernetes.io/metadata.name: kube-system

よくある質問

特定の構成のコストを理解するにはどうすればよいですか？

構成をスコープダウンするための最良の投資収益率を得るには、各オブジェクトのコストを理解すると役立つ場合があります。残念ながら、簡単な答えはありません。スケーラビリティは、多数の要因に依存します。ただし、いくつかの一般的なガイドラインがあります。

構成の変更は、再計算が必要なため、Istioではコストがかかります。Endpointsの変更（通常はPodのスケールアップまたはスケールダウンによる）は大幅に最適化されていますが、他のほとんどの構成は非常にコストがかかります。コントローラーがオブジェクトを常に変更している場合（時々、誤って発生します！）、これは特に有害になる可能性があります。どの構成が変更されているかを検出するためのツールを次に示します。

Istiodは、Push debounce stable 1 for config Gateway/default/gateway: ..., full=trueのように各変更をログに記録します。これは、default名前空間のGatewayオブジェクトが変更されたことを示しています。full=falseは、Endpointなどの最適化された更新を表します。注：ServiceとEndpointsへの変更はすべてServiceEntryとして表示されます。
Istiodは、各変更についてpilot_k8s_cfg_eventsおよびpilot_k8s_reg_eventsメトリクスを公開します。
kubectl get <resource> --watch -oyaml --show-managed-fieldsは、オブジェクト（またはオブジェクト）への変更を表示して、何が、誰によって変更されているかを理解するのに役立ちます。

ヘッドレスサービス（HTTPとして宣言されているもの以外）は、インスタンスの数に応じてスケーリングされます。これにより、大規模なヘッドレスサービスはコストがかかり、exportToまたは同等のものを使用して除外するのに適しています。

スコープ外のサービスに接続するとどうなりますか？

スコーピングメカニズムのいずれかを通じて除外されたサービスに接続する場合、データプレーンは宛先に関する情報を何も知らないため、一致しないトラフィックとして扱われます。

ゲートウェイについてはどうですか？

ゲートウェイはexportToとDiscoverySelectorsを尊重しますが、Sidecarオブジェクトはゲートウェイに影響を与えません。ただし、サイドカーとは異なり、ゲートウェイにはデフォルトでクラスター全体の構成はありません。代わりに、各構成はゲートウェイに明示的に添付されるため、この問題はほぼ回避されます。

ただし、現在、データプレーン構成の一部（Envoy用語では「クラスター」）は、明示的に参照されていない場合でも、常にクラスター全体に送信されます。