Kubernetesクラスタへのパッチ適用
注意:
システム・パッチ適用の準備ステップがすべて完了していることを確認します。 手順は、「アプライアンスのパッチ適用の準備」を参照してください。
Kubernetesコンテナ・オーケストレーション環境パッチ適用も、オペレーティング・システムとは別に保持されます。 1つのコマンドを使用すると、すべてのKubernetesパッケージ(kubeadm、kubectl、kubeletなど)に3つの管理ノードとすべてのコンピュート・ノードでパッチが適用されます。 このパッチ適用には、Kubernetesコンテナで実行されているマイクロサービスは含まれません。
ノート:
ソフトウェア・バージョン3.0.2-b892153以降では、すべてのパッチ操作はアップグレード計画に基づいており、アップグレード前コマンドの実行時に生成されます。 詳細は、「パッチ適用のための新しいソフトウェア・ソースの設定」を参照してください。 コンポーネントがすでに必須バージョンである場合、パッチ操作はスキップされます。 ただし、必要に応じて、「サービスWeb UI」または「サービスCLI」コマンド・オプション(force=True
)を使用して、同じバージョンでのパッチ適用を強制できます。
syncUpstreamUlnMirror
コマンドを発行して、Kubernetesパッチ適用の前に共有ストレージでのミラーの同期が完了していることを確認します。 詳細は、「ULNミラーとの更新および同期」を参照してください。
Kubernetesアップグレード・プロセスについて
サービスの互換性と継続性を確保するには、Kubernetesを一度に1つのバージョンにアップグレードする必要があります。 バージョンのスキップ - メジャーまたはマイナー - は、サポートされていません。 Private Cloud Appliance Upgraderは、Kubernetesクラスタのすべての部分を次の使用可能なバージョンにアップグレードまたはパッチ適用することでこのプロセスを管理し、環境全体でアプライアンス・ソフトウェア・リポジトリから入手可能な最新のKubernetesバージョンが実行されるまで、同じ一連の操作を繰り返します。
Kubernetesクラスタのアップグレードまたはパッチ適用は、Private Cloud Appliance管理ノードおよびコンピュート・ノードを含む時間のかかるプロセスです。 追加の各コンピュート・ノードは、Kubernetesの増分バージョンごとに10分ずつプロセスを拡張します。
アプライアンス・ソフトウェア・バージョン3.0.2-b925538以降では、コンテナ・オーケストレーション環境がKubernetesバージョン1.20.xからバージョン1.25.yにアップグレードまたはパッチ適用されます。つまり、プロセス全体が5回実行される必要があります。 実行が成功するたびに、リポジトリが同期され、次の必要なバージョンが取得されます。 ただし、このバージョンのアプライアンス・ソフトウェアでは、リポジトリは複数のバージョンのKubernetesパッケージを許可するように再構成されるため、再同期は不要になります。
個々のKubernetesノードのアップグレードには、約10分かかります。 テストでは、Private Cloud Appliance Kubernetesクラスタのバージョン1.20からバージョン1.25へのアップグレードまたはパッチ適用に、管理ノードが3つ、コンピュート・ノードが3つあるベース・ラック構成で約4-5時間かかることが示されています。 20個のコンピュート・ノードがあるフル・ラックでは、プロセス全体で少なくとも9時間必要であり、完了までに最大18時間かかる場合があります。 ラック固有の構成の推定時間は、アップグレード計画で報告されます。
アップグレードまたはパッチ適用の進行状況を監視するには、ジョブ・ステータスまたはログを定期的に確認します。
-
サービスCLIを使用してジョブ・ステータスを確認:
getUpgradeJob upgradeJobId=<id>
-
管理ノードのUpgraderログの表示:
tail -f /nfs/shared_storage/pca_upgrader/log/pca-upgrader_kubernetes_cluster_<time_stamp>.log
。
Kubernetesのアップグレードまたはパッチ適用中に、特定のサービスが一時的に使用できなくなる可能性があります。
-
「コンピュートWeb UI」、「サービスWeb UI」、OCI CLIおよび「サービスCLI」はすべて一時的に使用できなくなる可能性があります。 ユーザーは、操作を再試行する前に数分待つ必要があります。 「サービス・エンクレーブ」 (UIまたはCLI)での管理操作は、アップグレードまたはパッチ適用中に回避する必要があります。
-
Kubernetesアップグレードが開始されると、「Kubernetesワークロード・モニタリング・オペレータ」 (Sauronサービス)が停止されます。 その結果、Grafana、Prometheusおよびその他のSauronイングレス・エンドポイントにアクセスできません。 これらは、Kubernetesクラスタとコンテナ化されたマイクロサービス(プラットフォーム・レイヤー)のアップグレード・プロセスまたはパッチ適用プロセスの両方が完了した後、再び使用可能になります。
「サービスWeb UI」を使用したKubernetesクラスタへのパッチ適用
-
ナビゲーション・メニューで、「メンテナンス」セクションに移動し、「アップグレード計画」をクリックします。 ここでは、現行およびターゲット・コンポーネントのバージョンの概要を示します。
-
「アップグレード&パッチ適用」をクリックして、「アップグレード・ジョブ」ページを表示します。
-
「アップグレード・ジョブ」ページの右上隅にある「アップグレードまたはパッチの作成」をクリックします。
「要求の作成」ウィンドウが表示されます。 リクエスト・タイプとして「パッチ」を選択します。
-
適切なパッチ・リクエスト・タイプの選択: Kubernetesにパッチを適用します。
-
必要に応じて、パッチ・パラメータを入力します:
-
拡張オプションJSON: 利用できません。
-
ログ・レベル: オプションで、アップグレード・ログファイルの特定のログ・レベルを選択します。 デフォルトのログ・レベルは「情報」です。 詳細は、「デバッグ」を選択します。
-
代替ULNチャネル: このパラメータは、リクエストに非標準ULNチャネルを強制的に使用します。 Oracleが明示的に指示しないかぎり、このオプションを使用しないでください。
-
検証のみ: 検証専用モードで操作を実行するには、このオプションを有効にします。
-
強制: 操作を強制するには、このオプションを有効にします。 Oracleによって指示された場合のみ使用します。
-
-
「要求の作成」をクリックします。
新しいパッチ・リクエストが「アップグレード・ジョブ」表に表示されます。
「サービスCLI」を使用したKubernetesクラスタへのパッチ適用
-
patchコマンドを入力します。
PCA-ADMIN> patchKubernetes Command: patchKubernetes Status: Success Time: 2022-01-18 20:02:05,408 UTC Data: Service request has been submitted. Upgrade Job ID = 1642509549088-kubernetes-51898 \ Upgrade Request ID = UWS-4f0d9e99-a515-4170-ab35-9f8bdcbdb2b5
-
リクエストIDとジョブIDを使用して、アップグレード・プロセスのステータスを確認します。
PCA-ADMIN> getupgradejobs Command: getupgradejobs Status: Success Time: 2023-01-22 19:52:16,398 UTC Data: id upgradeRequestId commandName result -- ---------------- ----------- ------ 1642509549088-kubernetes-51898 UWS-4f0d9e99-a515-4170-ab35-9f8bdcbdb2b5 kubernetes Passed 1642492793827-oci-12162 UWS-6e06bbb7-16b8-49ba-9c33-f42fffbe1323 oci Passed PCA-ADMIN> getUpgradeJob upgradeJobId=1642509549088-kubernetes-51898 Command: getUpgradeJob upgradeJobId=1642509549088-kubernetes-51898 Status: Success Time: 2023-01-22 20:11:43,804 UTC Data: Upgrade Request Id = UWS-4f0d9e99-a515-4170-ab35-9f8bdcbdb2b5 Name = kubernetes [...]