GKE の Anthos Service Mesh のアップグレード

このガイドでは、GKE で Anthos Service Mesh をバージョン 1.6.4+ からバージョン 1.7.8 にアップグレードする方法について説明します。Anthos Service Mesh 1.4.5 以降からアップグレードするには、まず Anthos Service Mesh 1.5 にアップグレードする必要があります。Anthos Service Mesh 1.4 から 1.6 に直接アップグレードすることはできません。

Anthos Service Mesh インストール 1.7 以降は、バージョン スキップ アップグレードをサポートしています。1.10 に直接アップグレードするには、Anthos Service Mesh の最新バージョンへのアップグレードをご覧ください。

アップグレードを行う際は、デュアル コントロール プレーンのアップグレード(カナリア アップグレード)をおすすめします。ここでは、コントロール プレーンの新しいバージョンと以前のバージョンの両方を実行し、少数のワークロードで新しいバージョンのテストを行います。このアプローチはインプレース アップグレードよりも安全です。インプレース アップグレードでは、コントロール プレーンの新しいバージョンが以前のバージョンに置き換わります。istio-ingressgateway はインプレースでアップグレードされるため、クラスタの中断を計画する必要があるので注意してください。

Anthos Service Mesh のコントロール プレーン コンポーネントのデプロイには 5~10 分ほどかかります。また、すべてのワークロードに新しいサイドカー プロキシを挿入し、現在の Anthos Service Mesh バージョンで更新されるようにする必要があります。サイドカー プロキシの更新にかかる時間は、Pod 数、ノード数、デプロイのスケーリング設定、Pod 中断のコスト、その他の構成要素など、さまざまな要因に左右されます。サイドカー プロキシの更新にかかる大まかな時間は 1 分あたり 100 Pod です。

アップグレードの準備を行う

このセクションでは、Anthos Service Mesh をアップグレードする際に行う準備について説明します。

  1. サポートされている機能とこのガイドを確認して、機能とアップグレード プロセスをよく理解してください。

  2. 以前のバージョンの Anthos Service Mesh をインストールしたときにオプション機能を有効にした場合は、アップグレードするときに同じ機能を有効にする必要があります。オプション機能を有効にするには、--set values フラグを追加するか、istioctl install コマンドを実行するときに YAML ファイルで -f フラグを指定します。

  3. 限定公開クラスタに Anthos Service Mesh をインストールする場合は、ファイアウォールでポート 15017 を開き、自動サイドカー インジェクションで使用される Webhook が適切に機能する必要があります。詳細については、限定公開クラスタのポートを開くをご覧ください。

  4. Anthos Service Mesh 1.5 からアップグレードする場合は、ロールバックが必要となる場合に備えて、次の手順を行ってください。

    1. asm-1-5 という名前のディレクトリを作成します。

    2. asm-1-5 ディレクトリに 1.5 インストール ファイルをダウンロードします。

    3. ファイルの内容を asm-1-5 ディレクトリに抽出します。

    4. Anthos Service Mesh 1.5 インストールのルート ディレクトリにいることを確認します。

    5. 1.5 kpt パッケージをダウンロードし、1.5 istio-operator.yaml を構成します。

環境設定

Google Kubernetes Engine へのインストールは、インストール ガイドに沿って行います。インストールは、Cloud Shell、Google Cloud リソースに対するブラウザ内コマンドライン インターフェース、Linux または macOS を実行している独自のコンピュータを使用して行うことができます。

オプション A: Cloud Shell を使用する

Cloud Shell は、Debian ベースの Linux オペレーティング システムを実行している g1-small Compute Engine 仮想マシン(VM)をプロビジョニングします。Cloud Shell を使用する利点は次のとおりです。

  • Cloud Shell には、必要な gcloudkubectlhelm コマンドライン ツールが含まれています。

  • Cloud Shell の $HOME ディレクトリには 5 GB の永続ストレージ スペースがあります。

  • テキスト エディタを選択できます。

    • コードエディタ。Cloud Shell ウィンドウの上部にある をクリックしてアクセスします。

    • Emacs、Vim、Nano。Cloud Shell のコマンドラインからアクセスします。

