次の方法で共有

Azure Kubernetes Service 用の Istio ベースのサービス メッシュ アドオンをアップグレードする

  • [アーティクル]

この記事では、Azure Kubernetes Service (AKS) 用の Istio ベースのサービス メッシュ アドオンのアップグレード エクスペリエンスについて説明します。

Istio ベースのサービス メッシュ アドオンに対する新しいマイナー リビジョンまたはパッチのリリースに関するお知らせは、AKS リリース ノートで公開されています。 サービス メッシュ アドオン リビジョンのリリース スケジュールとサポートの詳細については、サポート ポリシーに関する章を参照してください。

マイナー リビジョンのアップグレード

Istio アドオンでは、カナリア アップグレード プロセスを使ってマイナー リビジョンをアップグレードできます。 アップグレードが開始されると、新しい (カナリア) リビジョンのコントロール プレーンが初期 (安定した) リビジョンのコントロール プレーンと一緒にデプロイされます。 その後、監視ツールを使ってこのプロセス中のワークロードの正常性を追跡しながら、データ プレーンのワークロードを手動でロール オーバーできます。 ワークロードの正常性に問題が見られない場合は、アップグレードを完了して新しいリビジョンのみがクラスターに残るようにすることができます。 それ以外の場合は、Istio の以前のリビジョンにロールバックできます。

使用可能なアップグレードは、現在の Istio リビジョンと AKS クラスター バージョンがサポートされているかどうかによって異なります:

  • サポートされている次のリビジョン (n+1) にアップグレードするか、1 つをスキップして n+2 にアップグレードできます (両方がサポートされ、クラスターのバージョンと互換性がある場合)。
  • 現在のリビジョン (n) と次のリビジョン (n+1) の両方がサポートされていない場合は、サポートされている最も近いリビジョン (n+2 以降) にのみアップグレードできますが、それ以上のバージョンにはアップグレードできません。
  • クラスター バージョンと Istio リビジョンの両方がサポートされていない場合は、Istio アップグレードを開始する前にクラスター バージョンをアップグレードする必要があります。

Note

サポートされていないリビジョンからのアップグレードはエラーが発生しやすいため、Istio リビジョンを常に最新の状態に保つことをお勧めします。 新しいリビジョンの注目すべき変更については、「Istio アドオン サポート カレンダー」と「アップストリーム Istio リリース ノート」を参照してください。

次の例は、default 名前空間内のすべてのワークロードをリビジョン asm-1-22 から asm-1-23 にアップグレードする方法を示しています。 この手順は、どのようなマイナー アップグレードでも同じであり、任意の数の名前空間に使用できます。

  1. az aks mesh get-upgrades コマンドを使って、アップグレード ターゲットとしてクラスターで使用できるリビジョンを確認します。

    az aks mesh get-upgrades --resource-group $RESOURCE_GROUP --name $CLUSTER

    このコマンドによって返されない新しいリビジョンが見込まれる場合は、最新のリビジョンと互換性を持つように、最初に AKS クラスターをアップグレードする必要がある場合があります。

  2. クラスター上の既存のメッシュ リビジョンにメッシュ構成を設定している場合は、次の手順でカナリア アップグレードを開始する前に、aks-istio-system 名前空間の新しいリビジョンに対応する別の ConfigMap を作成する必要があります。 この構成は、新しいリビジョンのコントロール プレーンがクラスターにデプロイされた時点で適用されます。 詳細については、こちらをご覧ください。

  3. az aks mesh upgrade start を使って、リビジョン asm-1-22 から asm-1-23 へのカナリア アップグレードを開始します。

    az aks mesh upgrade start --resource-group $RESOURCE_GROUP --name $CLUSTER --revision asm-1-23

    カナリア アップグレードとは、1.23 コントロール プレーンが 1.22 コントロール プレーンと一緒にデプロイされることを意味します。 これらは、アップグレードを完了するかロールバックするまで共存し続けます。

  4. 必要に応じて、リビジョン タグを使用して、各名前空間に手動でラベルを付け直すことなく、データ プレーンを新しいリビジョンにロールオーバーできます。 新しいリビジョンに移動するときに手動で名前空間のラベルを変更するのは、面倒でエラーが発生しやすい作業です。 リビジョン タグをリビジョンを指す安定した識別子として利用することで、この問題は解決します。

    各名前空間のラベルを付け直すのではなく、クラスター オペレーターで、新しいリビジョンを指すようにタグを変更できます。 そのタグでラベル付けされたすべての名前空間が同時に更新されます。 ただし、確実に正しいバージョンの istio-proxy サイドカーが挿入されるようにするには、ワークロードを再起動する必要があります。

    アップグレード中にリビジョン タグを使用するには:

    1. istioctl CLI をインストールする

    2. 最初のリビジョンのリビジョン タグを作成します。 この例では、prod-stable という名前を付けます。

      istioctl tag set prod-stable --revision asm-1-22 --istioNamespace aks-istio-system

    3. アップグレード時にインストールされるリビジョンのリビジョン タグを作成します。 この例では、prod-canary という名前を付けます。

      istioctl tag set prod-canary --revision asm-1-23 --istioNamespace aks-istio-system

    4. リビジョン タグにマップするアプリケーションの名前空間にラベルを付けます。

      # label default namespace to map to asm-1-22
