Apigee ハイブリッドのバージョン 1.8 へのアップグレード

Apigee Ingress ゲートウェイの概要

バージョン 1.8 以降、Apigee ハイブリッドでは、ハイブリッド インストールの Ingress ゲートウェイ(Apigee Ingress ゲートウェイ)を管理する新機能を備えています。Anthos Service Mesh は、ハイブリッド インストールの前提条件ではなくなりました。Apigee Ingress ゲートウェイを使用すると、Apigee は Anthos Service Mesh へのルーティング構成の提供を停止します。アップグレード後、この機能の使用を開始するには、トラフィックを新しい Apigee Ingress ゲートウェイに移行する必要があります。

Apigee では、Ingress ゲートウェイに Anthos Service Mesh 機能の小さなサブセットを使用します。ハイブリッド バージョン 1.8 以降の Apigee ハイブリッドには Ingress ゲートウェイが含まれており、Apigee ハイブリッドのアップグレードの一環としてインストールおよびアップグレードされます。そのため、Apigee ハイブリッドをインストール、アップグレード、管理するために Anthos Service Mesh に関する専門知識を身に付ける必要はありません。Ingress ゲートウェイのバージョンと Apigee ハイブリッド リリースとの互換性に関する問題は自動的に処理されます。

移行には 2 つのシナリオがあります。

  • マルチクラスタまたはマルチリージョンの移行(推奨):

    Apigee 用の新しい Ingress に切り替える前に、移行するクラスタから別のクラスタまたはリージョンにすべてのトラフィックをドレインします。これにより、新しい Apigee Ingress ゲートウェイが期待どおりに動作しているかどうかテストできます。その後、アップグレードしたクラスタにトラフィックを戻します。

  • インプレース アップグレード(本番環境では推奨されません):

    アップグレード中、Apigee は指定された IP アドレスで新しい Ingress ゲートウェイを起動します。その後、新しい Apigee Ingress ゲートウェイが期待どおりに動作しているかどうかをテストして、トラフィックを新しい Ingress に移行できます。このアップグレード中にダウンタイムが発生する可能性があります。

Apigee ハイブリッドをバージョン 1.8 にアップグレードする場合は、オーバーライド ファイルで Apigee Ingress ゲートウェイを構成する必要があります。アップグレード後、登録事業者の A または CNAME レコードを Apigee Ingress ゲートウェイまたは Anthos Service Mesh の IP アドレスに転送することで、クラスタで使用する Ingress ゲートウェイのタイプを制御します。

バージョン 1.8.8 へのアップグレードの概要

以降のセクションでは、Apigee Hybrid のアップグレード手順を次の順番で説明します。

  1. アップグレードを準備する
  2. ハイブリッド ランタイム バージョン 1.8.8 をインストールする
  3. Ingress ゲートウェイの場合は、次のいずれかのオプションを選択します。

前提条件

以下のアップグレード手順では、Apigee ハイブリッド バージョン 1.7.x またはバージョン 1.8.x の以前のパッチリリースがインストールされており、バージョン 1.8.8 にアップグレードすることを前提としています。以前のバージョンから更新する場合は、Apigee ハイブリッド バージョン 1.7 へのアップグレードをご覧ください。

Anthos Service Mesh を引き続き使用する場合は、Anthos Service Mesh をサポート対象バージョンにアップグレードする必要があります。Anthos Service Mesh のサポートされているバージョンについては、サポートされているプラットフォームの表をご覧ください。

バージョン 1.8 へのアップグレードを準備する

  1. この手順では、apigeectl をインストールしたファイル システム内のディレクトリの環境変数 APIGEECTL_HOME を使用します。必要に応じて、ディレクトリを apigeectl ディレクトリに変更し、次のコマンドで変数を定義します。

    Linux

    export APIGEECTL_HOME=$PWD
    echo $APIGEECTL_HOME

    Mac OS

    export APIGEECTL_HOME=$PWD
    echo $APIGEECTL_HOME

    Windows

    set APIGEECTL_HOME=%CD%
    echo %APIGEECTL_HOME%
  2. バージョン 1.7 の $APIGEECTL_HOME/ ディレクトリのバックアップを作成します。次に例を示します。
    tar -czvf $APIGEECTL_HOME/../apigeectl-v1.7-backup.tar.gz $APIGEECTL_HOME
  3. Cassandra のバックアップと復元の手順に沿って Cassandra データベースをバックアップします。

Apigee ランタイムのサービス アカウントに Cloud Trace エージェント ロールを追加します。(省略可)

省略可: Cloud Trace を使用する予定で、ハイブリッド v1.7 のインストールでこの手順をまだ実行していない場合は、Apigee ランタイム サービスのサービス アカウントに Cloud Trace エージェントの Google ロール(roles/cloudtrace.agent)が付与されていることを確認します。

本番環境の場合、通常これは apigee-runtime サービス アカウントです。非本番環境の場合、通常これは apigee-non-prod サービス アカウントです。

ロールを追加するには、[Cloud コンソール] > [IAM と管理] > [サービス アカウント] UI か、次のコマンドを使用します。

  1. 次のコマンドでサービス アカウントのメールアドレスを取得します。

    本番環境

    gcloud iam service-accounts list --filter "apigee-runtime"

    パターン apigee-runtime@$ORG_NAME.iam.gserviceaccount.com と一致する場合、そのパターンは次の手順で使用できます。

    本番以外の環境

    gcloud iam service-accounts list --filter "apigee-non-prod"

    パターン apigee-non-prod@$ORG_NAME.iam.gserviceaccount.com と一致する場合、そのパターンは次の手順で使用できます。

  2. サービス アカウントに Cloud Trace エージェント ロールを割り当てます。

    本番環境

    gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member="serviceAccount:apigee-runtime@$PROJECT_ID.iam.gserviceaccount.com" \
        --role="roles/cloudtrace.agent"

    本番以外の環境

    gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member="serviceAccount:apigee-non-prod@$PROJECT_ID.iam.gserviceaccount.com" \
        --role="roles/cloudtrace.agent"

    gcloud projects add-iam-policy-binding hybrid-example-project \
        --member="serviceAccount:apigee-runtime@hybrid-example-project.iam.gserviceaccount.com" \
        --role="roles/cloudtrace.agent"

    ここで、$PROJECT_ID は Apigee ハイブリッドがインストールされている Google Cloud プロジェクトの名前です。

