ACKクラスターを手動でアップグレードするか、制御プレーンとノードプールを個別にアップグレードする - Container Service for Kubernetes

古いクラスターバージョンには、セキュリティと安定性の問題があります。 Container Service for Kubernetes (ACK) は、ビジネスの継続性を確保するために、クラスターのインプレースアップグレードを使用しています。 ACKコンソールでACKクラスターのKubernetesバージョンをアップグレードしたり、クラスターのコントロールプレーンとノードプールを個別に更新したりできます。このトピックでは、アップグレード前後の使用上の注意事項と、ACKクラスターのアップグレード手順について説明します。

ACKクラスターが必要な理由s

ACKは、最新の3つのKubernetesマイナーバージョンの作成を保証します。たとえば、ACKがアップグレードされて、Kubernetes 1.28、1.30、および1.31の偶数バージョンをサポートすると、ACKはKubernetes 1.26のサポートを中止します。この場合、Kubernetes 1.26を実行するACKクラスターを作成できなくなります。

積極的なアップグレードには、次の利点があります。

セキュリティと安定性のリスクの軽減: Kubernetesの新しいバージョンは通常リリースされ、最適化とパッチのセキュリティと安定性の脆弱性が追加されます。古いKubernetesクラスターを使用すると、ビジネスにセキュリティと安定性のリスクが生じる可能性があります。
テクニカルサポートとカスタマーサービスの改善: ACKは、古いKubernetesバージョンのセキュリティパッチや修復をリリースしなくなりました。また、ACKは、古いKubernetesバージョンのテクニカルサポートの品質を保証するものではありません。新しいバージョンのKubernetesを使用すると、テクニカルサポートとカスタマーサービスが向上します。
新機能: オープンソースKubernetesのイテレーションには、通常、新機能と改良が加えられています。 ACKはこれらの機能もサポートし、開発とメンテナンスのエクスペリエンスを最適化します。

さらに、セキュリティのために、ACKは古いACKクラスターを強制的にアップグレードする権利を留保します。 ACKクラスターをプロアクティブにアップグレードするには、次の手順を実行することを推奨します。

重要

ACKクラスターをアップグレードすると、ACKはクラスターで事前チェックを実行しますが、ACKは互換性のないすべての機能、設定、およびAPIが検出されることを保証するものではありません。共有責任モデルによると、クラスターをアップグレードする前に、ドキュメント、コンソールの情報、内部メッセージを確認してKubernetesバージョンのリリースに注意を払い、対応するバージョンのアップグレードに関する注意事項を確認することをお勧めします。

ACKがKubernetesバージョンをサポートする方法の詳細については、「Kubernetesバージョンのサポート」をご参照ください。

使用法ノート (重要)

Kubernetesのバージョン

ACKクラスターは、あるバージョンから次のバージョンにのみアップグレードできます。たとえば、ACKクラスターのKubernetesバージョンを1.28から1.31にアップグレードするには、まずクラスターをKubernetes 1.30にアップグレードしてから、Kubernetes 1.31にアップグレードする必要があります。

KubernetesバージョンのACKクラスターを表示するには、ACKコンソールにログインします。 [クラスター] ページに移動し、管理するクラスターを見つけて、[バージョン] 列を確認します。クラスターをアップグレードするKubernetesバージョンを決定したら、対応するKubernetesバージョンのサポートを参照して、バージョンの詳細、廃止されたAPI、およびアップグレードの使用状況ノートを確認してください。対応するKubernetesバージョンのリリースノートをお読みください。これにより、新しいバージョンのKubernetesで機能の更新によって引き起こされる互換性の問題を回避できます。

説明

HelmグラフのYAMLファイルが廃止されたリソースを使用している場合は、できるだけ早い機会にファイルを変更してください。詳細については、前述のリリースノートおよび「クラスターの問題を修正する方法に関するクラスターチェック項目と提案」トピックの非推奨APIセクションを参照してください。

機能とカスタム設定

ACKクラスターが次の表に示す機能を使用している場合は、注意事項と推奨される解決策をお読みください。

