トラフィック管理 FAQ

ルールは kubectl get virtualservice -o yaml を使用して表示できます。

Istioはデフォルトですべてのポートでインバウンドトラフィックをキャプチャします。 キャプチャするポートの明示的なリストを指定するには、traffic.sidecar.istio.io/includeInboundPorts Podアノテーションを使用します。または、バイパスするポートのリストを指定するには、traffic.sidecar.istio.io/excludeOutboundPorts を使用して、この動作をオーバーライドできます。

これらのDestinationRule設定はどちらも、相互TLSトラフィックを送信します。 ISTIO_MUTUALを使用すると、Istio証明書が自動的に使用されます。 MUTUALの場合、鍵、証明書、および信頼できるCAを設定する必要があります。 これにより、Istio以外のアプリケーションとの相互TLSを開始できます。

はい、IstioはIstio 1.10以降、これらのワークロードを完全にサポートしています。

ホスト、TLS、および完全パスベースのマッチングを使用した単純なイングレス仕様は、ルートルールを必要とせずにそのまま使用できます。 ただし、イングレスリソースで使用されるパスには、.文字を含めないでください。

たとえば、次のイングレスリソースは、example.comホストへのリクエストと、URLとして/helloworldを一致させます。

$ kubectl create -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: simple-ingress
  annotations:
    kubernetes.io/ingress.class: istio
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /helloworld
        pathType: Prefix
        backend:
          service:
            name: myservice
            port:
              number: 8000
EOF

ただし、次のルールは、パスとingress.kubernetes.ioアノテーションに正規表現を使用しているため、機能しません。

$ kubectl create -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: this-will-not-work
  annotations:
    kubernetes.io/ingress.class: istio
    # Ingress annotations other than ingress class will not be honored
    ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /hello(.*?)world/
        pathType: Prefix
        backend:
          service:
            name: myservice
            port:
              number: 8000
EOF

CORS設定を適用した後、一見何も起こらなかったように見え、何が問題だったのか疑問に思うかもしれません。 CORSは、設定時に混乱を招くことが多い、一般的に誤解されているHTTPの概念です。

これを理解するには、一歩下がってCORSとは何か、そしていつ使用すべきかを理解するのに役立ちます。 デフォルトでは、ブラウザはスクリプトによって開始された「クロスオリジン」リクエストに制限を設けています。 これにより、たとえば、Webサイトattack.example.comがbank.example.comにJavaScriptリクエストを行い、ユーザーの機密情報を盗むことを防ぎます。

このリクエストを許可するには、bank.example.comはattack.example.comがクロスオリジンリクエストを実行することを許可する必要があります。 これがCORSの出番です。 Istio対応クラスターでbank.example.comを提供している場合、これを許可するようにcorsPolicyを設定できます。

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: bank
spec:
  hosts:
  - bank.example.com
  http:
  - corsPolicy:
      allowOrigins:
      - exact: https://attack.example.com
...

この場合、単一のオリジンを明示的に許可します。 ワイルドカードは、機密性の低いページでは一般的です。

これを行った後、よくある間違いは、curl bank.example.com -H "Origin: https://attack.example.com"のようなリクエストを送信し、リクエストが拒否されることを期待することです。 ただし、curlや他の多くのクライアントは、CORSがブラウザの制約であるため、拒否されたリクエストを確認しません。 CORS設定は、レスポンスにAccess-Control-*ヘッダーを追加するだけです。 レスポンスが満足できない場合にリクエストを拒否するのは、クライアント（ブラウザ）次第です。 ブラウザでは、これはプリフライトリクエストによって行われます。

現在、IstioはTCPベースのプロトコルをサポートしています。 さらに、Istioは、httpやmysqlなどの他のプロトコルにルーティングやメトリックなどの機能を提供します。

すべてプロトコルのリスト、およびプロトコルの設定方法については、プロトコル選択ドキュメントをご覧ください。