Cloud Shell を使用するには:

  1. Google Cloud コンソールに移動します。
  2. Google Cloud プロジェクトを選択します。
  3. Google Cloud コンソール ウィンドウの上部にある [Cloud Shell をアクティブにする] ボタンをクリックします。

    Google Cloud Platform コンソール

    Google Cloud コンソールの一番下にある新しいフレームの中で Cloud Shell セッションが開き、コマンドライン プロンプトが表示されます。

    Cloud Shell セッション

  4. コンポーネントを更新します。

    gcloud components update
    

    次のような出力が返されます。

    ERROR: (gcloud.components.update)
    You cannot perform this action because the gcloud CLI component manager
    is disabled for this installation. You can run the following command
    to achieve the same result for this installation:
    
    sudo apt-get update && sudo apt-get --only-upgrade install ...
  5. long コマンドをコピーし、貼り付けてコンポーネントを更新します。

  6. kpt から検出できるように、パスに Git を設定します。

オプション B: ローカルのコマンドライン ツールを使用する

ローカルマシンに Google Cloud CLI をインストールして初期化します。

gcloud CLI がすでにインストールされている場合は、次の手順を行います。

  1. gcloud CLI を使用して認証します。

    gcloud auth login
    
  2. コンポーネントを更新します。

    gcloud components update
    
  3. kubectl をインストールします。

    gcloud components install kubectl
    
  4. kpt をインストールします。

    gcloud components install kpt
    
  5. kpt から検出できるように、パスに Git を設定します。

環境変数の設定

  1. クラスタが作成されたプロジェクトのプロジェクト ID と、フリートのホスト プロジェクトのプロジェクト番号を取得します。

    gcloud

    次のコマンドを実行します。

    gcloud projects list
    

    コンソール

    1. Google Cloud コンソールの [ダッシュボード] ページに移動します。

      [ダッシュボード] ページに移動する

    2. ページ上部の [選択元] プルダウン リストをクリックします。表示された [選択元] ウィンドウで、プロジェクトを選択します。

      プロジェクト ID は、プロジェクト ダッシュボードの [プロジェクト情報] カードに表示されます。

  2. クラスタが作成されたプロジェクトのプロジェクト ID の環境変数を作成します。

    export PROJECT_ID=YOUR_PROJECT_ID

  3. フリートのホスト プロジェクトのプロジェクト番号の環境変数を作成します。

    export FLEET_PROJECT_NUMBER=YOUR_FLEET_PROJECT_NUMBER

  4. 次の環境変数を作成します。

    • クラスタ名を設定します。

      export CLUSTER_NAME=YOUR_CLUSTER_NAME
    • CLUSTER_LOCATION をクラスタのゾーンまたはリージョンに設定します。

      export CLUSTER_LOCATION=YOUR_ZONE_OR_REGION

クラスタのメッシュ ID を変更する(省略可)

サービス メッシュに異なるプロジェクトの複数のクラスタが含まれているか、含まれる予定がある場合は、すべてのクラスタに同じメッシュ ID が設定されている必要があります。この ID は、フリートのホスト プロジェクトのプロジェクト番号に基づいて設定されます。クラスタのメッシュ ID は、Anthos Service Mesh が使用するメッシュ ID と一致する必要があります。

クラスタが 1 つしかない場合、またはサービス メッシュに同じプロジェクトのクラスタしか含まれていないか、同じプロジェクトのクラスタを追加する場合は、次の手順をスキップして、認証情報と権限の設定を行ってください。