機能	注意	推奨ソリューション
FlexVolume	FlexVolume 1.11.2.5以前を使用してマウントされたObject Storage Service (OSS) ボリュームは、クラスターのアップグレード中に再マウントされます。	アップグレードが完了したら、OSSボリュームを使用するポッドを再作成する必要があります。 FlexVolumeは中止されました。 CSIを使用することを推奨します。詳細については、次をご参照ください： FlexVolumeからCSIへのアップグレード
ノードの自動スケーリング	自動スケーリングが有効になっている場合、クラスターがアップグレードされた後、クラスターは自動的にcluster-autoscalerを最新バージョンに更新します。これにより、自動スケーリング機能を期待どおりに使用できます。自動スケーリングを有効にすると、迅速モードのノードがシャットダウンし、更新に失敗する可能性があります。	cluster-autoscalerが最新バージョンに更新されていることを確認してください。詳細については、「ノードの自動スケーリングの有効化」をご参照ください。クラスターのアップグレード後に迅速モードのノードの更新に失敗した場合、ノードを手動で削除することを推奨します。
リソース予約	ACKクラスターを1.18にアップグレードすると、ACKはリソース予約を自動的に設定します。リソース予約がクラスターに設定されておらず、ノードのリソース使用率が高い場合、ACKは、クラスターのアップグレード後にノードに追い出されたポッドをスケジュールできない可能性があります。	ノードに十分なリソースを確保します。少なくとも50% のCPUリソースと少なくとも70% のメモリリソースを予約することを推奨します。詳細については、「リソース予約ポリシー」をご参照ください。
LoadBalancer設定	ACK Edgeクラスターでは、外部アクセスを処理するためにServer Load Balancer (SLB) インスタンスが必要です。ただし、SLBインスタンスに`externalTrafficPolicy: Local`が指定されている場合、トラフィックはノードローカルポッドにのみ転送されます。アプリケーションポッドが他のノードにデプロイされている場合、トラフィックはこれらのポッドに到達できません。	SLBインスタンスがトラフィックをアプリケーションポッドに転送できない場合に備えて、SLBインスタンスにexternalTrafficPolicy: Localが指定されているかどうかを確認します。詳細については、次をご参照ください： LoadBalancerサービスによって公開されているSLBインスタンスのIPアドレスにクラスターがアクセスできない場合の対処方法
APIサーバー	ACKは、クラスタをアップグレードするとき、クラスタ内のアプリケーションとの通信を中断することなく、制御プレーンを更新しようと試みる。ただし、APIサーバとの通信が一時的に中断される場合があります。割り込みは、APIサーバーに強く依存するアプリケーションに影響します。たとえば、アプリケーションがリソースを一覧表示して監視する必要がある場合、APIサーバーの再起動時に監視操作が中断されます。この問題を解決するには、中断が発生したときに監視操作を自動的に再試行するようにアプリケーションを設定する必要があります。	アプリケーションがAPIサーバーにアクセスする必要がない場合、アプリケーションはアップグレードの影響を受けません。
スタートアッププローブ	クラスター内のポッドに起動プローブが設定されている場合、kubeletが再起動された後、ポッドは一時的にNotReady状態になることがあります。	複数のレプリケートされたポッドをデプロイし、ポッドをノード間に分散することを推奨します。これにより、ノードの1つが再起動しても、アプリケーションに十分なポッドが確保されます。
kubectl	クラスターのアップグレード後、オンプレミスマシンでkubectlを更新することを推奨します。そうしないと、kubectlバージョンがAPIサーバーバージョンと互換性がなくなります。その結果、`無効なオブジェクトに追加のプロパティがありません`エラーメッセージが表示されることがあります。	kubectlをインストールまたは更新します。詳細については、「ツールのインストール」をご参照ください。

クラスターでカスタム設定を使用する場合は、次の表の説明をお読みください。

機能	説明
ネットワーク	クラスターをアップグレードするには、Yumを使用して必要なソフトウェアパッケージをダウンロードする必要があります。クラスターでカスタムネットワーク設定またはカスタムOSイメージを使用している場合は、Yumが期待どおりに実行できるようにする必要があります。 `yum makecache`コマンドを実行して、Yumのステータスを確認できます。
OSイメージ	カスタムOSイメージは、ACKによって厳密に検証されません。 ACKは、クラスターがカスタムOSイメージを使用している場合にクラスターをアップグレードできることを保証するものではありません。
その他	CLIを使用して変更されたスワップパーティションやkubelet設定など、クラスターが他のカスタム設定を使用している場合、クラスターのアップグレードに失敗したり、アップグレード中にカスタム設定が失われる可能性があります。

アップグレード手順、メソッド、および期間

U pgradeプロセス

