Sidecar

Sidecar は、接続されているワークロードインスタンスとの送受信通信を仲介するサイドカープロキシの設定を記述します。デフォルトでは、Istio はメッシュ内のすべてのワークロードインスタンスに到達するために必要な設定、およびワークロードに関連付けられているすべてのポートでトラフィックを受け入れるために必要な設定で、メッシュ内のすべてのサイドカープロキシをプログラムします。Sidecar 設定により、プロキシがワークロードとの間でトラフィックを転送するときに受け入れるポートとプロトコルのセットを微調整できます。さらに、ワークロードインスタンスからのアウトバウンドトラフィックを転送するときに、プロキシが到達できるサービスのセットを制限することも可能です。

メッシュ内のサービスと設定は、1つ以上の名前空間（例：Kubernetesの名前空間またはCFのorg/space）に編成されます。名前空間内のSidecar設定は、workloadSelectorフィールドを使用して選択された、同じ名前空間内の1つ以上のワークロードインスタンスに適用されます。workloadSelectorがない場合、同じ名前空間内のすべてのワークロードインスタンスに適用されます。ワークロードインスタンスに適用するSidecar設定を決定する際には、workloadSelectorを持たないSidecar設定よりも、このワークロードインスタンスを選択するworkloadSelectorを持つリソースが優先されます。

注記 1：名前空間ごとに、その名前空間内のすべてのPodのデフォルトを指定するworkloadSelectorを持たないSidecar設定は1つだけ存在できます。名前空間全体のサイドカーには、名前defaultを使用することをお勧めします。特定の名前空間に複数のセレクタなしのSidecar設定が存在する場合、システムの動作は定義されていません。2つ以上のSidecar設定がworkloadSelectorを使用して同じワークロードインスタンスを選択する場合、システムの動作は定義されていません。

注記 2：MeshConfig ルート名前空間内のSidecar設定は、デフォルトで、Sidecar設定のないすべての名空間へ適用されます。このグローバルデフォルトのSidecar設定には、workloadSelectorを含めるべきではありません。

注記 3：ゲートウェイはIstioプロキシであるにもかかわらず、Sidecarはゲートウェイには適用されません。

以下の例は、istio-configと呼ばれるルート名前空間でグローバルデフォルトのSidecar設定を宣言し、すべての名空間のサイドカーで、同じ名前空間内の他のワークロードとistio-system名前空間内のサービスへのアウトバウンドトラフィックのみを許可するように設定します。

apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
  name: default
  namespace: istio-config
spec:
  egress:
  - hosts:
    - "./*"
    - "istio-system/*"

以下の例は、prod-us1名前空間でSidecar設定を宣言し、上記で定義されたグローバルデフォルトをオーバーライドし、名前空間内のサイドカーで、prod-us1、prod-apis、およびistio-system名前空間のパブリックサービスへのアウトバウンドトラフィックを許可するように設定します。

apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
  name: default
  namespace: prod-us1
spec:
  egress:
  - hosts:
    - "prod-us1/*"
    - "prod-apis/*"
    - "istio-system/*"

次の例は、prod-us1名前空間で、ラベルapp: ratingsを持ち、ratings.prod-us1サービスに属するすべてのPodに対するSidecar設定を宣言します。ワークロードはポート9080でインバウンドHTTPトラフィックを受け入れます。その後、トラフィックは、Unixドメインソケットをリッスンしている接続されたワークロードインスタンスに転送されます。アウトバウンド方向では、istio-system名前空間に加えて、サイドカープロキシはprod-us1名前空間のサービスに対してポート9080にバインドされたHTTPトラフィックのみを転送します。

apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
  name: ratings
  namespace: prod-us1
spec:
  workloadSelector:
    labels:
      app: ratings
  ingress:
  - port:
      number: 9080
      protocol: HTTP
      name: somename
    defaultEndpoint: unix:///var/run/someuds.sock
  egress:
  - port:
      number: 9080
      protocol: HTTP
      name: egresshttp
    hosts:
    - "prod-us1/*"
  - hosts:
    - "istio-system/*"

ワークロードがIPTablesベースのトラフィックキャプチャなしでデプロイされている場合、Sidecar設定は、ワークロードインスタンスに接続されたプロキシのポートを設定する唯一の方法です。次の例は、prod-us1名前空間で、ラベルapp: productpageを持ち、productpage.prod-us1サービスに属するすべてのPodに対するSidecar設定を宣言します。これらのPodがIPテーブルルール（つまり、istio-initコンテナ）なしでデプロイされ、プロキシメタデータISTIO_META_INTERCEPTION_MODEがNONEに設定されていると仮定すると、以下の仕様により、そのようなPodはポート9080でHTTPトラフィック（Istio相互TLSでラップされている）を受信し、127.0.0.1:8080をリッスンしているアプリケーションに転送できます。また、アプリケーションが127.0.0.1:3306のバックエンドMySQLデータベースと通信し、それがmysql.foo.com:3306の外部ホストされているMySQLサービスにプロキシされることも許可します。

apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
  name: no-ip-tables
  namespace: prod-us1
