Istio ServiceEntry を Cloud Run の GCPBackend に移行する

プレビュー

このプロダクトまたは機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 一般提供前のプロダクトと機能は「現状のまま」ご利用いただけますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

注: このガイドでは、Istio API を使用する Cloud Service Mesh のみをサポートし、 Google Cloud API はサポートしていません。詳細については、Cloud Service Mesh の概要をご覧ください。

このページでは、ServiceEntry から GCPBackend に移行する方法について説明します。Istio のトラフィック管理機能を使用して、スムーズで安全な移行を実現する方法を示します。

GCPBackend に移行すると、次のようなメリットがあります。

1. アプリケーション コードの簡素化: アプリケーションに手動で IAM JWT を挿入する必要がなくなるため、複雑さと潜在的なエラーが軽減されます。
2. セキュリティの強化: 自動 IAM JWT 挿入を利用して、GKE と Cloud Run 間の通信をより安全にします。
3. シームレスな移行: トラフィック分割とミラーリングを使用して、アプリケーションを中断することなくトラフィックを安全に移行します。
4. 管理性の向上: 構成と管理が簡素化されます。

始める前に

以降のセクションでは、次の作業が完了していることを前提としています。

1. Cloud Service Mesh が有効になっている GKE クラスタ。
2. Istio Service Entry としての Cloud Run サービス。
3. 構成済みの GCPBackend リソース。

既存の VirtualService を作成または変更して、ServiceEntry と GCPBackend の両方を宛先として含める

トラフィック分割を使用して、ServiceEntry から GCPBackend にトラフィックを徐々にシフトできます。まず、GCPBackend に転送されるトラフィックの割合を少量から始めて、問題がないかモニタリングしながら徐々に増やします。

次の例では、リクエストの 10% を GCPBackend に移行します。

cat <<EOF > virtual-service.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: cr-gcpbackend-migration
  namespace: NAMESPACE
spec:
  hosts:
  - cr-service-entry.com
  http:
  - route:
    - destination:
        host: cr-gcpbackend.com
      weight: 10 # 10% traffic to gcp backend.
    - destination:
        host: cr-service-entry.com
      weight: 90 # 90% traffic to service entry
EOF
kubectl apply -f virtual-service.yaml

ここで

• NAMESPACE は名前空間名です。

この例では、次のようになります。

• VIRTUAL_SERVICEE は cr-gcpbackend-migration です。
• SERVICE_ENTRY_HOSTNAME は cr-service-entry.com です。
• GCP_BACKEND_HOSTNAME は =cr-gcpbackend.com です。

（省略可）トラフィック ミラーリング用に VirtualService を構成する

スムーズな移行をさらに確実にするために、トラフィック ミラーリングを構成して、トラフィックのコピーを GCPBackend に送信し、主に ServiceEntry にトラフィックを転送できます。これにより、プライマリ トラフィック フローに影響を与えることなく、GCPBackend 構成のテストと検証を行うことができます。詳細については、Istio Virtual Service API をご覧ください。

機能を検証する

アプリケーション ログまたは Cloud Service Mesh 指標を参照して、$SERVICE_ENTRY_HOSTNAME へのリクエストのエラー率を確認します。エラーは発生しません。

アプリケーションの外部でテストするには、curl クライアントをデプロイします。GCPBackend API を使用してリクエストが CloudRun に転送される場合、Cloud Service Mesh が自動的に IAM トークンを接続するため、リクエストに IAM トークンを明示的に接続する必要はありません。

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: testcurl
  namespace: default
spec:
  containers:
  - name: curl
    image: curlimages/curl
    command: ["sleep", "3000"]
EOF

kubectl exec testcurl -c curl -- curl "$SERVICE_ENTRY_HOSTNAME"

出力は有効な HTTP 200 レスポンスになります。