Istio ServiceEntry を Cloud Run の GCPBackend に移行する
このページでは、ServiceEntry から GCPBackend に移行する方法について説明します。Istio のトラフィック管理機能を使用して、スムーズで安全な移行を実現する方法を示します。
GCPBackend に移行すると、次のようなメリットがあります。
- アプリケーション コードの簡素化: アプリケーションに手動で IAM JWT を挿入する必要がなくなるため、複雑さとエラーが生じる可能性を削減できます。
 - セキュリティの強化: 自動 IAM JWT 挿入を利用して、GKE と Cloud Run 間の通信をより安全にします。
 - シームレスな移行: トラフィック分割とミラーリングを使用して、アプリケーションを中断することなくトラフィックを安全に移行します。
 - 管理性の向上: 構成と管理が合理化されます。
 
始める前に
以降のセクションでは、次のものがあることを前提としています。
- Cloud Service Mesh が有効になっている GKE クラスタ。
 - Istio ServiceEntry。
 - Cloud Run サービス用に構成された GCPBackend リソース。
 
既存の VirtualService を作成または変更して、ServiceEntry と GCPBackend の両方を宛先として含める
トラフィック分割を使用して、ServiceEntry から GCPBackend にトラフィックを徐々にシフトできます。まず、GCPBackend に少量のトラフィックを転送することから始めて、問題がないかモニタリングしながら徐々に増やしていきます。
次の例では、リクエストの 10% を GCPBackend に移行します。
cat <<EOF > virtual-service.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: gcpbackend-migration
  namespace: NAMESPACE
spec:
  hosts:
  - service-entry.com
  http:
  - route:
    - destination:
        host: gcpbackend.com
      weight: 10 # 10% traffic to gcp backend.
    - destination:
        host: service-entry.com
      weight: 90 # 90% traffic to service entry
EOF
kubectl apply -f virtual-service.yaml
ここで
- NAMESPACE は名前空間名です。
 
この例では
- VIRTUAL_SERVICE は 
gcpbackend-migrationです。 - SERVICE_ENTRY_HOSTNAME は 
service-entry.comです。 - GCP_BACKEND_HOSTNAME は 
gcpbackend.comです。 
(省略可)トラフィック ミラーリング用に VirtualService を構成する
スムーズな移行をさらに確実にするには、トラフィックを引き続き主に ServiceEntry に転送しながら、トラフィック ミラーリングを構成してトラフィックのコピーを GCPBackend に送信することができます。これにより、主なトラフィックの流れに影響を与えることなく、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 レスポンスになります。