Anthos Service Mesh 1.6 のドキュメントを表示しています。最新のドキュメントを表示するか、他の利用可能なバージョンを選択します。

オンプレミスの Anthos Service Mesh のダウングレード

このガイドでは、Anthos clusters on VMware で Anthos Service Mesh を 1.6.14 から 1.5.10 にダウングレードする方法について説明します。

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 フラグを指定します。

ダウングレード

  1. このガイドの手順を行い、Anthos Service Mesh のダウングレードを準備します。

  2. Anthos Service Mesh をダウングレードします。

  3. サイドカー プロキシを更新します。

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

環境設定

Anthos Service Mesh をインストールするマシンには、次のツールが必要です。Anthos Service Mesh はユーザー クラスタにのみインストールできます。管理クラスタにはインストールできません。

  • curl コマンドライン ツール
  • Cloud SDK（gcloud コマンドライン ツール）

Cloud SDK をインストールしたら、次の手順を実施します。

  1. Cloud SDK で認証します。

    gcloud auth login

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

    gcloud components update

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

    gcloud components install kubectl

  4. kpt をインストールします。

    gcloud components install kpt

  5. 次のようにしてコンテキストをユーザー クラスタに切り替えます。

    kubectl config use-context CLUSTER_NAME

  6. ユーザー アカウント（Google Cloud ログイン メールアドレス）にクラスタ管理者の権限を付与します。この権限は、Anthos Service Mesh に必要なロールベースのアクセス制御（RBAC）ルールを作成するのに必要です。

    kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole=cluster-admin \
  --user=USER_ACCOUNT

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

    Linux

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

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

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

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

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

    4. Mac OS

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

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

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

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

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

    7. Windows

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

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

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

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

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

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

Anthos Service Mesh のダウングレード

Anthos Service Mesh をダウングレードするには:

istioctl install --set profile=asm-multicloud

コントロール プレーン コンポーネントを確認する

ダウングレードするには、コントロール プレーン コンポーネントを再インストールする必要があります。完了するまでには約 5～10 分かかります。新しいコンポーネントがインストールされると、古いコントロール プレーン コンポーネントは終了し、削除されます。ワークロードの AGE 列の値を見ることで、進行状況を確認できます。

kubectl get pod -n istio-system

出力例:

NAME                                     READY   STATUS        RESTARTS   AGE
istio-ingressgateway-5bfdf7c586-v6wxx    2/2     Terminating   0          25m
istio-ingressgateway-7b598c5557-b88md    2/2     Running       0          5m44s
istiod-78cdbbbdb-d7tps                   1/1     Running       0          5m16s
promsd-576b8db4d6-lqf64                  2/2     Running       1          5m26s

この例では、istio-ingressgateway のインスタンスが 2 つあります。AGE 列の 25m のインスタンスが終了します。その他のコンポーネントはすべて、新たにインストールされます。

サイドカー プロキシの更新

ダウングレード前にクラスタで実行されていたワークロードの場合、現在の Anthos Service Mesh バージョンが使用されるように、サイドカー プロキシを再挿入する必要があります。

自動サイドカー インジェクションでは、Pod の再起動で既存の Pod のサイドカーを更新できます。Pod を再起動する方法は、Pod が Deployment の一部として作成されたかどうかによって異なります。

  1. Deployment を使用した場合は、サイドカー付きのすべての Pod を再起動する Deployment を再起動します。

    kubectl rollout restart deployment -n YOUR_NAMESPACE

    Deployment を使用していない場合、Pod を削除すると、自動的にサイドカー付きで再作成されます。

    kubectl delete pod -n YOUR_NAMESPACE --all

  2. 名前空間内のすべての Pod にサイドカーが挿入されたことを確認します。

    kubectl get pod -n YOUR_NAMESPACE

    次に前のコマンドの出力例を示します。ここで、READY 列はワークロードごとに 2 つのコンテナ（プライマリ コンテナとサイドカー プロキシのコンテナ）があることを示しています。

    NAME                    READY   STATUS    RESTARTS   AGE
YOUR_WORKLOAD           2/2     Running   0          20s
...