機械翻訳について

このドキュメントで説明されているソフトウェアは、サポートされなくなったか、拡張サポートされています。
Oracleでは、現在サポートされているリリースにアップグレードすることをお勧めします。

第1章 更新およびアップグレードの概要

このドキュメントでは、更新 Oracle Cloud Native EnvironmentおよびKubernetesを最新のエラータ・リリースに、またはアップグレードをリリース1.3からリリース1.4にする方法を示します。 この章では、アップグレードという用語は、全体的なプロセスが同じであるため、アップグレードと更新の両方を意味します。

アップグレードの最初のステップは、Oracle Cloud Native Environmentソフトウェア・パッケージをアップグレードすることです。 これには、ノードのプラットフォームAPIサーバーまたはプラットフォーム・エージェントの停止、Oracle Cloud Native EnvironmentパッケージのアップグレードおよびプラットフォームAPIサーバーまたはプラットフォーム・エージェントの再起動が含まれます。

次のステップでは、Kubernetesソフトウェア・パッケージをアップグレードします。 これは、適切なolcnectl module updateコマンドを発行するときに、Platform API Serverによって実行されます。

クラスタを停止せずに高可用性クラスタをアップグレードできます。 コントロール・プレーン・ノードは逐次的にアップグレードされるため、一方のコントロール・プレーン・ノードがオフラインになると、もう一方のコントロール・プレーン・ノードがクラスタを制御します。 コントロール・プレーン・ノードが1つのクラスタでは、アップグレードの実行中にコントロール・プレーン・ノードが短時間オフラインになります。

また、ワーカー・ノードも逐次的にアップグレードされます。 アプリケーションが複数のワーカー・ノードで実行されている場合、それらは稼働状態を維持してアップグレード中も使用可能になります。

ノート

特定のKubernetesルールでは、アップグレードのためにノードがオフラインにされないことがあります。 PodDisruptionBudgetはこれらのオブジェクトの1つです。 ノードをオフラインに設定できるようにするには、実行中のポッドの数をMinAvailable値を超えるまで増やします。 PodDisruptionBudgetsの詳細は、次の場所にあるアップストリームのドキュメントを参照してください。

https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#how-disruption-budgets-work

アップグレードの開始前に、障害発生時に必要となる可能性のあるリカバリを支援するためのバックアップがコントロール・プレーン・ノードから取得されます。

重要

モジュールの更新が失敗した場合、バックアップを使用してコントロール・プレーン・ノードをリカバリできます。 コントロール・プレーン・ノード・バックアップからのリストアの詳細は、コンテナ・オーケストレーションを参照してください。

Kubernetesのリリース(エラータまたは新しいリリース)は、各ノードでアップグレードされます。 まずコントロール・プレーン・ノードがアップグレードされ、次にワーカー・ノードがアップグレードされます。 ノードのアップグレード・プロセス中に、次のステップが実行されます。

  1. ポッドを除去するクラスタからノードが排出されます(kubectl drainコマンドを使用)。

  2. kubeadmパッケージがアップグレードされます。

  3. kubeadm upgradeコマンドを使用して、ノードがアップグレードされます。

  4. kubectlパッケージとkubeletパッケージがアップグレードされます。

  5. kubeletサービスが再開されます。

  6. ノードがクラスタに戻され(kubectl uncordonコマンドを使用)、ポッドを実行できるようになります。

Kubernetesを更新またはアップグレードするには、olcnectl module updateコマンドを使用して環境内のKubernetesモジュールを更新します。 次の章に示すolcnectl module updateコマンド・オプションは、Kubernetesのアップグレードに必要な最小限のコマンドです。 次の追加オプションを使用することもできます。

  • --generate-scriptsオプションを指定すると、モジュールの更新時に検証失敗が発生した場合に、各ノードに対して実行可能なスクリプトが生成されます。 スクリプトはモジュール内のノードごとに作成され、ローカル・ディレクトリにhostname:8090.shという名前で保存されます。

  • --forceオプションを指定すると、表示されているプロンプトが非表示になり、モジュールの更新が確認されます。

  • --container-registryオプションを使用すると、更新またはアップグレードの実行時に必ずデフォルトになる新しいコンテナ・レジストリを指定できます。 たとえば:

    --container-registry container-registry-austin-mirror.oracle.com/olcne/