Azure Kubernetes Service 用の Istio ベースのサービス メッシュ アドオンをアップグレードする
この記事では、Azure Kubernetes Service (AKS) 用の Istio ベースのサービス メッシュ アドオンのアップグレード エクスペリエンスについて説明します。
Istio ベースのサービス メッシュ アドオンに対する新しいマイナー リビジョンまたはパッチのリリースに関するお知らせは、AKS リリース ノートで公開されています。
マイナー リビジョンのアップグレード
Istio アドオンでは、カナリア アップグレード プロセスを使ってマイナー リビジョンをアップグレードできます。 アップグレードが開始されると、新しい (カナリア) リビジョンのコントロール プレーンが古い (安定した) リビジョンのコントロール プレーンと一緒にデプロイされます。 その後、監視ツールを使ってこのプロセス中のワークロードの正常性を追跡しながら、データ プレーンのワークロードを手動でロール オーバーできます。 ワークロードの正常性に問題が見られない場合は、アップグレードを完了して新しいリビジョンのみがクラスターに残るようにすることができます。 それ以外の場合は、Istio の以前のリビジョンにロールバックできます。
サポートされている Istio のマイナー リビジョンを現在クラスターで使っている場合、一度に 1 つのマイナー リビジョンのアップグレードしか許可されません。 サポートされていないリビジョンの Istio をクラスターで使っている場合は、その Kubernetes バージョンでサポートされている最小の Istio マイナー リビジョンにアップグレードする必要があります。 その後は、再び一度に 1 つずつ、マイナー リビジョンのアップグレードを行うことができます。
次の例は、リビジョン asm-1-18 から asm-1-19 にアップグレードする方法を示しています。 手順はすべてのマイナー アップグレードで同じです。
az aks mesh get-upgrades コマンドを使って、アップグレード ターゲットとしてクラスターで使用できるリビジョンを確認します。
az aks mesh get-upgrades --resource-group $RESOURCE_GROUP --name $CLUSTERこのコマンドによって返されない新しいリビジョンが見込まれる場合は、最新のリビジョンと互換性を持つように、最初に AKS クラスターをアップグレードする必要がある場合があります。
クラスター上の既存のメッシュ リビジョンにメッシュ構成を設定している場合は、次の手順でカナリア アップグレードを開始する前に、
aks-istio-system名前空間の新しいリビジョンに対応する別の ConfigMap を作成する必要があります。 この構成は、新しいリビジョンのコントロール プレーンがクラスターにデプロイされた時点で適用されます。 詳細については、こちらをご覧ください。az aks mesh upgrade start を使って、リビジョン
asm-1-18からasm-1-19へのカナリア アップグレードを開始します。az aks mesh upgrade start --resource-group $RESOURCE_GROUP --name $CLUSTER --revision asm-1-19カナリア アップグレードとは、1.18 コントロール プレーンが 1.17 コントロール プレーンと一緒にデプロイされることを意味します。 これらは、アップグレードを完了するかロールバックするまで共存し続けます。
asm-1-18とasm-1-19の両方に対応するコントロール プレーン ポッドが存在することを確認します。istiodポッドを確認します。kubectl get pods -n aks-istio-system出力例:
NAME READY STATUS RESTARTS AGE istiod-asm-1-18-55fccf84c8-dbzlt 1/1 Running 0 58m istiod-asm-1-18-55fccf84c8-fg8zh 1/1 Running 0 58m istiod-asm-1-19-f85f46bf5-7rwg4 1/1 Running 0 51m istiod-asm-1-19-f85f46bf5-8p9qx 1/1 Running 0 51mイングレスが有効な場合は、イングレス ポッドを確認します。
kubectl get pods -n aks-istio-ingress出力例:
NAME READY STATUS RESTARTS AGE aks-istio-ingressgateway-external-asm-1-18-58f889f99d-qkvq2 1/1 Running 0 59m aks-istio-ingressgateway-external-asm-1-18-58f889f99d-vhtd5 1/1 Running 0 58m aks-istio-ingressgateway-external-asm-1-19-7466f77bb9-ft9c8 1/1 Running 0 51m aks-istio-ingressgateway-external-asm-1-19-7466f77bb9-wcb6s 1/1 Running 0 51m aks-istio-ingressgateway-internal-asm-1-18-579c5d8d4b-4cc2l 1/1 Running 0 58m aks-istio-ingressgateway-internal-asm-1-18-579c5d8d4b-jjc7m 1/1 Running 0 59m aks-istio-ingressgateway-internal-asm-1-19-757d9b5545-g89s4 1/1 Running 0 51m aks-istio-ingressgateway-internal-asm-1-19-757d9b5545-krq9w 1/1 Running 0 51m両方のリビジョンのイングレス ゲートウェイ ポッドがサイド バイ サイドでデプロイされていることを確認します。 ただし、サービスとその IP は不変のままです。
新しいポッドが新しいリビジョンとそのコントロール プレーンに関連付けられた Istio サイドカーを取得するように、名前空間のラベルを変更します。
kubectl label namespace default istio.io/rev=asm-1-19 --overwriteラベルの変更は、再起動されるまでワークロードには影響しません。
各アプリケーション ワークロードを再起動して、個別にロール オーバーします。 次に例を示します。
kubectl rollout restart deployment <deployment name> -n <deployment namespace>監視ツールとダッシュボードを調べて、再起動後にワークロードがすべて正常な状態で実行されているかどうかを確認します。 その結果に基づいて、次の 2 つの選択肢があります。
カナリア アップグレードを完了する: ワークロードがすべて期待どおりに正常な状態で実行されていることを確認できれば、カナリア アップグレードを完了できます。 アップグレードが完了すると、前のリビジョンのコントロール プレーンが削除され、新しいリビジョンのコントロール プレーンがクラスター上に残ります。 次のコマンドを実行して、カナリア アップグレードを完了します。
az aks mesh upgrade complete --resource-group $RESOURCE_GROUP --name $CLUSTERカナリア アップグレードをロールバックする: ワークロードの正常性に問題が見つかった場合は、Istio の以前のリビジョンにロールバックできます。
名前空間のラベルを前のリビジョンに書き換えます。
kubectl label namespace default istio.io/rev=asm-1-18 --overwriteこれらのワークロードをもう一度再起動して、以前の Istio リビジョンに対応するサイドカーを使うようにワークロードをロールバックします。
kubectl rollout restart deployment <deployment name> -n <deployment namespace>コントロール プレーンを以前のリビジョンにロールバックします。
az aks mesh upgrade rollback --resource-group $RESOURCE_GROUP --name $CLUSTER
以前、リビジョンに対してメッシュ構成を設定した場合、完了またはロールバック時にクラスターから削除されたリビジョンの ConfigMap を削除できるようになります。
Note
新しいリビジョンに移動するときに手動で名前空間のラベルを変更するのは、面倒でエラーが発生しやすい作業です。 リビジョン タグがこの問題を解決します。 リビジョン タグはリビジョンを指す安定した識別子であり、名前空間のラベル変更を回避するために使用できます。 メッシュ オペレーターでは、名前空間のラベルを変更するのではなく、新しいリビジョンを指すようにタグを変更するだけで済みます。 そのタグでラベル付けされたすべての名前空間が同時に更新されます。 ただし、確実に正しいバージョンの istio-proxy サイドカーが挿入されるようにするには、ワークロードを再起動する必要があることに注意してください。
イングレス ゲートウェイを使用したマイナー リビジョンのアップグレード
現在 Istio イングレス ゲートウェイを使用していて、マイナー リビジョンのアップグレードを実行している場合は、Istio イングレス ゲートウェイ ポッド/デプロイがリビジョンごとにデプロイされていることに注意してください。 ただし、複数のリビジョンにわたるすべてのイングレス ゲートウェイ ポッドに 1 つの LoadBalancer サービスを提供するため、イングレス ゲートウェイの外部/内部 IP アドレスはアップグレードの全期間を通じて変更されません。
したがって、カナリア アップグレード中に、クラスターに 2 つのリビジョンが同時に存在する場合、受信トラフィックは両方のリビジョンのイングレス ゲートウェイ ポッドによって処理されます。
パッチ バージョンのアップグレード
- 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.18.2-distroless", "image": "mcr.microsoft.com/oss/istio/proxyv2:1.18.2-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.18.0, mcr.microsoft.com/oss/istio/proxyv2:1.18.1-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.18.0, mcr.microsoft.com/oss/istio/proxyv2:1.18.2-distroless