kubectl label ns default istio.io/rev=prod-stable --overwrite

      新しいリビジョンの名前空間に istio.io/rev=prod-canary というラベルを付けることもできます。 ただし、このような名前空間内のワークロードは、再起動されるまで新しいサイドカーに更新されません。

      ラベルが付けられた後に名前空間内に新しいアプリケーションが作成される場合、その名前空間のリビジョン タグに対応するサイドカーが挿入されます。

  5. asm-1-22 と asm-1-23 の両方に対応するコントロール プレーン ポッドが存在することを確認します。

    1. istiod ポッドを確認します。

      kubectl get pods -n aks-istio-system

      出力例:

      NAME                                        READY   STATUS    RESTARTS   AGE
istiod-asm-1-22-55fccf84c8-dbzlt            1/1     Running   0          58m
istiod-asm-1-22-55fccf84c8-fg8zh            1/1     Running   0          58m
istiod-asm-1-23-f85f46bf5-7rwg4             1/1     Running   0          51m
istiod-asm-1-23-f85f46bf5-8p9qx             1/1     Running   0          51m

    2. イングレスが有効な場合は、イングレス ポッドを確認します。

      kubectl get pods -n aks-istio-ingress

      出力例:

      NAME                                                          READY   STATUS    RESTARTS   AGE
aks-istio-ingressgateway-external-asm-1-22-58f889f99d-qkvq2   1/1     Running   0          59m
aks-istio-ingressgateway-external-asm-1-22-58f889f99d-vhtd5   1/1     Running   0          58m
aks-istio-ingressgateway-external-asm-1-23-7466f77bb9-ft9c8   1/1     Running   0          51m
aks-istio-ingressgateway-external-asm-1-23-7466f77bb9-wcb6s   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-22-579c5d8d4b-4cc2l   1/1     Running   0          58m
aks-istio-ingressgateway-internal-asm-1-22-579c5d8d4b-jjc7m   1/1     Running   0          59m
aks-istio-ingressgateway-internal-asm-1-23-757d9b5545-g89s4   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-23-757d9b5545-krq9w   1/1     Running   0          51m

      両方のリビジョンのイングレス ゲートウェイ ポッドがサイド バイ サイドでデプロイされていることを確認します。 ただし、サービスとその IP は不変のままです。

  6. 新しいポッドが新しいリビジョンとそのコントロール プレーンに関連付けられた Istio サイドカーにマップされるように、名前空間のラベルを変更します。

    1. リビジョン タグを使用する場合は、prod-stable タグ自体を上書きしてマッピングを変更します。

      istioctl tag set prod-stable --revision asm-1-23 --istioNamespace aks-istio-system --overwrite

      タグとリビジョンのマッピングを確認します。

      istioctl tag list

      両方のタグが新しくインストールされたリビジョンを指している必要があります。

      TAG           REVISION   NAMESPACES
prod-canary   asm-1-23   default
prod-stable   asm-1-23   ...

      この場合、各名前空間を個別にラベルを付け直す必要はありません。

    2. リビジョン タグを使用しない場合は、新しいリビジョンを指すようにデータ プレーンの名前空間のラベルを変更する必要があります。

      kubectl label namespace default istio.io/rev=asm-1-23 --overwrite

    ラベルの変更は、再起動されるまでワークロードには影響しません。

  7. 各アプリケーション ワークロードを再起動して、個別にロール オーバーします。 次に例を示します。

    kubectl rollout restart deployment <deployment name> -n <deployment namespace>

  8. 監視ツールとダッシュボードを調べて、再起動後にワークロードがすべて正常な状態で実行されているかどうかを確認します。 その結果に基づいて、次の 2 つの選択肢があります。

    1. カナリア アップグレードを完了する: ワークロードがすべて期待どおりに正常な状態で実行されていることを確認できれば、カナリア アップグレードを完了できます。 アップグレードが完了すると、前のリビジョンのコントロール プレーンが削除され、新しいリビジョンのコントロール プレーンがクラスター上に残ります。 次のコマンドを実行して、カナリア アップグレードを完了します。

      az aks mesh upgrade complete --resource-group $RESOURCE_GROUP --name $CLUSTER

    2. カナリア アップグレードをロールバックする: ワークロードの正常性に問題が見つかった場合は、Istio の以前のリビジョンにロールバックできます。

    • 名前空間のラベルを以前のリビジョンに付け直します: リビジョン タグを使用している場合:

      istioctl tag set prod-stable --revision asm-1-22 --istioNamespace aks-istio-system --overwrite

      または、リビジョン タグを使用しない場合:

      kubectl label namespace default istio.io/rev=asm-1-22 --overwrite

    • これらのワークロードをもう一度再起動して、以前の Istio リビジョンに対応するサイドカーを使うようにワークロードをロールバックします。

      kubectl rollout restart deployment <deployment name> -n <deployment namespace>

    • コントロール プレーンを以前のリビジョンにロールバックします。

      az aks mesh upgrade rollback --resource-group $RESOURCE_GROUP --name $CLUSTER

    prod-canary リビジョン タグは削除できます。

    istioctl tag remove prod-canary --istioNamespace aks-istio-system

  9. 以前、リビジョンに対してメッシュ構成を設定した場合、完了またはロールバック時にクラスターから削除されたリビジョンの ConfigMap を削除できるようになります。

