古いクラスターバージョンには、セキュリティと安定性の問題があります。 Container Service for Kubernetes (ACK) は、ビジネスの継続性を確保するために、インプレース更新を使用してACK Lingjunクラスターを更新します。 ACKコンソールでクラスターのKubernetesバージョンを更新したり、クラスターのコントロールプレーンとノードプールを個別に更新したりできます。 このトピックでは、更新前と更新後の使用上の注意事項と、ACK Lingjunクラスターを更新する手順について説明します。
ACK Lingjunクラスターに更新が必要な理由
ACK LingjunクラスターのKubernetesバージョンを1.20から1.22に更新できます。
プロアクティブな更新には、次の利点があります。
セキュリティと安定性のリスクの軽減: Kubernetesの新しいバージョンは通常リリースされ、最適化とパッチのセキュリティと安定性の脆弱性が追加されます。 古いKubernetesクラスターを使用すると、ビジネスにセキュリティと安定性のリスクが生じる可能性があります。
新機能: オープンソースKubernetesのイテレーションには、通常、新機能と改良が加えられています。 ACKはこれらの機能もサポートし、開発とメンテナンスのエクスペリエンスを最適化します。
クラスターをプロアクティブに更新するには、次の手順を実行することを推奨します。
クラスターを更新すると、ACKはクラスターで事前チェックを実行しますが、ACKは互換性のないすべての機能、設定、およびAPIを識別できることを保証するものではありません。 共有責任モデルによると、クラスターを更新する前に、ドキュメント、コンソールの情報、内部メッセージを確認してKubernetesバージョンのリリースに注意を払い、対応するバージョンの更新ノートを確認することをお勧めします。
ACK LingjunクラスターがKubernetesバージョンをサポートする方法の詳細については、「Kubernetesバージョンのサポート」をご参照ください。
使用法ノート (重要)
Kubernetesのバージョン
ACK LingjunクラスターのKubernetesバージョンを表示するには、ACKコンソールにログインし、[クラスター] ページでクラスターの [バージョン] 列を確認します。 Kubernetesバージョンにアップデートする前に、対応するKubernetesバージョンの次のリリースノートを読んで、バージョンの詳細、非推奨のAPI、アップデートの使用状況を確認してください。 これにより、新しいバージョンのKubernetesで機能の更新によって引き起こされる互換性の問題を回避できます。
HelmグラフのYAMLファイルが非推奨のリソースを使用している場合は、できるだけ早くファイルを変更してください。 詳細については、前述のリリースノートおよび非推奨APIをご参照ください。
機能とカスタム設定
ACK Lingjunクラスターが次の表に示す機能を使用している場合は、考慮事項と推奨される解決策をお読みください。
特徴 | 考慮事項 | 推奨ソリューション |
FlexVolume | FlexVolume 1.11.2.5以前を使用してマウントされたObject Storage Service (OSS) ボリュームは、クラスターの更新中に再マウントされます。 | 更新が完了したら、OSSボリュームを使用するポッドを再作成する必要があります。 FlexVolumeは非推奨です。 FlexVolumeからCSIにアップグレードすることを推奨します。 詳細については、「 FlexVolumeからCSIへのアップグレード」をご参照ください。
|
自動スケーリング | 自動スケーリングが有効になっている場合、クラスターが更新された後、クラスターはクラスターオートスケーラーを最新バージョンに自動的に更新します。 これにより、自動スケーリング機能が期待どおりに機能します。 | Cluster Autoscalerが最新バージョンに更新されていることを確認します。 詳細については、「ノードの自動スケーリング」をご参照ください。 |
リソース予約 | ACK LingjunクラスターのKubernetesバージョンを1.18に更新すると、ACKはリソース予約を自動的に設定します。 リソース予約がクラスターに設定されておらず、ノードのリソース使用率が高い場合、ACKは、クラスターの更新後にノードに追い出されたポッドをスケジュールできない可能性があります。 | ノードに十分なリソースを確保します。 CPUリソースの少なくとも50% とメモリリソースの少なくとも70% を予約することを推奨します。 詳細については、「リソース予約ポリシー」をご参照ください。 |
LoadBalancer設定 | ACK Lingjunクラスターは、外部アクセスを処理するためにServer Load Balancer (SLB) インスタンスを必要とします。 ただし、SLBインスタンスに | SLBインスタンスがトラフィックをアプリケーションポッドに転送できない場合に備えて、externalTrafficPolicy: LocalがSLBインスタンスに指定されているかどうかを確認します。 詳細については、「 LoadBalancerサービスによって公開されているSLBインスタンスのIPアドレスにクラスターがアクセスできない場合の対処方法をご参照ください。
|
APIサーバー | ACKがクラスタを更新すると、ACKはクラスタ内のアプリケーションとの通信を中断することなく制御プレーンを更新しようと試みる。 ただし、APIサーバとの通信が一時的に中断される場合があります。 割り込みは、APIサーバーに強く依存するアプリケーションに影響します。 たとえば、アプリケーションがリソースを一覧表示して監視する必要がある場合、APIサーバーの再起動時に監視操作が中断されます。 この問題を解決するには、中断が発生したときに監視操作を自動的に再試行するようにアプリケーションを設定する必要があります。 | アプリケーションがAPIサーバーにアクセスする必要がない場合、アプリケーションは更新の影響を受けません。 それ以外の場合は、アプリケーションが失敗時に再試行できることを確認します。 |
kubectl | クラスターが更新された後、オンプレミスマシンでkubectlを更新することを推奨します。 kubectlを更新しない場合、kubectlのバージョンがAPIサーバーのバージョンと互換性がない可能性があります。 その結果、 | kubectlをインストールまたは更新します。 詳細については、「kubectlのインストール」をご参照ください。 |
クラスターでカスタム設定を使用する場合は、次の表の説明をお読みください。
項目 | 説明 |
ネットワーク | クラスターを更新するには、Yumを使用して必要なソフトウェアパッケージをダウンロードする必要があります。 クラスターがカスタムネットワーク設定またはカスタムOSイメージを使用している場合は、Yumが通常どおり実行できるようにする必要があります。 |
OSイメージ | カスタムOSイメージは、ACKによって厳密に検証されません。 クラスターがカスタムOSイメージを使用している場合、ACKはクラスター更新の成功を保証しません。 |
その他 | CLIを使用して変更されたスワップパーティションやkubelet設定など、クラスターが他のカスタム設定を使用している場合、クラスターの更新に失敗したり、更新中にカスタム設定が失われたりする可能性があります。 |
説明
ACKクラスターを更新するときは、クラスターの制御プレーンとノードプールを更新する必要があります。 更新手順を次の図に示します。
準備
クラスターを更新するKubernetesバージョンのリリースノートを参照して、更新ノートについて確認してください。 これにより、機能の更新による互換性の問題を回避できます。 オフピーク時に更新を実行することを推奨します。
クラスターの更新
クラスターのコントロールプレーンとノードプールを更新する前に、クラスターが事前チェックに合格する必要があります。 事前チェックの結果で問題が報告された場合は、問題を修正して事前チェックを再度実行する必要があります。
制御プレーンを更新するUpdate the control plane
ACKマネージドクラスターおよびACKサーバーレスクラスター
ローリング更新が使用される。 kube-apiserver、kube-controller-manager、kube-schedulerなどの制御プレーンコンポーネントを更新します。
ACK専用クラスター
インプレース更新は、ビジネスの継続性を確保し、データ移行と構成変更によってもたらされる潜在的なリスクを軽減するために実行されます。 手順：
ACKがクラスター内のetcdとコンテナランタイムを更新する必要があることを識別すると、ACKは各マスターノードのetcdとコンテナランタイムを順番に更新します。
ACKは一度に1つのマスターノードのみを更新し、マスターノードのIDを表示します。
kube-apiserver、kube-controller-manager、kube-schedulerなどのマスターノードのコンポーネントを更新します。
マスターノードのkubeletを更新します。
ノードプールの更新
ノードプールを更新するときは、kubeletとコンテナランタイムを更新する必要があります。 コンテナランタイムをDockerからcontainerdに変更するには、更新中にACKがノードのシステムディスクを置き換えます。 このようにして、オペレーティングシステムとアプリケーションも更新されます。 クラスターを更新する前に、ノードのシステムディスク上のデータをバックアップすることを推奨します。 他のシナリオでは、ACKはインプレース更新を使用してノードプールを更新する。 詳細については、「ノードプールの更新」をご参照ください。
ACKは、クラスタ内のノードをバッチで更新します。
複数のノードプールが1つずつ更新されます。
ノードプール内のノードはバッチで更新されます。 第1のバッチは、1つのノードを含む。 ノードの数は、後続のバッチで2のべき乗で増加します。 一時停止した更新を再開した後も、バッチ更新ポリシーが適用されます。 [ノードプールのアップグレード] ページで最大バッチサイズを指定できます。 最大バッチサイズを10に設定することを推奨します。 詳細については、「ノードプールの更新」をご参照ください。
アップデートの確認
クラスターのKubernetesバージョンが更新されているかどうか、ノードプールが期待どおりに実行されるかどうか、およびクラスター内のビジネスが期待どおりに実行されるかどうかを確認します。
手順
制御プレーンの更新Update the control plane
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、 を選択します。
[クラスターのアップグレード] ページで、[宛先バージョン] を設定し、事前チェック をクリックして、アップデートの潜在的なリスクを検出します。
事前チェックが完了すると、[事前チェックの結果] セクションで事前チェックの結果を表示できます。
問題が表示されない場合は、クラスターが事前チェックに合格したことを示します。 アップデートを開始できます。
問題が表示されても、クラスターは期待どおりに実行でき、クラスターのステータスは変更されません。 コンソールによって提供される提案に基づいて問題を修正できます。 詳細については、「クラスターチェック項目とクラスターの問題を修正する方法に関する提案」をご参照ください。
説明クラスターがKubernetes 1.20以降を実行する場合、事前チェックは、クラスターで非推奨のAPIが使用されているかどうかを確認します。 事前チェックの結果は参照用であり、クラスターが更新可能かどうかは判断されません。 詳細については、「非推奨API」をご参照ください。
クラスターが事前チェックに合格したら、[更新の開始] をクリックし、画面の指示に従って制御プレーンを更新します。
更新履歴は、[クラスターのアップグレード] ページの右上隅に表示されます。
更新が完了したら、[クラスター] ページに移動し、クラスターのKubernetesバージョンを確認して、コントロールプレーンが更新されているかどうかを確認できます。 コントロールプレーンの更新後に新しいノードを追加すると、新しいノードは新しいKubernetesバージョンを使用します。
次のステップ: ノードプールの更新
コントロールプレーンが更新されると、更新されたKubernetesバージョンに基づいてクラスターに新しいノードが追加されます。 最も早い機会にオフピーク時に既存のノードを更新し、更新が完了した後にkubeletバージョンを確認することを推奨します。 詳細については、「ノードプールの更新」および「Lingjunノードプールの更新」をご参照ください。
クラスターの更新に関するFAQ about cluster updates
クラスターの更新が失敗し、インスタンスでaliyunサービスが実行されていないというエラーが返された場合はどうすればよいですか。
PLEG not healthyエラーを処理するにはどうすればよいですか?
制御プレーンとノードプールの更新手順
制御プレーンの更新Update the control plane
ACKは、次の手順に基づいて、ACK Lingjunクラスターの制御プレーンを更新します。 更新ポリシーでは、次のルールを指定します。
制御プレーンと、kube-apiserver、kube-controller-manager、kube-schedulerなどのマネージコンポーネントを更新します。
kube-proxyなどのKubernetesコンポーネントを更新します。
ノードプールの更新
ACKは、クラスタ内のノードをバッチで更新します。 バッチ更新ポリシーでは、次のルールを指定します。
ACKは、ノードプールを1つずつ更新する。
ノードプール内のノードはバッチで更新されます。 第1のバッチは、1つのノードを含む。 ノードの数は、後続のバッチで2の累乗に基づいて増加します。 一時停止した更新を再開した後も、バッチ更新ポリシーが適用されます。 [ノードプールのアップグレード] ページで最大バッチサイズを指定できます。 最大バッチサイズを10に設定することを推奨します。 詳細については、「ノードプールの更新」および「Lingjunノードプールの更新」をご参照ください。
関連ドキュメント
ACK Lingjunクラスターの更新時にエラーが発生した場合は、クラスターチェック項目とクラスターの問題の修正方法に関する提案を参照して、エラーのトラブルシューティングを行います。