spec:
  workloadSelector:
    labels:
      app: productpage
  ingress:
  - port:
      number: 9080 # binds to proxy_instance_ip:9080 (0.0.0.0:9080, if no unicast IP is available for the instance)
      protocol: HTTP
      name: somename
    defaultEndpoint: 127.0.0.1:8080
    captureMode: NONE # not needed if metadata is set for entire proxy
  egress:
  - port:
      number: 3306
      protocol: MYSQL
      name: egressmysql
    captureMode: NONE # not needed if metadata is set for entire proxy
    bind: 127.0.0.1
    hosts:
    - "*/mysql.foo.com"

そして、mysql.foo.com:3306へのルーティングのための関連するサービスエントリ。

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-svc-mysql
  namespace: ns1
spec:
  hosts:
  - mysql.foo.com
  ports:
  - number: 3306
    name: mysql
    protocol: MYSQL
  location: MESH_EXTERNAL
  resolution: DNS

単一のプロキシでトラフィックキャプチャモードを混在させることも可能です。たとえば、内部サービスが192.168.0.0/16サブネット上にある設定を考えてみましょう。そのため、VMには192.168.0.0/16サブネット上のすべてのアウトバウンドトラフィックをキャプチャするようにIPテーブルが設定されています。VMには、インバウンドトラフィック用の172.16.0.0/16サブネット上に追加のネットワークインターフェースがあると仮定します。次のSidecar設定により、VMは172.16.0.0/16サブネットから到着するトラフィックに対して172.16.1.32:80（VMのIP）でリスナーを公開できます。

注記：VMのプロキシ上のISTIO_META_INTERCEPTION_MODEメタデータには、REDIRECTまたはTPROXYという値が含まれている必要があります。これは、IPテーブルベースのトラフィックキャプチャがアクティブであることを意味します。

apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
  name: partial-ip-tables
  namespace: prod-us1
spec:
  workloadSelector:
    labels:
      app: productpage
  ingress:
  - bind: 172.16.1.32
    port:
      number: 80 # binds to 172.16.1.32:80
      protocol: HTTP
      name: somename
    defaultEndpoint: 127.0.0.1:8080
    captureMode: NONE
  egress:
    # use the system detected defaults
    # sets up configuration to handle outbound traffic to services
    # in 192.168.0.0/16 subnet, based on information provided by the
    # service registry
  - captureMode: IPTABLES
    hosts:
    - "*/*"

次の例は、prod-us1名前空間で、ラベルapp: ratingsを持ち、ratings.prod-us1サービスに属するすべてのPodに対するSidecar設定を宣言します。サービスはポート8443でインバウンドHTTPSトラフィックを受け入れ、サイドカープロキシは指定されたサーバー証明書を使用して一方向TLSを終了します。その後、トラフィックは、Unixドメインソケットをリッスンしている接続されたワークロードインスタンスに転送されます。特定のポートでmTLSモードを「DISABLE」に設定するために、PeerAuthenticationポリシーが設定されていることが期待されます。この例では、ポート80でmTLSモードが無効になっています。この機能は現在実験段階です。

apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
  name: ratings
  namespace: prod-us1
spec:
  workloadSelector:
    labels:
      app: ratings
  ingress:
  - port:
      number: 80
      protocol: HTTPS
      name: somename
    defaultEndpoint: unix:///var/run/someuds.sock
    tls:
      mode: SIMPLE
      privateKey: "/etc/certs/privatekey.pem"
      serverCertificate: "/etc/certs/servercert.pem"
---
apiVersion: v1
kind: Service
metadata:
  name: ratings
  labels:
    app: ratings
    service: ratings
spec:
  ports:
  - port: 8443
    name: https
    targetPort: 80
  selector:
    app: ratings
---
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: ratings-peer-auth
  namespace: prod-us1
spec:
  selector:
    matchLabels:
      app: ratings
  mtls:
    mode: STRICT
  portLevelMtls:
    80:
      mode: DISABLE

トラフィックキャプチャとアプリケーションへのトラフィックの転送方法の設定に加えて、インバウンド接続プールの設定を制御することも可能です。デフォルトでは、IstioはDestinationRulesから接続プールの設定をクライアント（サービスへのアウトバウンド接続の場合）とサーバー（サービスインスタンスへのインバウンド接続の場合）の両方にプッシュします。SidecarのInboundConnectionPoolとポートごとのConnectionPool設定を使用すると、クライアントすべてにプッシュされる設定とは別に、サーバーの接続プールを制御できます。

apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
  name: connection-pool-settings
  namespace: prod-us1
spec:
  workloadSelector:
    labels:
      app: productpage
  inboundConnectionPool:
      http:
        http1MaxPendingRequests: 1024
        http2MaxRequests: 1024
        maxRequestsPerConnection: 1024
        maxRetries: 100
  ingress:
  - port:
      number: 80
      protocol: HTTP
      name: somename
    connectionPool:
      http:
        http1MaxPendingRequests: 1024
        http2MaxRequests: 1024
        maxRequestsPerConnection: 1024
        maxRetries: 100
      tcp:
        maxConnections: 100

Sidecar

IstioIngressListener

IstioEgressListener

Workloadセレクタ

OutboundTrafficPolicy

Sidecarポート

OutboundTrafficPolicy.Mode

キャプチャモード