準備と事前チェック:
- 使用状況ノート: クラスターをアップグレードする前に、対応するKubernetesバージョンのリリースノートを読んで、アップグレードの使用状況ノートを確認してください。これにより、機能の更新による互換性の問題を回避できます。詳細については、このトピックの「Kubernetesバージョン」セクションをご参照ください。
- 事前チェック: 事前チェックを実行して、潜在的なアップグレードリスクを特定します。アップグレードのリスクが特定されている場合は、コンソールの指示に従うか、クラスターのチェック項目とクラスターの問題の修正方法に関する提案を参照して問題を修正します。
クラスターアップグレード: クラスターが事前チェックに合格した後、コントロールプレーンとノードプールを含むクラスターを更新できます。 ACKを使用すると、次のモードでクラスターを更新できます。
- 同時更新: 制御プレーンとノードプールが同時に更新されます。
- Separate update: ACKは最初に制御プレーンを更新し、次にノードプールを更新します。
制御プレーンの更新には、主要コンポーネントkube − apiserverが関与する。ノードプールの更新には、kubeletとその依存コンポーネントが含まれます。クラスターの安定性と信頼性を確保するために、ACKはkube-apiserverがkubeletより2つ前のバージョンであることを確認する必要があります。この要件を満たすために、ACKは、制御プレーンを別々に更新し、次いでオフピーク時間中にノードプールを更新する必要がある。
クラスターの更新後: クラスターとkubeletのバージョンを確認し、ノードプールが正常に実行されるかどうかを確認し、クラスター内のアプリケーションが正常に実行されるかどうかを確認します。

更新方法

制御プレーンの更新

ACK管理クラスターおよびACKサーバーレスクラスター

ACKマネージドクラスターとACKサーバーレスクラスターは、ローリング更新を使用します。手順：

kube-apiserver、kube-controller-manager、cloud-controller-manager、kube-schedulerなどの制御プレーンと管理された制御プレーンコンポーネントを更新します。
kube-proxyなどのKubernetesコンポーネントを更新します。

ACK専用クラスター

ACK専用クラスターはインプレース更新を使用して、ビジネスの継続性を確保し、データ移行と構成変更によってもたらされる潜在的なリスクを軽減します。手順：

ACKがクラスター内のetcdとコンテナランタイムを更新する必要があることを識別すると、各マスターノードのetcdとコンテナランタイムが順番に更新されます。
システムは毎回1つのマスターノードのみを更新し、マスターノードのIDを表示します。
kube-apiserver、kube-controller-manager、cloud-controller-manager、kube-schedulerなどのマスターコンポーネントを更新します。
マスターノードのkubeletを更新します。
すべてのマスターノードが更新された後、kube-proxyなどのKubernetesコンポーネントを更新します。

ノードプールの更新

ノードプールの更新中に、kubelet、OSイメージ、およびコンテナーランタイムが更新されます。 OSを置き換えたり、コンテナランタイムをDockerからcontainerdに更新したりするには、更新中にACKがノードのシステムディスクを置き換える必要があります。クラスターを更新する前に、ノードのシステムディスクのデータをバックアップすることを推奨します。他のシナリオでは、ACKはインプレース更新を使用してノードプールを更新する。詳細については、「ノードプールの更新」をご参照ください。

ACKクラスター内のノードは、次のバッチ更新戦略に基づいてバッチで更新されます。

ACKは、ノードプールを1つずつ更新する。
ノードプール内のノードはバッチで更新されます。第1のバッチは、1つのノードを含む。ノードの数は、後続のバッチで2の累乗に基づいて増加します。一時停止した更新プロセスを再開した後も、バッチ更新ポリシーが適用されます。 [ノードプールのアップグレード] ページでバッチサイズを指定できます。バッチサイズを10に設定することを推奨します。詳細については、「ノードプールの更新」をご参照ください。

更新期間

ACK管理クラスターとACKサーバーレスクラスターの場合、制御プレーンの更新に約5分かかります。 ACK専用クラスターの場合、ACKはマスターノードを1つずつ更新する必要があります。マスターノードの更新には約8分かかります。ノードプール内のノードはバッチで更新されます。バッチを更新するには約5分かかります。

手順

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

制限事項

Kubernetes 1.18以降を実行するACKクラスターを更新する場合、制御プレーンのみを更新できます。

手順

ノードプールを更新する前に、まず制御プレーンを更新する必要があります。

ACKコンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、アップグレードするクラスターを見つけ、[操作] 列の [詳細] > [操作] > [クラスターのアップグレード] を選択します。
[クラスターのアップグレード] ページの [更新項目] セクションで、使用可能なKubernetesバージョンを選択し、[更新モード] パラメーターを [制御プレーンのみ] に設定し、事前チェック をクリックします。
事前チェックが完了したら、[詳細] をクリックしてレポートを表示します。
- レポートで結果が正常の場合、クラスターは事前チェックに合格し、クラスターを更新できます。
- レポートで結果が異常な場合、クラスターは期待どおりに実行でき、クラスターのステータスは変更されません。 [トラブルシューティング] タブをクリックし、ページに表示される提案に従って問題を修正します。詳細については、「クラスターチェック項目とクラスターの問題を修正する方法に関する提案」をご参照ください。
  説明
  クラスターがKubernetes 1.20以降を実行する場合、事前チェックはクラスターで廃止されたAPIが使用されているかどうかを確認します。事前チェックの結果は参照用であり、クラスタを更新できるかどうかは判断されません。詳細については、「クラスターの問題を修正する方法に関するクラスターチェック項目と提案」トピックの非推奨APIセクションを参照してください。