クラスタに新しいメッシュ ID ラベルを設定するには:

  1. メッシュ ID の環境変数を作成します。

    export MESH_ID="proj-${FLEET_PROJECT_NUMBER}"

  2. クラスタの既存のラベルを残す場合は、mesh_id ラベルの追加時にそれらのラベルを含める必要があります。

    1. クラスタに既存のラベルがあるかどうかを確認するには:

      gcloud container clusters describe ${CLUSTER_NAME} \
        --project ${PROJECT_ID}

      出力で resourceLabels フィールドを探します。ラベルは、resourceLabels フィールドごとに別々の行に格納されます。次に例を示します。

      resourceLabels:
        csm: ''
        env: dev
        release: stable

      既存の mesh_id を保持する必要はありません。新しい mesh_id ラベルで上書きします。

      利便性を考えて、環境変数にラベルを追加することもできます。以下の例の YOUR_EXISTING_LABELS は、クラスタに存在するラベルのカンマ区切りのリスト(KEY=VALUE 形式、たとえば env=dev,release=stable)で置き換えます。

      export EXISTING_LABELS="YOUR_EXISTING_LABELS"
    2. mesh_id ラベルを設定します。

      • クラスタの既存のラベルを残す場合は、mesh_id と既存のラベルでクラスタを更新します。

        gcloud container clusters update ${CLUSTER_NAME} \
          --project ${PROJECT_ID}
          --update-labels=mesh_id=${MESH_ID},${EXISTING_LABELS}
      • クラスタに既存のラベルがない場合は、新しい mesh_id ラベルだけでクラスタを更新します。

        gcloud container clusters update ${CLUSTER_NAME} \
          --project=${PROJECT_ID} \
          --update-labels=mesh_id=${MESH_ID}

認証情報と権限の設定

  1. クラスタとのやり取りで必要な認証情報を取得します。

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
        --project=${PROJECT_ID}
    
  2. 現在のユーザーにクラスタ管理者の権限を付与します。この権限は、Anthos Service Mesh に必要なロールベースのアクセス制御(RBAC)ルールを作成するのに必要です。

    kubectl create clusterrolebinding cluster-admin-binding \
      --clusterrole=cluster-admin \
      --user="$(gcloud config get-value core/account)"

"cluster-admin-binding" already exists エラーが発生した場合は、無視して既存の cluster-admin-binding を続行しても問題ありません。

インストール ファイルのダウンロード

    Linux

  1. Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-linux-amd64.tar.gz
  2. 署名ファイルをダウンロードし、openssl を使用して署名を検証します。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-linux-amd64.tar.gz.1.sig
    openssl dgst -verify /dev/stdin -signature istio-1.7.8-asm.10-linux-amd64.tar.gz.1.sig istio-1.7.8-asm.10-linux-amd64.tar.gz <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF

    想定される出力は Verified OK です。

  3. ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
    tar xzf istio-1.7.8-asm.10-linux-amd64.tar.gz

    このコマンドにより、現在の作業ディレクトリに istio-1.7.8-asm.10 という名前のインストール ディレクトリが作成されます。このディレクトリには、次のものが含まれます。

    • samples ディレクトリにあるサンプル アプリケーション
    • Anthos Service Mesh のインストールに使用する istioctl コマンドライン ツールは、bin ディレクトリにあります。
    • Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。

  4. Mac OS

  5. Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-osx.tar.gz
  6. 署名ファイルをダウンロードし、openssl を使用して署名を検証します。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-osx.tar.gz.1.sig
    openssl dgst -sha256 -verify /dev/stdin -signature istio-1.7.8-asm.10-osx.tar.gz.1.sig istio-1.7.8-asm.10-osx.tar.gz <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF

    想定される出力は Verified OK です。

  7. ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
    tar xzf istio-1.7.8-asm.10-osx.tar.gz

    このコマンドにより、現在の作業ディレクトリに istio-1.7.8-asm.10 という名前のインストール ディレクトリが作成されます。このディレクトリには、次のものが含まれます。

    • samples ディレクトリにあるサンプル アプリケーション
    • Anthos Service Mesh のインストールに使用する istioctl コマンドライン ツールは、bin ディレクトリにあります。
    • Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。

  8. Windows

  9. Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-win.zip
  10. 署名ファイルをダウンロードし、openssl を使用して署名を検証します。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-win.zip.1.sig
    openssl dgst -verify - -signature istio-1.7.8-asm.10-win.zip.1.sig istio-1.7.8-asm.10-win.zip <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF

    想定される出力は Verified OK です。

  11. ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
    tar xzf istio-1.7.8-asm.10-win.zip

    このコマンドにより、現在の作業ディレクトリに istio-1.7.8-asm.10 という名前のインストール ディレクトリが作成されます。このディレクトリには、次のものが含まれます。

    • samples ディレクトリにあるサンプル アプリケーション
    • Anthos Service Mesh のインストールに使用する istioctl コマンドライン ツールは、bin ディレクトリにあります。
    • Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。

  12. Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。
    cd istio-1.7.8-asm.10
  13. 利便性を考えて、/bin ディレクトリ内のツールを PATH に追加します。
    export PATH=$PWD/bin:$PATH