Apigee Ingress ゲートウェイのインストールを準備する

アップグレードの一環として Apigee Ingress ゲートウェイをインストールするには、次の ingressGateways プロパティをオーバーライド ファイルに追加する必要があります。

構文

ingressGateways:
- name: INGRESS_NAME
  replicaCountMin: REPLICAS_MIN
  replicaCountMax: REPLICAS_MAX
  resources:
    requests:
      cpu: CPU_COUNT_REQ
      memory: MEMORY_REQ
    limits:
      cpu: CPU_COUNT_LIMIT
      memory: MEMORY_LIMIT
  svcAnnotations:  # optional. See Known issue 243599452.
    SVC_ANNOTATIONS_KEY: SVC_ANNOTATIONS_VALUE
  svcLoadBalancerIP: SVC_LOAD_BALANCER_IP # optional

ingressGateways:
- name: prod1
  replicaCountMin: 2
  replicaCountMax: 100
  resources:
    requests:
      cpu: 1
      memory: 1Gi
    limits:
      cpu: 2
      memory: 2Gi 
  • INGRESS_NAME は、Ingress デプロイの名前です。 次の要件を満たす任意の名前を使用できます。
    • 最大文字数が 17 文字
    • 小文字の英数字、「-」、「.」のみを使用する
    • 先頭が英数字である
    • 末尾が英数字である

    構成プロパティ リファレンスの ingressGateways[].name をご覧ください。

  • REPLICAS_MINREPLICAS_MAX は、インストールにおける Apigee Ingress ゲートウェイの最小レプリカ数と最大レプリカ数です。詳細とデフォルト設定については、構成プロパティ リファレンスの ingressGateways[].replicaCountMin および ingressGateways[].replicaCountMax をご覧ください。
  • CPU_COUNT_REQMEMORY_REQ は、インストール環境における Apigee Ingress ゲートウェイの各レプリカに対する CPU とメモリのリクエストです。

    詳細とデフォルト設定については、 構成プロパティ リファレンスの ingressGateways[].resources.requests.cpu および ingressGateways[].resources.requests.memory をご覧ください。

  • CPU_COUNT_LIMITMEMORY_LIMIT インストール環境での Apigee Ingress ゲートウェイの各レプリカに対する最大 CPU とメモリの制限。

    詳細とデフォルト設定については、 構成プロパティ リファレンスの ingressGateways[].resources.limits.cpu および ingressGateways[].resources.limits.memory をご覧ください。

  • SVC_ANNOTATIONS_KEYSVC_ANNOTATIONS_VALUE(省略可):

    これは、デフォルトの Ingress サービスのアノテーションを提供する Key-Value ペアです。アノテーションは、ハイブリッド インストールの構成をサポートするために、クラウド プラットフォームが使用します。たとえば、ロードバランサのタイプを内部または外部に設定する場合などです。次に例を示します。

    ingressGateways:
      svcAnnotations:
        networking.gke.io/load-balancer-type: "Internal"

    アノテーションは、プラットフォームによって異なります。必須アノテーションと推奨アノテーションについては、プラットフォームのドキュメントをご覧ください。

    構成プロパティ リファレンスの ingressGateways[].svcAnnotations をご覧ください。
  • SVC_LOAD_BALANCER_IP(省略可)ロードバランサに静的 IP アドレスを割り当てることができます。ロードバランサの IP アドレスの指定をサポートするプラットフォームでは、この IP アドレスを使用してロードバランサが作成されます。ロードバランサの IP アドレスを指定できないプラットフォームでは、このプロパティは無視されます。

    ロードバランサに静的 IP アドレスが割り振られていない場合は、このプロパティをオーバーライド ファイルを含めないでください。

    構成プロパティ リファレンスの ingressGateways[].svcLoadBalancerIP をご覧ください。

オーバーライド ファイルをさらに変更して、オプションの v1.8 機能を有効または無効にします。

ハイブリッド v1.8 の新機能を有効にするには、次のプロパティを overrides.yaml ファイルに追加します。これらの機能はオプションです。

  • 組織をスコープとする UDCA がデフォルトで有効になりました。単一の UDCA デプロイを使用してすべての環境のトラフィックを処理することで、UDCA Pod の使用率低下は防止され、他の Apigee コンポーネントでノードリソースの可用性が向上します。組織をスコープとする UDCA は、すべての環境で単一のサービス アカウント apigee-udca を使用します。

    さまざまな環境で UDCA に異なるサービス アカウントを使用している場合は、envs:udca:serviceAccountPath を使用して環境レベルで指定されたものではなく、udca:serviceAccountPath を使用してオーバーライド ファイル内の組織レベルで指定されたサービス アカウントを使用することに注意してください。

    Apigee ハイブリッド v1.8 は、環境をスコープとする UDCA をサポートしています。環境ごとの UDCA を維持するには、orgScopedUDCA: false を設定します。

    構成プロパティ リファレンスの orgScopedUDCA をご覧ください。

  • validateOrg を有効にして、Apigee 組織と環境がアクティブであり、overrides ファイルで指定された Google Cloud Platform プロジェクトと連携していることの厳格な検証を求めます。
    validateOrg: true

    構成プロパティ リファレンスの validateOrg をご覧ください。