クラスターが事前チェックに合格したら、[更新の開始] をクリックします。
[クラスターのアップグレード] ページで更新の進行状況を確認できます。更新が完了したら、[クラスター] ページに移動し、管理するクラスターを見つけ、クラスターのKubernetesバージョンを確認して、制御プレーンコンポーネントが更新されていることを確認できます。

次のステップ: ノードプールの更新

コントロールプレーンが更新されると、更新されたKubernetesバージョンに基づいて新しいノードがクラスターに追加されます。最も早い機会にオフピーク時に既存のノードを更新し、更新が完了した後にkubeletバージョンを確認することを推奨します。詳細については、「ノードプールの更新」をご参照ください。

制御プレーンとすべてのノードプールの更新

ACKコンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、アップグレードするクラスターを見つけ、[操作] 列の [詳細] > [操作] > [クラスターのアップグレード] を選択します。
[クラスターのアップグレード] ページの [更新項目] セクションで、使用可能なKubernetesバージョンを選択し、[更新モード] パラメーターを [制御プレーンとすべてのノードプール] に設定します。 [バッチ更新ポリシー] セクションで、[バッチごとに修復するノードの最大数] パラメーターを設定し、事前チェック をクリックします。
事前チェックが完了したら、[詳細の表示] をクリックしてレポートを表示します。
- レポートで結果が正常の場合は、引き続きクラスターを更新できます。
- レポートで結果が異常の場合は、[トラブルシューティング] タブをクリックし、提案に従って問題を修正します。詳細については、「クラスターチェック項目とクラスターの問題を修正する方法に関する提案」をご参照ください。
クラスターが事前チェックに合格したら、[更新の開始] をクリックします。
更新中は、ノードを追加または削除しないでください。ノードを追加または削除するには、まず更新をキャンセルする必要があります。 [クラスターのアップグレード] ページの [イベントローテーション] セクションで更新の進行状況を確認し、ビジネス要件に基づいて次の操作を実行できます。
- 更新を一時停止して再開する: 一時停止 をクリックして更新を一時停止します。更新を再開するには、続行をクリックします。
  更新を一時停止すると、クラスターは中間状態のままになります。更新が一時停止され、最も早い機会に更新を完了するときは、クラスターで操作を実行しないでください。クラスターが7日間Paused状態のままになると、更新は終了します。 ACKは、更新に関連するイベントとログを自動的に削除します。
- 更新をキャンセル: キャンセル をクリックします。表示されたメッセージボックスで [OK] をクリックします。更新をキャンセルした後、ACKは現在のバッチ内のノードを更新し続け、更新をロールバックすることはできません。残りのバッチは更新されません。
  説明
  - 更新中にエラーが発生した場合、ACKは更新を一時停止します。失敗の原因は、ページの下部に表示されます。提案に従ってエラーをトラブルシューティングできます。
  - エラーが発生しない限り、更新中にkube-upgrade名前空間のリソースを変更しないでください。
更新が完了したら、[クラスター] ページに移動し、クラスターのKubernetesバージョンを確認して、コントロールプレーンコンポーネントが更新されていることを確認できます。クラスターの詳細ページに移動し、左側のナビゲーションウィンドウで [ノード] > [ノード] を選択して、Kubernetesバージョンのノードを表示することもできます。

よくある質問

ACK専用クラスターのマスターノードの更新がタイムアウトした場合はどうすればよいですか。

原因

承認webhookコンポーネントの自己署名サーバー証明書には、Subject Alternative Nameフィールドが含まれていません。その結果、マスターコンポーネントの起動に失敗します。

解決策

次のコマンドを実行して、承認Webhookの自己署名サーバー証明書に [Subject Alternative Name] フィールドが含まれているかどうかを確認します。 kubectlが設定されているノードで次のコマンドを実行する必要があります。

次のコマンドを実行して、クラスター内のアクセス許可webhookを照会します。

kubectl get mutatingwebhookconfigurations

期待される出力:

NAME                                      WEBHOOKS   AGE
ack-node-local-dns-admission-controller   1          27h

次のコマンドを実行して、承認webhook用に設定されたサービスを照会します。

kubectl get mutatingwebhookconfigurations ack-node-local-dns-admission-controller -oyaml | grep service -A 5
    service:
      name: ack-node-local-dns-admission-controller
      namespace: kube-system
      path: /inject
      port: 443
  failurePolicy: Ignore

次のコマンドを実行して、サービスのクラスターIPアドレスを照会します。

kubectl -n kube-system get service ack-node-local-dns-admission-controller