リソース構成ファイルの準備

istioctl install コマンドを実行するときは、コマンドラインで -f istio-operator.yaml を指定します。このファイルには、Anthos Service Mesh で必要なプロジェクトとクラスタに関する情報が含まれています。プロジェクトとクラスタの情報を設定できるように、istio-operator.yaml と他のリソース構成ファイルを含むパッケージをダウンロードする必要があります。

リソース構成ファイルを準備するには:

Mesh CA

  1. Anthos Service Mesh パッケージのリソース構成ファイル用に新しいディレクトリを作成します。クラスタ名をディレクトリ名として使用することをおすすめします。

  2. Anthos Service Mesh パッケージをダウンロードするディレクトリに変更します。

  3. パッケージをダウンロードします。

    kpt pkg get \
    https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.7-asm asm
    
  4. クラスタが作成されたプロジェクトのプロジェクト ID を設定します。

    kpt cfg set asm gcloud.core.project ${PROJECT_ID}
    
  5. フリート ホスト プロジェクトのプロジェクト番号を設定します。

    kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}
    
  6. クラスタ名を設定します。

    kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}
    
  7. デフォルトのゾーンまたはリージョンを設定します。

    kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}
    
  8. インストールする Anthos Service Mesh のバージョンにタグを設定します。

    kpt cfg set asm anthos.servicemesh.tag 1.7.8-asm.10
    
  9. リビジョン ラベルを使用するように Webhook の検証を設定します。

    kpt cfg set asm anthos.servicemesh.rev asm-178-10
    

    Anthos Service Mesh をインストールするときに、istiod にリビジョン ラベルを設定します。検証 Webhook に同じリビジョンを設定する必要があります。

  10. マルチクラスタ構成内のクラスタは異なるプロジェクトにあるため、マルチクラスタ / マルチプロジェクトのサービスメッシュを形成する他のプロジェクトに、信頼できるドメイン エイリアスを構成する必要があります。

    1. マルチクラスタ / マルチプロジェクト メッシュに含まれるすべてのクラスタのプロジェクト ID を取得します。

    2. 各クラスタのプロジェクト ID に、信頼ドメイン エイリアスを設定します。たとえば、3 つのプロジェクトにクラスタがある場合は、次のコマンドを実行して、PROJECT_ID_1PROJECT_ID_2PROJECT_ID_3 を各クラスタのプロジェクト ID に置き換えます。

      kpt cfg set asm anthos.servicemesh.trustDomainAliases PROJECT_ID_1.svc.id.goog PROJECT_ID_2.svc.id.goog PROJECT_ID_3.svc.id.goog

      他のプロジェクトにクラスタを構成する場合は、同じコマンドを使用できます。

      信頼ドメイン エイリアスにより、Mesh CA は他のプロジェクトのクラスタ上のワークロードを認証できます。Anthos Service Mesh をインストールした後、信頼ドメイン エイリアスを設定するだけでなく、クラスタ間で負荷分散を有効にする必要があります。

  11. kpt セッターの値を出力します。

    kpt cfg list-setters asm
    

    コマンドの出力は、次のようになります。

                              NAME                                                       VALUE
    anthos.servicemesh.canonicalServiceHub               gcr.io/gke-release/asm/canonical-service-controller:1.7.8-asm.10
    anthos.servicemesh.controlplane.monitoring.enabled   true
    anthos.servicemesh.hub                               gcr.io/gke-release/asm
    anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
    anthos.servicemesh.tag                               1.7.8-asm.10
    anthos.servicemesh.trustDomainAliases                [example-project-12345.svc.id.goog,example-project-23456.svc.id.goog,example-project-98765.svc.id.goog]
    base-dir                                             base
    gcloud.compute.location                              us-central
    gcloud.compute.network                               default
    gcloud.compute.subnetwork                            default
    gcloud.container.cluster                             example-cluster-1
    gcloud.container.cluster.clusterSecondaryRange
    gcloud.container.cluster.releaseChannel              REGULAR
    gcloud.container.cluster.servicesSecondaryRange
    gcloud.container.nodepool.max-nodes                  4
    gcloud.core.project                                  example-project-12345
    gcloud.project.environProjectID                      FLEET_PROJECT_ID
    gcloud.project.environProjectNumber                  1234567890123
    gcloud.project.projectNumber                         9876543210987

    次のセッターの値が正しいことを確認します。

    • anthos.servicemesh.rev
    • anthos.servicemesh.tag
    • anthos.servicemesh.trustDomainAliases
    • gcloud.compute.location
    • gcloud.container.cluster
    • gcloud.core.project
    • gcloud.project.environProjectNumber

    他のセッターの値は無視してかまいません。