ハイブリッド 1.8.8 ランタイムをインストールする

  1. ハイブリッド ベース ディレクトリ(apigeectl 実行可能ファイルが配置されているディレクトリの親)にいることを確認します。
    cd $APIGEECTL_HOME/..
  2. 次のコマンドを使用して、ご利用のオペレーティング システムに対応したリリース パッケージをダウンロードします。ご利用のプラットフォームを次の表から選択します。

    Linux

    Linux 64 ビット:

    curl -LO \
      https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_linux_64.tar.gz

    macOS

    Mac 64 ビット:

    curl -LO \
      https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_mac_64.tar.gz

    Windows

    Windows 64 ビット

    curl -LO ^
      https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_windows_64.zip
  3. 現在の apigeectl/ ディレクトリをバックアップ ディレクトリ名に変更します。例:

    Linux

    mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/

    macOS

    mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/ 

    Windows

    rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.7 
  4. ダウンロードした gzip ファイルの内容をハイブリッドのベース ディレクトリに展開します。 ハイブリッドのベース ディレクトリは、名前が変更された apigeectl-v1.7 ディレクトリがあるディレクトリです。

    Linux

    tar xvzf filename.tar.gz -C ./

    macOS

    tar xvzf filename.tar.gz -C ./

    Windows

    tar xvzf filename.zip -C ./
  5. デフォルトでは、tar の内容が展開されるディレクトリの名前には、バージョンとプラットフォームが含まれています。たとえば、./apigeectl_1.8.8-xxxxxxx_linux_64 となります。次のコマンドを使用して、このディレクトリの名前を apigeectl に変更します。

    Linux

    mv apigeectl_1.8.8-xxxxxxx_linux_64 apigeectl

    macOS

    mv apigeectl_1.8.8-xxxxxxx_mac_64 apigeectl

    Windows

    rename apigeectl_1.8.8-xxxxxxx_windows_64 apigeectl
  6. apigeectl ディレクトリに移動します。
    cd ./apigeectl

    このディレクトリは apigeectl ホーム ディレクトリになります。apigeectl 実行可能コマンドはこのディレクトリに配置されます。

  7. この手順では、apigeectl ユーティリティがインストールされているファイル システムのディレクトリを表す環境変数 $APIGEECTL_HOME を使用します。必要に応じて、ディレクトリを apigeectl ディレクトリに変更し、次のコマンドで変数を定義します。

    Linux

    export APIGEECTL_HOME=$PWD
    echo $APIGEECTL_HOME

    Mac OS

    export APIGEECTL_HOME=$PWD
    echo $APIGEECTL_HOME

    Windows

    set APIGEECTL_HOME=%CD%
    echo %APIGEECTL_HOME%
  8. version コマンドで apigeectl のバージョンを確認します。
    ./apigeectl version
    Version: 1.8.8
  9. hybrid-base-directory/hybrid-files ディレクトリに移動します。hybrid-files ディレクトリには、オーバーライド ファイル、証明書、サービス アカウントなどの構成ファイルがあります。例:
    cd $APIGEECTL_HOME/../hybrid-files
  10. 次のコマンドを使用して、kubectl が正しいコンテキストに設定されていることを確認します。現在のコンテキストは、Apigee ハイブリッドをアップグレードするクラスタに設定する必要があります。
    kubectl config get-contexts | grep \*
  11. hybrid-files ディレクトリにおいて:
    1. 以下の $APIGEECTL_HOME へのシンボリック リンクを更新します。これらのリンクにより、hybrid-files ディレクトリから新しくインストールされた apigeectl コマンドを実行できます。
      ln -nfs $APIGEECTL_HOME/tools tools
      ln -nfs $APIGEECTL_HOME/config config
      ln -nfs $APIGEECTL_HOME/templates templates
      ln -nfs $APIGEECTL_HOME/plugins plugins
    2. シンボリック リンクが正しく作成されたことを確認するには、次のコマンドを実行してリンクパスが正しい場所を指していることを確認します。
      ls -l | grep ^l
  12. ドライランの初期化を行ってエラーを確認します。
    ${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE --dry-run=client

    ここで、OVERRIDES_FILE はオーバーライド ファイルの名前です(例: ./overrides/overrides.yaml)。

  13. エラーがなければ、ハイブリッド 1.8.8 を初期化します。このコマンドは、Apigee Ingress ゲートウェイもインストールして構成します。
    $APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
  14. 初期化のステータスを確認します。
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    成功すると、「All containers ready.」と出力されます。

    さらに、次のコマンドを実行して ApigeeDataStore のステータスを確認することもできます。

    kubectl describe apigeeds -n apigee

    出力で「State: running」を探します。

  15. --dry-run フラグを使用して、apply コマンドのドライランでエラーを確認します。
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --dry-run=client
  16. エラーがない場合、オーバーライドを適用します。インストールに応じて、本番環境または非本番環境用の手順を選択し実行します。

    本番

    本番環境では各ハイブリッド コンポーネントを個別にアップグレードし、次のコンポーネントに進む前に、アップグレードされたコンポーネントのステータスを確認します。

    1. hybrid-files ディレクトリに移動します。
    2. オーバーライドを適用して Cassandra をアップグレードします。
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
    3. 完了を確認します。
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

      Pod の準備ができた場合にのみ、次の手順に進みます。

    4. オーバーライドを適用してテレメトリー コンポーネントをアップグレードし、完了を確認します。
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --telemetry
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    5. Redis コンポーネントを起動します。
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis
    6. オーバーライドを適用して、組織レベルのコンポーネント(MART、Watcher、Apigee Connect)をアップグレードし、完了を確認します。
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --org
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    7. オーバーライドを適用して環境をアップグレードします。これには、次の 2 つの選択肢があります。
      • 環境別の環境: 一度に 1 つの環境にオーバーライドを適用して、完了を確認します。環境ごとにこの手順を繰り返します。
        $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --env ENV_NAME
        $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

        ここで、ENV_NAME はアップグレードする環境の名前です。

      • 一度にすべての環境: すべての環境にオーバーライドを一度に適用して、完了を確認します。
        $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --all-envs
        $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    8. オーバーライドを適用して virtualhosts コンポーネントをアップグレードし、完了を確認します。
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --settings virtualhosts
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    非本番環境

    非本番環境、デモ環境、試験運用版環境の大半では、すべてのコンポーネントに同時にオーバーライドを適用できます。非本番環境が大規模で複雑な場合や、本番環境とよく似ている場合は、本番環境をアップグレードするための手順の使用をおすすめします。

    1. hybrid-files ディレクトリに移動します。
    2. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE
    3. ステータスを確認します。
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

Kubernetes のバージョンをアップグレードする

Kubernetes プラットフォームをハイブリッド 1.8 でサポートされているバージョンにアップグレードします。 ヘルプが必要な場合は、プラットフォームのドキュメントをご覧ください。

トラフィックを Anthos Service Mesh から Apigee Ingress ゲートウェイに切り替えます。

トラフィックを Apigee Ingress ゲートウェイに切り替えるには:

  1. Apigee Ingress ゲートウェイを公開します。Apigee Ingress ゲートウェイの公開の手順を行います。
  2. プロキシを呼び出して、新しい Ingress ゲートウェイをテストします。現在デプロイされている重要なプロキシをすべてテストするのが理想的です。
  3. トラフィックを切り替えるには、新しい Apigee Ingress ゲートウェイの IP アドレスを指すように DNS レコードを更新します。DNS プロバイダによっては、トラフィックを新しいエンドポイントに段階的にシフトできる可能性があります。ヒント: Apigee Ingress ゲートウェイの外部 IP アドレスは、次のコマンドを使用して確認できます。
    kubectl get svc -n apigee -l app=apigee-ingressgateway

    出力は次のようになります。

    NAME                                        TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                      AGE
    apigee-ingressgateway-prod-hybrid-37a39bd   LoadBalancer   192.0.2.123   233.252.0.123   15021:32049/TCP,80:31624/TCP,443:30723/TCP   16h
  4. ダッシュボードをモニタリングして、すべてのランタイム トラフィックが機能していることを確認します。すべてが想定どおりに動作している場合にのみ、次の手順に進みます。DNS キャッシュが原因で DNS 更新の伝播に時間がかかることがあるため、古い Ingress ゲートウェイ(Anthos Service Mesh)を経由するトラフィックがないことを確認します。
  5. Apigee から Anthos Service Mesh への構成の提供を停止するには、Apigee Ingress ゲートウェイの管理ガイドの ASM への構成の提供を停止するの手順を行います。
  6. API プロキシ トラフィックを再度テストしてモニタリングします。
  7. Anthos Service Mesh のドキュメントの手順に沿って、クラスタから Anthos Service Mesh をアンインストールします。

Anthos Service Mesh をバージョン 1.15 にアップグレードする

手順は、使用しているプラットフォームに適した Anthos Service Mesh のドキュメントを使用して実行します。

Anthos Service Mesh をインストールして構成する手順は、プラットフォームによって異なります。プラットフォームは、次のカテゴリに分類されます。

  • GKE: Google Cloud で実行されている Google Kubernetes Engine クラスタ。
  • Google Cloud 以外: 次の場所で実行されている Anthos クラスタ。
    • Anthos clusters on VMware(GKE On-Prem)
    • ベアメタル版 Anthos
    • Anthos clusters on AWS
    • Amazon EKS
  • その他の Kubernetes プラットフォーム: 次で作成され実行される正規のクラスタ。
    • AKS
    • EKS
    • OpenShift

GKE

ハイブリッド インストール用に Anthos Service Mesh をバージョン 1.13.9 にアップグレードする手順は次のとおりです。

  1. アップグレードの準備をします。
  2. 新しいバージョンの Anthos Service Mesh をインストールします。
  3. 以前の Anthos Service Mesh バージョンのデプロイ、サービス、Webhook を、現在のインストールから削除します。
  4. ゲートウェイをアップグレードして新しい Webhook を構成します。

Anthos Service Mesh をバージョン 1.13.9にアップグレードするための準備

  1. Anthos Service Mesh のアップグレードの要件を確認します。ただし、まだアップグレードは行わないでください。
  2. 新しいバージョンをインストールする前に、現在のリビジョンを確認します。この情報は、現在のインストールから以前の Anthos Service Mesh バージョンの Deployment、Service、Webhook を削除する際に必要になります。現在の istiod リビジョンを環境変数に格納するには、次のコマンドを使用します。
    export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
    echo $DELETE_REV

    出力は 1.12.9-asm.2 のようになります。

  3. 新しい overlay.yaml ファイルを作成するか、既存の overlay.yaml に次の内容が含まれていることを確認します。
    apiVersion: install.istio.io/v1alpha1
    kind: IstioOperator
    spec:
      components:
        ingressGateways:
        - name: istio-ingressgateway
          enabled: true
          k8s:
            nodeSelector:
              # default node selector, if different or not using node selectors, change accordingly.
              cloud.google.com/gke-nodepool: apigee-runtime
            resources:
              requests:
                cpu: 1000m
            service:
              type: LoadBalancer
              loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
              ports:
                - name: http-status-port
                  port: 15021
                - name: http2
                  port: 80
                  targetPort: 8080
                - name: https
                  port: 443
                  targetPort: 8443
      meshConfig:
        accessLogFormat:
          '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  4. Anthos Service Mesh のドキュメントの次のセクションを行います。
    1. asmcli をダウンロードする
    2. クラスタ管理者の権限を付与する
    3. プロジェクトとクラスタを検証する
    4. オプション機能を使用してアップグレードする。「Gateway のアップグレード セクション」には、まだ進まないでください。
  5. 新しいコントロール プレーンに切り替えます。
    1. istiod のリビジョン ラベルを取得します。
      kubectl get pod -n istio-system -L istio.io/rev

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

          NAME                                  READY  STATUS  RESTARTS   AGE  REV
          istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
          istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
          istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
          istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
    2. 新しいリビジョン ラベルを環境変数に割り当てます。

      出力の REV 列にある、新しいバージョンのリビジョン ラベルの値をメモします。この例での値は asm-1139-10 です。

      export UPGRADE_REV="REVISION_LABEL"
    3. 次のコマンドを使用して、リビジョン ラベルを istio-system Namespace に追加し、istio-injection ラベルを削除します(存在する場合)。
      kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite

      出力に "istio-injection not found" が表示された場合は、無視してかまいません。これは、以前、名前空間に istio-injection ラベルが付加されていなかったことを意味します。名前空間に istio-injection とリビジョン ラベルの両方があると自動インジェクションが失敗するため、Anthos Service Mesh ドキュメント内のすべての kubectl label コマンドには istio-injection ラベルの削除が含まれています。

    4. Pod を再起動してインジェクションを再度トリガーします。
      kubectl rollout restart deployment -n istio-system
    5. アプリケーションをテストして、ワークロードが正しく機能していることを確認します。
    6. 他の名前空間にワークロードがある場合は、手順を繰り返して名前空間にラベルを付け、Pod を再起動します。
  6. 以前のバージョンを削除します。
    1. asmcli をインストールしたディレクトリに移動します。
    2. Anthos Service Mesh インストールの出力ディレクトリを DIR_PATH 環境変数に保存します。これは、オプション機能を使用したアップグレードの手順で指定したディレクトリと同じです。
      export DIR_PATH=OUTPUT_DIR
    3. 次のコマンドを含むシェル スクリプトを作成します。
      #!/bin/bash
      
      set -ex
      
      if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
        kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
        kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
      fi
      
    4. スクリプトを実行して、以前のバージョンを削除します。

Google Cloud 以外

ここでは、Anthos Service Mesh のアップグレードについて説明します。

  • Anthos clusters on VMware(GKE On-Prem)
  • ベアメタル版 Anthos
  • Anthos clusters on AWS
  • Amazon EKS

ハイブリッド インストール用に Anthos Service Mesh をバージョン 1.13.9 にアップグレードする手順は次のとおりです。

  1. アップグレードの準備をします。
  2. 新しいバージョンの Anthos Service Mesh をインストールします。
  3. 以前の Anthos Service Mesh バージョンのデプロイ、サービス、Webhook を、現在のインストールから削除します。
  4. ゲートウェイをアップグレードして新しい Webhook を構成します。

Anthos Service Mesh をバージョン 1.13.9にアップグレードするための準備

  1. Anthos Service Mesh のアップグレードの要件を確認します。ただし、まだアップグレードは行わないでください。
  2. 新しいバージョンをインストールする前に、現在のリビジョンを確認します。この情報は、現在のインストールから以前の Anthos Service Mesh バージョンの Deployment、Service、Webhook を削除する際に必要になります。現在の istiod リビジョンを環境変数に格納するには、次のコマンドを使用します。
    export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
    echo $DELETE_REV

    出力は 1.12.9-asm.2 のようになります。

  3. 新しい overlay.yaml ファイルを作成するか、既存の overlay.yaml に次の内容が含まれていることを確認します。
    apiVersion: install.istio.io/v1alpha1
    kind: IstioOperator
    spec:  
      components:
        ingressGateways:
        - name: istio-ingressgateway
          enabled: true
          k8s:
            nodeSelector:
              # default node selector, if different or not using node selectors, change accordingly.
              cloud.google.com/gke-nodepool: apigee-runtime
            resources:
              requests:
                cpu: 1000m
            service:
              type: LoadBalancer
              loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
              ports:
                - name: http-status-port
                  port: 15021
                - name: http2
                  port: 80
                  targetPort: 8080
                - name: https
                  port: 443
                  targetPort: 8443
      values:
        gateways:
          istio-ingressgateway:
            runAsRoot: true
    
      meshConfig:
        accessLogFormat:
          '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  4. Anthos Service Mesh のドキュメントの次のセクションを行います。
    1. asmcli をダウンロードする
    2. クラスタ管理者の権限を付与する
    3. プロジェクトとクラスタを検証する
    4. オプション機能を使用してアップグレードする。「Gateway のアップグレード セクション」には、まだ進まないでください。
  5. 新しいコントロール プレーンに切り替えます。
    1. istiod のリビジョン ラベルを取得します。
      kubectl get pod -n istio-system -L istio.io/rev

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

          NAME                                  READY  STATUS  RESTARTS   AGE  REV
          istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
          istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
          istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
          istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
    2. 新しいリビジョン ラベルを環境変数に割り当てます。

      出力の REV 列にある、新しいバージョンのリビジョン ラベルの値をメモします。この例での値は asm-1139-10 です。

      export UPGRADE_REV="REVISION_LABEL"
    3. 次のコマンドを使用して、リビジョン ラベルを istio-system Namespace に追加し、istio-injection ラベルを削除します(存在する場合)。
      kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite

      出力に "istio-injection not found" が表示された場合は、無視してかまいません。これは、以前、名前空間に istio-injection ラベルが付加されていなかったことを意味します。名前空間に istio-injection とリビジョン ラベルの両方があると自動インジェクションが失敗するため、Anthos Service Mesh ドキュメント内のすべての kubectl label コマンドには istio-injection ラベルの削除が含まれています。

    4. Pod を再起動してインジェクションを再度トリガーします。
      kubectl rollout restart deployment -n istio-system
    5. アプリケーションをテストして、ワークロードが正しく機能していることを確認します。
    6. 他の名前空間にワークロードがある場合は、手順を繰り返して名前空間にラベルを付け、Pod を再起動します。
  6. 以前のバージョンを削除します。
    1. asmcli をインストールしたディレクトリに移動します。
    2. Anthos Service Mesh インストールの出力ディレクトリを DIR_PATH 環境変数に保存します。これは、オプション機能を使用したアップグレードの手順で指定したディレクトリと同じです。
      export DIR_PATH=OUTPUT_DIR
    3. 次のコマンドを含むシェル スクリプトを作成します。
      #!/bin/bash
      
      set -ex
      
      if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
        kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
        kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
      fi
      
    4. スクリプトを実行して、以前のバージョンを削除します。

AKS / EKS

Anthos 接続クラスタで Anthos Service Mesh(ASM)バージョン istio-1.13.9-asm.10 をアップグレードする以下のプロセスは、新規のインストールを実行する場合と同じです。

Anthos Service Mesh のインストールの準備

  1. 新しいバージョンをインストールする前に、現在のリビジョンを確認します。現在の Anthos Service Mesh インストールから検証 Webhook と変更 Webhook を削除するには、この情報が必要です。現在の istiod リビジョンを環境変数に格納するには、次のコマンドを使用します。
    export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
    echo $DELETE_REV

    出力は「1.12.9-asm.2」のようになります。

  2. Linux

  3. Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz
  4. 署名ファイルをダウンロードし、OpenSSL を使用して署名を検証します。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig
    openssl dgst -verify /dev/stdin -signature istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF
  5. ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
    tar xzf istio-1.13.9-asm.10-linux-amd64.tar.gz

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

    • samples ディレクトリにあるサンプル アプリケーション
    • Anthos Service Mesh のインストールに使用する istioctl コマンドライン ツールは、bin ディレクトリにあります。
    • Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。
  6. Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。
    cd istio-1.13.9-asm.10
  7. 利便性を考えて、/bin ディレクトリ内のツールを PATH に追加します。
    export PATH=$PWD/bin:$PATH
  8. Mac OS

  9. Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz
  10. 署名ファイルをダウンロードし、OpenSSL を使用して署名を検証します。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz.1.sig
    openssl dgst -sha256 -verify /dev/stdin -signature istio-1.13.9-asm.10-osx.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF
  11. ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
    tar xzf istio-1.13.9-asm.10-osx.tar.gz

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

    • samples ディレクトリにあるサンプル アプリケーション
    • Anthos Service Mesh のインストールに使用する istioctl コマンドライン ツールは、bin ディレクトリにあります。
    • Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。
  12. Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。
    cd istio-1.13.9-asm.10
  13. 利便性を考えて、/bin ディレクトリ内のツールを PATH に追加します。
    export PATH=$PWD/bin:$PATH
  14. Windows

  15. Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip
  16. 署名ファイルをダウンロードし、OpenSSL を使用して署名を検証します。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip.1.sig
    openssl dgst -verify - -signature istio-1.13.9-asm.10-win.zip.1.sig istio-1.13.9-asm.10.win.zip <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF
  17. ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
    tar xzf istio-1.13.9-asm.10-win.zip

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

    • samples ディレクトリにあるサンプル アプリケーション
    • Anthos Service Mesh のインストールに使用する istioctl コマンドライン ツールは、bin ディレクトリにあります。
    • Anthos Service Mesh 構成プロファイルは manifests\profiles ディレクトリにあります。
  18. Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。
    cd istio-1.13.9-asm.10
  19. 利便性を考えて、/bin ディレクトリ内のツールを PATH に追加します。
    set PATH=%CD%\bin:%PATH%
  20. Anthos Service Mesh Istio がインストールされているので、istioctl のバージョンを確認します。
    istioctl version
  21. コントロール プレーン コンポーネント用に istio-system という名前空間を作成します。
    kubectl create namespace istio-system

Anthos Service Mesh のインストール

  1. overlay.yaml ファイルを編集するか、次の内容の新しいファイルを作成します。
    apiVersion: install.istio.io/v1alpha1
    kind: IstioOperator
    spec:
      meshConfig:
        accessLogFile: /dev/stdout
        enableTracing: true
        accessLogFormat:
          '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
      components:
        ingressGateways:
        - name: istio-ingressgateway
          enabled: true
          k8s:
            service:
              type: LoadBalancer
              ports:
              - name: status-port
                port: 15021
                targetPort: 15021
              - name: http2
                port: 80
                targetPort: 8080
              - name: https
                port: 443
                targetPort: 8443
    
  2. asm-multicloud プロファイルを使用して、istioctl を使用して Anthos Service Mesh をインストールします。
    istioctl install \
        --set profile=asm-multicloud \
        --set revision="asm-1139-10" \
        --filename overlay.yaml

    出力は次のようになります。

    kubectl get pods -n istio-system
    NAME                                   READY   STATUS    RESTARTS   AGE
    istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
    istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
    istiod-asm-1139-10-798ffb964-2ls88       1/1     Running   0          3m21s
    istiod-asm-1139-10-798ffb964-fnj8c       1/1     Running   1          3m21s

    --set revision 引数は、istio.io/rev=asm-1139-10 形式のリビジョン ラベルを istiod に追加します。リビジョン ラベルは、自動サイドカー インジェクタ Webhook によって使用され、挿入されたサイドカーを特定の istiod リビジョンに関連付けます。名前空間のサイドカー自動挿入を有効にするには、istiod のラベルと一致するリビジョンのラベルを付ける必要があります。

  3. インストールが完了したことを確認します。
    kubectl get svc -n istio-system

    出力は次のようになります。

    NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
    istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
    istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
    istiod-asm-1139-10       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s
  4. 新しいコントロール プレーンに切り替えます。
    1. istiod のリビジョン ラベルを取得します。
      kubectl get pod -n istio-system -L istio.io/rev

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

          NAME                                  READY  STATUS  RESTARTS   AGE  REV
          istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
          istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
          istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
          istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
    2. 新しいリビジョン ラベルを環境変数に割り当てます。

      出力の REV 列にある、新しいバージョンのリビジョン ラベルの値をメモします。この例での値は asm-1139-10 です。

      export UPGRADE_REV="REVISION_LABEL"
    3. 次のコマンドを使用して、リビジョン ラベルを istio-system Namespace に追加し、istio-injection ラベルを削除します(存在する場合)。
      kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite

      出力に "istio-injection not found" が表示された場合は、無視してかまいません。これは、以前、名前空間に istio-injection ラベルが付加されていなかったことを意味します。名前空間に istio-injection とリビジョン ラベルの両方があると自動インジェクションが失敗するため、Anthos Service Mesh ドキュメント内のすべての kubectl label コマンドには istio-injection ラベルの削除が含まれています。

    4. Pod を再起動してインジェクションを再度トリガーします。
      kubectl rollout restart deployment -n istio-system
    5. アプリケーションをテストして、ワークロードが正しく機能していることを確認します。
    6. 他の名前空間にワークロードがある場合は、手順を繰り返して名前空間にラベルを付け、Pod を再起動します。
  5. 以前のバージョンを削除します。
    1. asmcli をインストールしたディレクトリに移動します。
    2. 次のコマンドを含むシェル スクリプトを作成します。
      #!/bin/bash
      
      set -ex
      
      if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
        kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
      fi
      
    3. スクリプトを実行して、以前のバージョンを削除します。

OpenShift

Anthos 接続クラスタで Anthos Service Mesh(ASM)バージョン istio-1.13.9-asm.10 をアップグレードする以下のプロセスは、新規のインストールを実行する場合と同じです。

Anthos Service Mesh のインストールの準備

  1. 新しいバージョンをインストールする前に、現在のリビジョンを確認します。現在の Anthos Service Mesh インストールから検証 Webhook と変更 Webhook を削除するには、この情報が必要です。現在の istiod リビジョンを環境変数に格納するには、次のコマンドを使用します。
    export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
    echo $DELETE_REV

    出力は「1.12.9-asm.2」のようになります。

  2. Linux

  3. 次の OpenShift CLI(oc)コマンドを使用して、anyuid セキュリティ コンテキスト制約(SCC)を istio-system に付与します。
    oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system
  4. Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz
  5. 署名ファイルをダウンロードし、OpenSSL を使用して署名を検証します。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig
    openssl dgst -verify /dev/stdin -signature istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF
  6. ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
    tar xzf istio-1.13.9-asm.10-linux-amd64.tar.gz

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

    • samples ディレクトリにあるサンプル アプリケーション
    • Anthos Service Mesh のインストールに使用する istioctl コマンドライン ツールは、bin ディレクトリにあります。
    • Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。
  7. Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。
    cd istio-1.13.9-asm.10
  8. 利便性を考えて、/bin ディレクトリ内のツールを PATH に追加します。
    export PATH=$PWD/bin:$PATH
  9. Mac OS

  10. 次の OpenShift CLI(oc)コマンドを使用して、anyuid セキュリティ コンテキスト制約(SCC)を istio-system に付与します。
    oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system
  11. Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz
  12. 署名ファイルをダウンロードし、OpenSSL を使用して署名を検証します。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz.1.sig
    openssl dgst -sha256 -verify /dev/stdin -signature istio-1.13.9-asm.10-osx.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF
  13. ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
    tar xzf istio-1.13.9-asm.10-osx.tar.gz

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

    • samples ディレクトリにあるサンプル アプリケーション
    • Anthos Service Mesh のインストールに使用する istioctl コマンドライン ツールは、bin ディレクトリにあります。
    • Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。
  14. Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。
    cd istio-1.13.9-asm.10
  15. 利便性を考えて、/bin ディレクトリ内のツールを PATH に追加します。
    export PATH=$PWD/bin:$PATH
  16. Windows

  17. 次の OpenShift CLI(oc)コマンドを使用して、anyuid セキュリティ コンテキスト制約(SCC)を istio-system に付与します。
    oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system
  18. Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip
  19. 署名ファイルをダウンロードし、OpenSSL を使用して署名を検証します。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip.1.sig
    openssl dgst -verify - -signature istio-1.13.9-asm.10-win.zip.1.sig istio-1.13.9-asm.10.win.zip <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF
  20. ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
    tar xzf istio-1.13.9-asm.10-win.zip

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

    • samples ディレクトリにあるサンプル アプリケーション
    • Anthos Service Mesh のインストールに使用する istioctl コマンドライン ツールは、bin ディレクトリにあります。
    • Anthos Service Mesh 構成プロファイルは manifests\profiles ディレクトリにあります。
  21. Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。
    cd istio-1.13.9-asm.10
  22. 利便性を考えて、/bin ディレクトリ内のツールを PATH に追加します。
    set PATH=%CD%\bin:%PATH%
  23. Anthos Service Mesh Istio がインストールされているので、istioctl のバージョンを確認します。
    istioctl version
  24. コントロール プレーン コンポーネント用に istio-system という名前空間を作成します。
    kubectl create namespace istio-system

検証 Webhook の構成

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

  1. 次の内容のファイルを、istiod-service.yaml という名前で作成します。
    apiVersion: v1
    kind: Service
    metadata:
      name: istiod
      namespace: istio-system
      labels:
        istio.io/rev: asm-1139-10
        app: istiod
        istio: pilot
        release: istio
    spec:
      ports:
        - port: 15010
          name: grpc-xds # plaintext
          protocol: TCP
        - port: 15012
          name: https-dns # mTLS with k8s-signed cert
          protocol: TCP
        - port: 443
          name: https-webhook # validation and injection
          targetPort: 15017
          protocol: TCP
        - port: 15014
          name: http-monitoring # prometheus stats
          protocol: TCP
      selector:
        app: istiod
        istio.io/rev: asm-1139-10
      meshConfig:
        accessLogFormat:
          '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  2. kubectl を使用して検証 Webhook 構成を適用します。
    kubectl apply -f istiod-service.yaml
  3. 構成が適用されたことを確認します。
    kubectl get svc -n istio-system

    レスポンスは次のようになります。

    NAME     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                 AGE
    istiod   ClusterIP   172.200.18.133   <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP   22s

Anthos Service Mesh のインストール

  1. overlay.yaml ファイルを編集するか、次の内容の新しいファイルを作成します。
    apiVersion: install.istio.io/v1alpha1
    kind: IstioOperator
    spec:
      meshConfig:
        accessLogFile: /dev/stdout
        enableTracing: true
        accessLogFormat:
          '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
      components:
        ingressGateways:
          - name: istio-ingressgateway
            enabled: true
            k8s:
              service:
                type: LoadBalancer
                ports:
                - name: status-port
                  port: 15021
                  targetPort: 15021
                - name: http2
                  port: 80
                  targetPort: 8080
                - name: https
                  port: 443
                  targetPort: 8443
    
  2. asm-multicloud プロファイルを使用して、istioctl を使用して Anthos Service Mesh をインストールします。
    istioctl install \
        --set profile=asm-multicloud \
        --set revision="asm-1139-10" \
        --filename overlayfile.yaml

    出力は次のようになります。

    kubectl get pods -n istio-system
    NAME                                   READY   STATUS    RESTARTS   AGE
    istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
    istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
    istiod-asm-1139-10-798ffb964-2ls88       1/1     Running   0          3m21s
    istiod-asm-1139-10-798ffb964-fnj8c       1/1     Running   1          3m21s

    --set revision 引数は、istio.io/rev=1.6.11-asm.1 形式のリビジョン ラベルを istiod に追加します。リビジョン ラベルは、自動サイドカー インジェクタ Webhook によって使用され、挿入されたサイドカーを特定の istiod リビジョンに関連付けます。名前空間のサイドカー自動挿入を有効にするには、istiod のラベルと一致するリビジョンのラベルを付ける必要があります。

  3. インストールが完了したことを確認します。
    kubectl get svc -n istio-system

    出力は次のようになります。

    NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
    istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
    istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
    istiod-asm-1139-10       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s
  4. 新しいコントロール プレーンに切り替えます。
    1. istiod のリビジョン ラベルを取得します。
      kubectl get pod -n istio-system -L istio.io/rev

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

          NAME                                  READY  STATUS  RESTARTS   AGE  REV
          istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
          istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
          istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
          istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
    2. 新しいリビジョン ラベルを環境変数に割り当てます。

      出力の REV 列にある、新しいバージョンのリビジョン ラベルの値をメモします。この例での値は asm-1139-10 です。

      export UPGRADE_REV="REVISION_LABEL"
    3. 次のコマンドを使用して、リビジョン ラベルを istio-system Namespace に追加し、istio-injection ラベルを削除します(存在する場合)。
      kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite

      出力に "istio-injection not found" が表示された場合は、無視してかまいません。これは、以前、名前空間に istio-injection ラベルが付加されていなかったことを意味します。名前空間に istio-injection とリビジョン ラベルの両方があると自動インジェクションが失敗するため、Anthos Service Mesh ドキュメント内のすべての kubectl label コマンドには istio-injection ラベルの削除が含まれています。

    4. Pod を再起動してインジェクションを再度トリガーします。
      kubectl rollout restart deployment -n istio-system
    5. アプリケーションをテストして、ワークロードが正しく機能していることを確認します。
    6. 他の名前空間にワークロードがある場合は、手順を繰り返して名前空間にラベルを付け、Pod を再起動します。
  5. 以前のバージョンを削除します。
    1. asmcli をインストールしたディレクトリに移動します。
    2. 次のコマンドを含むシェル スクリプトを作成します。
      #!/bin/bash
      
      set -ex
      
      if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
        kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
      fi
      
    3. スクリプトを実行して、以前のバージョンを削除します。

アップグレードのロールバック

以前のアップグレードをロールバックするには次のようにします。

  1. ハイブリッドのランタイム名前空間の完了したジョブをクリーンアップします。ここで、名前空間を指定した場合、NAMESPACE は、オーバーライド ファイルで指定された名前空間です。名前空間を指定しない場合、デフォルトの名前空間は apigee です。
    kubectl delete job -n NAMESPACE \
      $(kubectl get job -n NAMESPACE \
      -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
  2. apigee-system 名前空間の完了したジョブをクリーンアップします。
    kubectl delete job -n apigee-system \
      $(kubectl get job -n apigee-system \
      -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
  3. 以前のバージョンの apigeectl を含むディレクトリを指すように APIGEECTL_HOME 変数を変更します。次に例を示します。
    export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
  4. overrides ファイルに加えた変更を元に戻します。
    1. ingressGateways とそのすべてのプロパティを削除するか、コメントアウトします。
    2. virtualhosts.selector.app の値を前の値に設定します。次に例を示します。
      virtualhosts:
        - name: my-env-group
          selector:
            app: istio-ingressgateway
    3. ao.args.disableIstioConfigInAPIServer を削除するか、コメントアウトします。
  5. ロールバックするインストールのルート ディレクトリで、apigeectl apply を実行し、Pod のステータスを確認してから apigeectl init を実行します。必ずロールバックするバージョンの元のオーバーライド ファイルを使用してください。
    1. ハイブリッド ファイル ディレクトリで、apigeectl apply を実行します。
      $APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE

      ここで、ORIGINAL_OVERRIDES_FILE は、以前のバージョンのハイブリッド インストールのオーバーライド ファイルの相対パスとファイル名です(例: ./overrides/overrides1.7.yaml)。

    2. ポッドのステータスを確認します。
      kubectl -n NAMESPACE get pods

      ここで、NAMESPACE は Apigee ハイブリッドの名前空間です。

    3. apigeeds のステータスを確認します。
      kubectl describe apigeeds -n apigee

      出力は次のようになります。

      Status:
        Cassandra Data Replication:
        Cassandra Pod Ips:
          10.8.2.204
        Cassandra Ready Replicas:  1
        Components:
          Cassandra:
            Last Successfully Released Version:
              Revision:  v1-f8aa9a82b9f69613
              Version:   v1
            Replicas:
              Available:  1
              Ready:      1
              Total:      1
              Updated:    1
            State:        running
        Scaling:
          In Progress:         false
          Operation:
          Requested Replicas:  0
        State:                 running

      apigeeds Pod が実行されている場合にのみ、次の手順に進みます。

    4. 次のコマンドを実行して、アップグレード後に Message Processor の新しいレプリカ数の値をメモします。これらの値が、以前に設定した値と一致しない場合は、オーバーライド ファイルの値を、以前の構成と一致するように変更します。
      apigeectl apply -f ORIGINAL_OVERRIDES_FILE --dry-run=client --print-yaml --env ENV_NAME 2>/dev/null |grep "runtime:" -A 25 -B 1| grep "autoScaler" -A 2

      出力は次のようになります。

            autoScaler:
              minReplicas: 2
              maxReplicas: 10
    5. ハイブリッド v1.8.4 以前にロールバックする場合は、ハイブリッド v1.8.5 以降で使用されるコントローラ デプロイを削除します。
      kubectl -n apigee-system delete deploy apigee-controller-manager
    6. apigeectl init を実行します。
      $APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE
  6. Apigee Ingress ゲートウェイ マネージャーのデプロイを削除します。このコンポーネントは、Apigee ハイブリッド バージョン 1.8 以降にのみ関連します。
    kubectl delete deployment -n NAMESPACE apigee-ingress-gateway-manager

    ここで、NAMESPACE は Apigee ハイブリッドの Namespace です。