Cloud Service Mesh と Traffic Director は Cloud Service Mesh になりました。詳細については、Cloud Service Mesh の概要をご覧ください。

Istio ServiceEntry を Compute Engine VM の GCPBackend に移行する

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

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

エンドポイント検出 - VM インスタンスが追加または削除されると、Backend Service の VM エンドポイントが自動的に更新されます。
一元化されたヘルスチェック - VM エンドポイントがヘルスチェックされ、異常なバックエンドから正常なバックエンドにトラフィックが自動的に転送されます。
グローバルロードバランシングと高度なロードバランシングアルゴリズム - VM エンドポイントは複数のリージョンにデプロイできます。ロードバランシングアルゴリズムを使用して、これらのリージョン全体のロードバランシング動作を構成します。詳細については、https://cloud.google.com/service-mesh/docs/service-routing/advanced-load-balancing-overview と https://cloud.google.com/service-mesh/docs/service-routing/advanced-load-balancing-overview をご覧ください。
シームレスな移行: トラフィック分割とミラーリングを使用して、アプリケーションを中断することなくトラフィックを安全に移行します。
管理性の向上: 構成と管理が簡素化されます。

始める前に

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

Cloud Service Mesh が有効になっている GKE クラスタ。
Istio Service Entry。
Compute Engine VM 用に 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 を構成する

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

機能を検証する

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

アプリケーションの外部でテストするには、curl クライアントをデプロイします。リクエストが GCPBackend API を使用して転送される場合、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 レスポンスになります。