Anthos Service Mesh 1.6

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

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

アップグレードを行う際は、デュアル コントロール プレーンのアップグレード(カナリア アップグレード)をおすすめします。ここでは、コントロール プレーンの新しいバージョンと以前のバージョンの両方を実行し、少数のワークロードで新しいバージョンのテストを行います。このアプローチはインプレース アップグレードよりも安全です。インプレース アップグレードでは、コントロール プレーンの新しいバージョンが以前のバージョンに置き換わります。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 が適切に機能する必要があります。ファイアウォール ルールを追加するか、限定公開クラスタを作成したときに自動的に作成されたファイアウォール ルールを次のように更新します。

    1. クラスタのソース範囲(master-ipv4-cidr)を確認します。次のコマンドで、cluster_name をクラスタの名前で置き換えます。

      gcloud compute firewall-rules list --filter="name~gke-cluster_name-[0-9a-z]*-master"
    2. ファイアウォール ルールをポート 1507 で更新します。次のコマンドで、firewall_rule_name をファイアウォールの名前で置き換えます。

      gcloud compute firewall-rules update firewall_rule_name --allow tcp:10250,tcp:443,tcp:15017

      update コマンドは実際には置き換えのため、デフォルト ポート 443(HTTPS)、10250(kubelet)、15017 を含める必要があります。

アップグレード

  1. このガイドの手順に従って、Anthos Service Mesh のアップグレードを準備します。

  2. Anthos Service Mesh をアップグレードします

環境設定

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. Cloud Console に移動します。
  2. Cloud プロジェクトを選択します。
  3. Cloud Console ウィンドウの上部にある [Cloud Shell をアクティブにする] ボタンをクリックします。

    Google Cloud Platform Console

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

    Cloud Shell セッション

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

    gcloud components update
    

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

    ERROR: (gcloud.components.update)
    You cannot perform this action because the Cloud SDK 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. kubectl をインストールします。

    sudo apt-get install kubectl
    
  7. kpt をインストールします。

    sudo apt-get install google-cloud-sdk-kpt
    

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

ローカルマシンに、Cloud SDKgcloud コマンドライン ツール)をインストールして初期化します。

Cloud SDK がすでにインストールされている場合:

  1. Cloud SDK で認証します。

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

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

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

    gcloud components install kpt
    

環境変数の設定

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

    gcloud

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

    gcloud projects list
    

    Console

    1. Cloud Console で [ダッシュボード] ページに移動します。

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

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

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

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

    export PROJECT_ID=YOUR_PROJECT_ID

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

    export ENVIRON_PROJECT_NUMBER=YOUR_ENVIRON_PROJECT_NUMBER

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

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

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

      export CLUSTER_LOCATION=YOUR_ZONE_OR_REGION

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

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

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

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

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

    export MESH_ID="proj-${ENVIRON_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}
    
  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.6.8-asm.9-linux-amd64.tar.gz
  2. 署名ファイルをダウンロードし、openssl を使用して署名を検証します。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.6.8-asm.9-linux-amd64.tar.gz.1.sig
    openssl dgst -verify /dev/stdin -signature istio-1.6.8-asm.9-linux-amd64.tar.gz.1.sig istio-1.6.8-asm.9-linux-amd64.tar.gz <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF

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

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

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

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

  4. Mac OS

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

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

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

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

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

  8. Windows

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}
    
  8. 使用する構成プロファイルを設定します。

    • クラスタが Shared Virtual Private Cloud にあり、サービス メッシュに異なるプロジェクトのクラスタが含まれているか、このようなクラスタを追加する場合は、asm-gcp-multiproject プロファイルを設定します。

      kpt cfg set asm anthos.servicemesh.profile asm-gcp-multiproject
      
    • すべてのクラスタが同じプロジェクトにある場合、asm-gcp プロファイルを設定します。

      kpt cfg set asm anthos.servicemesh.profile asm-gcp
      
  9. asm-gcp-multiproject プロファイルを設定する場合、マルチクラスタのサービス メッシュを形成するすべてのプロジェクトに信頼ドメイン エイリアスを構成する必要があります。

    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 は他のプロジェクトのクラスタ上のワークロードを認証できます。信頼ドメイン エイリアスを設定するだけでなく、クラスタ間で負荷分散を有効にする必要があります。

  10. また、リソース構成ファイルを Cloud Source Repositories などの独自のソース管理システムにチェックインして、ファイルの変更をトラッキングすることもできます。

Anthos Service Mesh の更新

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

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

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

  1. リビジョン名の環境変数を作成します。リビジョン名には、アップグレードするコントロール プレーン バージョンを識別するため、asm-168-9 のような名前を使用することをおすすめします。

    export REVISION=asm-168-9

    リビジョン名は DNS-1035 のラベルにします。ラベルには小文字の英数字または - を使用し、ラベルの先頭は英字に、ラベルの最後は英数字にする必要があります(例: my-name'abc-123)。検証に使用される正規表現は '[a-z]([-a-z0-9]*[a-z0-9])?') です。

  2. 新しいリビジョンをインストールします。

    次のコマンドを実行し、istio-operator.yaml ファイルで設定した構成プロファイルを使用して Anthos Service Mesh をインストールします。プロファイルの概要については、構成プロファイルをご覧ください。各プロファイルでサポートされる機能の詳細については、サポートされている機能のページをご覧ください。インストールをカスタマイズする場合は、オプション機能の有効化をご覧ください。

      istioctl install \
        -f asm/cluster/istio-operator.yaml \
        --revision=${REVISION}

    --revision 引数で、コントロール プレーンの Deployment に 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-REVISION-6d5cfd4b89-xztlr       1/1     Running   0          3m44s
    istiod-fb7f746f4-wcntn                      1/1     Running   0          50m
    promsd-579f9f9bf4-m65nc                     2/2     Running   1          50m

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

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

  1. 再デプロイするワークロードの名前空間の環境変数を作成します。

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

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=${REVISION} --overwrite

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

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

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

    kubectl get pods -n ${NAMESPACE} -l istio.io/rev=${REVISION}
    
  5. アプリケーションをテストして、ワークロードが正しく機能していることを確認します。

    以前のバージョンにロールバックする必要がある場合:

    1. 以前の Anthos サービス メッシュ バージョンで挿入するワークロードを更新します。

      kubectl label namespace ${NAMESPACE} istio.io/rev- istio-injection=enabled --overwrite
    2. Pod を再起動してインジェクションを再度トリガーします。

      kubectl rollout restart deployment -n ${NAMESPACE}

    アプリケーションが想定どおりに動作していることを確認したら、古いコントロール プレーンを削除してアップグレードを完了します。

    kubectl delete svc istiod -n istio-system

    kubectl delete deploy istiod -n istio-system

次のステップ