Citadel

  1. Anthos Service Mesh パッケージのリソース構成ファイル用に新しいディレクトリを作成します。クラスタ名をディレクトリ名として使用することをおすすめします。

  2. Anthos Service Mesh パッケージをダウンロードするディレクトリに変更します。

  3. パッケージをダウンロードします。

    kpt pkg get \
    https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.7-asm asm
    
  4. クラスタが作成されたプロジェクトのプロジェクト ID を設定します。

    kpt cfg set asm gcloud.core.project ${PROJECT_ID}
    
  5. フリート ホスト プロジェクトのプロジェクト番号を設定します。

    kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}
    
  6. クラスタ名を設定します。

    kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}
    
  7. デフォルトのゾーンまたはリージョンを設定します。

    kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}
    
  8. インストールする Anthos Service Mesh のバージョンにタグを設定します。

    kpt cfg set asm anthos.servicemesh.tag 1.7.8-asm.10
    
  9. リビジョン ラベルを使用するように Webhook の検証を設定します。

    kpt cfg set asm anthos.servicemesh.rev asm-178-10
    
  10. kpt セッターの値を出力します。

    kpt cfg list-setters asm
    

    コマンドの出力は、次のようになります。

                              NAME                                                       VALUE
    anthos.servicemesh.canonicalServiceHub               gcr.io/gke-release/asm/canonical-service-controller:1.7.8-asm.10
    anthos.servicemesh.controlplane.monitoring.enabled   true
    anthos.servicemesh.hub                               gcr.io/gke-release/asm
    anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
    anthos.servicemesh.tag                               1.7.8-asm.10
    anthos.servicemesh.trustDomainAliases
    base-dir                                             base
    gcloud.compute.location                              us-central
    gcloud.compute.network                               default
    gcloud.compute.subnetwork                            default
    gcloud.container.cluster                             example-cluster-1
    gcloud.container.cluster.clusterSecondaryRange
    gcloud.container.cluster.releaseChannel              REGULAR
    gcloud.container.cluster.servicesSecondaryRange
    gcloud.container.nodepool.max-nodes                  4
    gcloud.core.project                                  example-project-12345
    gcloud.project.environProjectID                      FLEET_PROJECT_ID
    gcloud.project.environProjectNumber                  1234567890123
    gcloud.project.projectNumber                         9876543210987

    次のセッターの値が正しいことを確認します。

    • anthos.servicemesh.rev
    • anthos.servicemesh.tag
    • gcloud.compute.location
    • gcloud.container.cluster
    • gcloud.core.project
    • gcloud.project.environProjectNumber

    他のセッターの値は無視してかまいません。

Anthos Service Mesh の更新

新しいバージョンの Anthos Service Mesh をインストールするには、デュアル コントロール プレーンのアップグレード プロセス(Istio ドキュメントではカナリア アップグレード)に沿って操作することをおすすめします。デュアル コントロール プレーンのアップグレードでは、既存のコントロール プレーンを残しながら、新しいバージョンのコントロール プレーンをインストールします。新しいバージョンをインストールする際は、新しいコントロール プレーンのバージョンを識別する revision ラベルを含めます。各リビジョンは、独自の Deployment と Service を持つ完全な Anthos Service Mesh コントロール プレーンの実装です。

新しいコントロール プレーンを参照するようにワークロードに同じ revision ラベルを設定し、ローリング再起動を行い、新しい Anthos Service Mesh バージョンでプロキシを再挿入して新しいバージョンに移行します。この方法では、少数のワークロードでアップグレードの効果をモニタリングできます。アプリケーションのテスト後に、すべてのトラフィックを新しいバージョンに移行できます。これは、インプレース アップグレードを行うよりもはるかに安全です。インプレース アップグレードでは、以前のバージョンのコントロール プレーンが新しいコントロール プレーンで置き換わります。

