Alibaba Cloud Service Mesh:Istio から ASM へのクラスターの移行

ステップ 1: 移行するクラスターを ASM に追加する

Istio がインストールされた ACK クラスター、または Alibaba Cloud Container Service に登録されているセルフビルドクラスターを ASM に追加するには、「ASM インスタンスにクラスターを追加する」をご参照ください。このプロセス中に、「istio-system 名前空間チェックを無視する」オプションを選択します。Kubernetes クラスターがまだ Alibaba Cloud Container Service に登録されていない場合は、ACK One の登録済みクラスター機能に基づいてクラスターを ACK インスタンスに登録し、ASM コンソールでクラスターを ASM に追加します。

クラスターが ASM に追加されると、ASM インスタンスは移行プロセスを制御するために ASMMigrateFromIstio リソースを自動的に作成します。次のコマンドを実行して、リソースを表示できます。

kubectl --kubeconfig=${ASM_KUBECONFIG} get asmmigratefromistio

予想される出力:

apiVersion: istio.alibabacloud.com/v1beta1
kind: ASMMigrateFromIstio
metadata:
  name: default
spec:
  desiredState: Init
  retryCounter: 0
  advancedOptions:
    stopIstioSystemInjectionDisabling: false
status:
  message: ""
  retryCounter: 0
  state: Init

このリソースの構成項目は、次のように説明されています。

ASMMigrateFromIstio の状態切り替え

次のフェーズに進むには、ASMMigrateFromIstio リソースの状態を手動で変更する必要があります。この例では、現在の状態は Init で、状態 SetupIstioForMigrate は次のフェーズに進んだことを示します。

次のサンプルコードは、状態を切り替える方法の例を示しています。

• SetupIstioForMigrate

  kubectl --kubeconfig=${ASM_KUBECONFIG} patch asmmigratefromistio default --type='merge' -p '{"spec":{"desiredState":"SetupIstioForMigrate"}}'

• Migrating

  kubectl --kubeconfig=${ASM_KUBECONFIG} patch asmmigratefromistio default --type='merge' -p '{"spec":{"desiredState":"Migrating"}}'

• Finished

  kubectl --kubeconfig=${ASM_KUBECONFIG} patch asmmigratefromistio default --type='merge' -p '{"spec":{"desiredState":"Finished"}}'

次のフェーズの状態が SetupIstioForMigrate であると仮定すると、次のコマンドを実行して切り替えが成功したことを確認できます。

kubectl get asmigratefromistio default -o yaml

予想される出力:

apiVersion: istio.alibabacloud.com/v1beta1
kind: ASMMigrateFromIstio
metadata:
  name: default
spec:
  desiredState: SetupIstioForMigrate
  retryCounter: 0
status:
  message: ""
  retryCounter: 0
  state: SetupIstioForMigrate

status.state の値が SetupIstioForMigrate の場合、状態は正常に切り替わっています。

Istio の東西ゲートウェイが有効になっているクラスターに必要な追加設定

デフォルトでは、ASM では istio-system 名前空間のサイドカーの自動インジェクションは無効になっています。ただし、Istio の東西ゲートウェイ Pod のキャッシュされたイメージは、MutatingWebhook によって手動で変更する必要があり、これには istio-system 名前空間でサイドカーのインジェクションが有効になっている必要があります。クラスターで東西ゲートウェイが有効になっている場合は、次のコマンドを実行して、ASM が istio-system 名前空間でサイドカーの自動インジェクションを無効にするのを防ぎます。

kubectl --kubeconfig=${ASM_KUBECONFIG} patch asmmigratefromistio default --type='merge' -p '{"spec":{"advancedOptions":{"disableIstioSystemLabelReconciliation": true}}}' 

次に、ASM から istio-system に同期されたラベルを手動で削除します。

1. Istio-system 名前空間の構成を編集します。

   kubectl --kubeconfig=${ACK インスタンスの kubeconfig ファイルのパス} edit ns istio-system

2. ラベル istio-injection: disable を削除し、保存して終了します。

ステップ 2: 準備のために Istio を構成する

1. 状態を SetupIstioForMigrate に変更します。

   重要

   上記のコマンドを実行した後、ASM で Istiod を再構成する必要があります。この場合、後続の移行のために Istiod をローリングモードで再起動できます。

2. このフェーズでは、ASM は Istio に次の構成を追加して、移行中に Istio Sidecar と ASM Sidecar 間の mTLS 通信を有効にします。

   defaultConfig:
     proxyMetadata:
       PROXY_CONFIG_XDS_AGENT: "true"

   このフェーズに入った後、この構成をすべてのワークロードに適用するには、Istio Sidecar が有効になっているすべてのワークロードを再起動する必要があります。次のコマンドを実行して、Pod が適格かどうかを確認できます。

   kubectl get pod ${POD 名} -o yaml|grep PROXY_CONFIG_XDS_AGENT

   空でない出力が表示された場合、ワークロードは正しく構成されています。Istio Sidecar が有効になっているすべてのワークロードが構成されたら、Migrating フェーズに進みます。

ステップ 3: 移行

Migrating フェーズでは、すべての Istio Sidecar が ASM メッシュプロキシに置き換えられるまで、ワークロードに Istio Sidecar または ASM メッシュプロキシをインジェクトできます。

1. 状態を Migrating に切り替えます。このフェーズでは、すべての Istio API を ASM に接続し、次の手順で概説されているように、イングレスゲートウェイ、エグレスゲートウェイ、東西ゲートウェイを含む Istio Sidecar のコンポーネントを ASM に移行します。