イングレス ゲートウェイを使用したマイナー リビジョンのアップグレード

現在 Istio イングレス ゲートウェイを使用していて、マイナー リビジョンのアップグレードを実行している場合は、Istio イングレス ゲートウェイ ポッド/デプロイがリビジョンごとにデプロイされていることに注意してください。 ただし、複数のリビジョンにわたるすべてのイングレス ゲートウェイ ポッドに 1 つの LoadBalancer サービスを提供するため、イングレス ゲートウェイの外部/内部 IP アドレスはアップグレードの全期間を通じて変更されません。

したがって、カナリア アップグレード中に、クラスターに 2 つのリビジョンが同時に存在する場合、両方のリビジョンのイングレス ゲートウェイ ポッドによって受信トラフィックが処理されます。

水平ポッド自動スケーリングをカスタマイズしたマイナー リビジョンのアップグレード

Istiod またはイングレス ゲートウェイの水平ポッド自動スケーリング (HPA) 設定をカスタマイズしている場合は、カナリア アップグレード時の整合性を維持するため、以下のような挙動で両方のリビジョンに対して HPA 設定が適用されることにご注意ください。

  • アップグレードを開始する前に HPA 仕様を更新すると、新しいコントロール プレーンのインストール時に、既存の (安定した) リビジョンの設定がカナリア リビジョンの HPA に適用されます。
  • カナリア アップグレードの実行中に HPA 仕様を更新すると、安定リビジョンの HPA 仕様が優先され、カナリア リビジョンの HPA に適用されます。
    • アップグレード中に安定リビジョンの HPA を更新すると、カナリア リビジョンの HPA 仕様は、安定したリビジョンに適用された新しい設定を反映するように更新されます。
    • アップグレード中にカナリア リビジョンの HPA を更新すると、カナリア リビジョンの HPA 仕様は安定リビジョンの HPA 仕様に戻されます。

パッチ バージョンのアップグレード

  • Istio アドオンのパッチ バージョンの可用性情報は、AKS のリリース ノートで公開されています。
  • これらの AKS リリースの一部として、istiod およびイングレス ポッドに対してパッチが自動的にロールアウトされ、クラスターに設定された default計画メンテナンス期間が順守されます。
  • ユーザーは、再導入のために次のポッドを再起動して、ワークロードで Istio プロキシへのパッチを開始する必要があります。

    • 新しいポッドまたは再起動されたポッド用の Istio プロキシのバージョンを確認します。 このバージョンは、パッチが適用された後の istiod および Istio イングレス ポッドのバージョンと同じです。

      kubectl get cm -n aks-istio-system -o yaml | grep "mcr.microsoft.com\/oss\/istio\/proxyv2"

      出力例:

      "image": "mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless",
"image": "mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless"

    • 名前空間内のすべてのポッドの Istio プロキシ イメージのバージョンを確認します。

      kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort |\
grep "mcr.microsoft.com\/oss\/istio\/proxyv2"

      出力例:

      productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.22.0, mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless

    • 再挿入をトリガーするため、ワークロードを再起動します。 次に例を示します。

      kubectl rollout restart deployments/productpage-v1 -n default

    • 新しいバージョンになっていることを確認するには、名前空間内のすべてのポッドに対して Istio プロキシ イメージ のバージョンをもう一度確認します。

      kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort |\
grep "mcr.microsoft.com\/oss\/istio\/proxyv2"

      出力例:

      productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.2.0, mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless

Note

アップグレード中に発生した問題が発生した場合は、メッシュ リビジョンのアップグレードのトラブルシューティングに関するページを参照してください