コントロール プレーンの更新

次のコマンドを実行して、istio-operator.yaml ファイルで設定した構成プロファイルを使用して新しいコントロール プレーンをデプロイします。サポートされているオプション機能を有効にするには、コマンドラインで -f と YAML のファイル名を指定します。詳細については、オプション機能の有効化をご覧ください。

  istioctl install \
    -f asm/cluster/istio-operator.yaml \
    --set revision=asm-178-10

--set revision 引数は、istiod に istio.io/rev ラベルを追加します。このコマンドの実行後は、コントロール プレーンの 2 つの Deployment と Service を並行して実行できます。

kubectl get pods -n istio-system

出力例:

NAME                                        READY   STATUS    RESTARTS   AGE
istio-ingressgateway-c56675fcd-86zdn        1/1     Running   0          2m9s
istio-ingressgateway-c56675fcd-vn4nv        1/1     Running   0          2m21s
istiod-asm-178-10-6d5cfd4b89-xztlr           1/1     Running   0          3m44s
istiod-fb7f746f4-wcntn                      1/1     Running   0          50m

ワークロードの再デプロイ

新しいリビジョンをインストールしても、既存のサイドカー プロキシには影響しません。これらをアップグレードするには、新しいコントロール プレーンを指すように構成する必要があります。これは、名前空間ラベル istio.io/rev に基づいたサイドカー インジェクションで制御されます。

  1. 新しい Anthos Service Mesh バージョンで挿入されるワークロードを更新します。

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-178-10 --overwrite

    istio.io/rev ラベルよりも優先されるため、istio-injection ラベルは削除する必要があります。

  2. Pod を再起動してインジェクションを再度トリガーします。

    kubectl rollout restart deployment -n NAMESPACE
  3. Pod が istiod-asm-178-10 コントロール プレーンを参照するように構成されていることを確認します。

    kubectl get pods -n NAMESPACE -l istio.io/rev=asm-178-10

  4. アプリケーションをテストして、ワークロードが正しく機能していることを確認します。

  5. 他の名前空間にワークロードがある場合は、各名前空間に対して前の手順を繰り返します。

  6. アプリケーションが期待どおりに機能していることを確認したら、アップグレードを完了するに進みます。それ以外の場合は、次の手順で以前のバージョンにロールバックします。

    1. コントロール プレーンの以前のバージョンで挿入されるワークロードを更新します。

       kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite

    2. プロキシが Istio のバージョンになるように、Pod を再起動してインジェクションを再度トリガーします。

       kubectl rollout restart deployment -n NAMESPACE

    3. コントロール プレーン コンポーネントをロールバックします。

      以前の 1.6 にロールバックする

      1. 以前のバージョンの istio-ingressgateway を再デプロイします。

        kubectl -n istio-system rollout undo deploy istio-ingressgateway
        
      2. 新しいコントロール プレーンを削除します。

        kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-asm-178-10 -n istio-system --ignore-not-found=true
        

      1.5 にロールバックする

      1. 1.5 Anthos Service Mesh インストール ファイルをダウンロードしたディレクトリに移動します。

      2. 以前のバージョンの Anthos Service Mesh を再インストールします。オプション機能を有効にした場合は、次のコマンドで該当する --set values フラグまたは -f フラグ(YAML ファイル名)を指定してください。

        bin/istioctl install \
        -f asm/cluster/istio-operator.yaml

アップグレードを完了する

アプリケーションが想定どおりに機能していることを確認したら、次の手順でアップグレードを完了します。

  1. 古いコントロール プレーンを削除します。

    kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
    
  2. 次のコマンドを実行して、Canonical Service コントローラをデプロイします。

    kubectl apply -f asm/canonical-service/controller.yaml

    このコマンドでは、Canonical Service コントローラをクラスタにデプロイします。Canonical Service コントローラは、同じ論理サービスに属するワークロードをグループにまとめ、Google Cloud コンソールのサービス ダッシュボードで追加機能のロックを解除する必要があります。詳細については、Canonical Service コントローラの有効化と無効化をご覧ください。

次のステップ