2. (オプション) ASM クラスタクロスゲートウェイをデプロイします。

   ASM 内では、メッシュプロキシが有効になっているワークロードは、Istio の東西ゲートウェイと同様に、クラスタクロス通信に ASM クラスタクロスゲートウェイを自動的に使用します。この場合、東西ゲートウェイが有効になっている場合は、Istio Sidecar から ASM メッシュプロキシに移行した後もシームレスなクラスタクロス通信を維持するために、ASM クラスタクロスゲートウェイをデプロイしてから、ワークロードを ASM メッシュプロキシと統合する ことが不可欠です。

   ASM コンソールでクラスターのネットワークを構成します。ネットワークは、Istio でクラスターに構成されているネットワークと同じである必要があります。さらに、Istio の東西ゲートウェイが有効になっているクラスターに対して、クラスタクロス メッシュ プロキシ経由のアクセスを有効にする を有効にする必要があります。詳細については、「クラスターのネットワーク設定を構成し、クラスタクロス メッシュ プロキシを有効にする」をご参照ください。

   

   説明

   ASM のネットワーク構成が Istio のネットワーク構成と一致していることを確認します。この例では、整合性を確保するために、ASM でクラスター a に network-1 を、クラスター b に network-2 を構成する必要があります。

3. Istio Sidecar を ASM メッシュプロキシに移行します。

   $ kubectl --kubeconfig=${Kubernetes クラスターの kubeconfig ファイルのパス} -n ${名前空間} patch ${デプロイメント名} --type='merge' -p '{"spec":{"template":{"metadata":{"labels":{"sidecar.asm.aliyun.com/inject":"true"}}}}}'

   重要

   この操作により、ワークロードでローリング再起動がトリガーされる場合があります。トラフィックの損失は、アプリケーションが無損失オフラインをサポートしているかどうか、Istio Sidecar に無損失オフラインが構成されているかどうか、およびアプリケーションが無損失オフラインの要件を満たしているかどうかによって異なります。要件は、アプリケーションへのすべてのリクエストが指定されたタイムアウト期間内に返される必要があることです。この手順は、オフピーク時に実行することをお勧めします。

4. Istio イングレスゲートウェイを ASM イングレスゲートウェイに移行します。

   Istio イングレスゲートウェイを ASM イングレスゲートウェイに移行します。詳細については、「セルフビルドの Istio IngressGateway を ASM ゲートウェイに移行する方法」をご参照ください。

5. Istio エグレスゲートウェイを ASM エグレスゲートウェイに移行します。移行するクラスターでエグレスゲートウェイが有効になっている場合は、次の手順に従います。

   1. ASM でエグレスゲートウェイを作成します。詳細については、「エグレスゲートウェイを作成する」をご参照ください。外部サービスに登録するための ServiceEntry、エグレスゲートウェイのポート フォワーディングを有効にするためのゲートウェイルール、トラフィックをエグレスゲートウェイにルーティングするための仮想サービスなど、必要なリソースを作成します。詳細については、「ASM での外部サービスへのアクセスのためのトラフィック管理」をご参照ください。

   2. 外部サービスの仮想サービスを調整して、トラフィックを ASM エグレスゲートウェイに転送し、目的の重みを設定します。

      次のサンプルコードは、仮想サービスを構成する方法の例を示しています。完全なサンプルコードについては、「HTTP トラフィックのエグレスゲートウェイ」をご参照ください。

      apiVersion: networking.istio.io/v1
      kind: VirtualService
      metadata:
        name: direct-cnn-through-egress-gateway
      spec:
        hosts:
        - edition.cnn.com
        gateways:
        - istio-egressgateway
        - mesh
        http:
        - match:
          - gateways:
            - mesh
            port: 80
          route:
          - destination:
              host: istio-egressgateway.istio-system.svc.cluster.local
              port:
                number: 80
            weight: 99
          - destination: # エグレスゲートウェイを指す新しい宛先を追加し、必要に応じて重みを調整します
              host: asm-egressgateway.istio-system.svc.cluster.local # ASM エグレスゲートウェイが asm-egressgateway と呼ばれていると仮定します
              port:
                number: 80
            weight: 1

      この YAML ファイルでは、edition.cnn.com へのトラフィックは、99:1 の比率で Istio Ingressgateway と ASM Egressgateway にルーティングされます。すべてのトラフィックが ASM Egress ゲートウェイにルーティングされるまで、必要に応じて比率を調整します。Istio Egress ゲートウェイのアクセスログを監視して、トラフィックフローを追跡できます。

ステップ 4: 完了

次のフェーズに進む前に、以下のすべての操作が完了していることを確認してください。

• すべての Istio Sidecar が削除されている。

• Istio の東西ゲートウェイ、イングレスゲートウェイ、またはエグレスゲートウェイを通過するトラフィックがない。

• すべての Istio API 構成が ASM にインポートされている。

• ASM メッシュプロキシがインジェクトされたワークロードが期待どおりに機能している。

上記の操作が完了したら、バージョン固有の istioctl コマンドを使用して、クラスターにインストールされている Istio をアンインストールできます。

$ istioctl --kubeconfig=${Kubernetes クラスターの kubeconfig ファイルのパス} uninstall --purge

istioctl ツールがアンインストールされたら、状態を Finished に切り替えます。状態の切り替えが失敗した場合は、status.message のプロンプトに従って残りの Istio リソースをクリアし、spec.retryCounter を 1 ずつ増やしてから再試行してください。 status.state の値が Finished に変更されると、移行は完了です。