ベアメタル版 Anthos クラスタをアップグレードする

新しいバージョンの bmctl をインストールすると、以前のバージョンで作成した既存のクラスタをアップグレードできます。Anthos clusters on bare metal の最新バージョンにクラスタをアップグレードすると、クラスタに追加機能と修正が適用されます。また、引き続きクラスタのサポートを保証します。管理者、ハイブリッド、スタンドアロン、ユーザー クラスタは、bmctl upgrade cluster コマンドを使用してアップグレードできます。

アップグレードに関する考慮事項

以下のセクションでは、クラスタをアップグレードする前に考慮すべきルールとベスト プラクティスの概要を説明します。

プレビューの機能

プレビュー機能は変更される場合があり、テストと評価のみを目的として提供されています。本番環境のクラスタでプレビュー機能を使用しないでください。プレビュー機能を使用するクラスタを必ずアップグレードできるというわけではありません。場合によっては、プレビュー機能を使用するクラスタのアップグレードを明示的にブロックすることがあります。

アップグレードに関連する重要な変更点については、リリースノートをご覧ください。

SELinux

コンテナを保護するために SELinux を有効にする場合は、すべてのホストマシンで SELinux を Enforced モードで有効にする必要があります。リリース 1.9.0 以降のベアメタル版 Anthos クラスタでは、クラスタの作成前かアップグレード後に SELinux を有効または無効にできます。Red Hat Enterprise Linux（RHEL）と CentOS では、SELinux がデフォルトで有効になっています。ホストマシンで SELinux が無効になっている場合や、不明な場合は、SELinux を使用したコンテナの保護をご覧ください。

ベアメタル版 Anthos クラスタは、RHEL システムと CentOS システムの SELinux のみをサポートしています。

アップグレードのバージョン ルール

新しいバージョンの bmctl をダウンロードしてインストールすると、bmctl の以前のバージョンで作成またはアップグレードされた管理者、ハイブリッド、スタンドアロン、ユーザー クラスタをアップグレードできます。クラスタを下位バージョンにダウングレードすることはできません。

クラスタは、使用している bmctl のバージョンと一致するバージョンにのみアップグレードできます。つまり、bmctl のバージョン 1.10.8 を使用している場合は、クラスタをバージョン 1.10.8 にのみアップグレードできます。

パッチ バージョンのアップグレード

任意のマイナー バージョンについて、より上位のパッチ バージョンにアップグレードできます。つまり、Y が X より大きい限り、1.10.X バージョン クラスタをバージョン 1.10.Y にアップグレードできます。たとえば、1.9.0 から 1.9.1 にアップグレードしたり、1.9.1 から 1.9.3 にアップグレードしたりできます。クラスタに最新のセキュリティ修正が適用されているように、可能な限り最新のパッチ バージョンにアップグレードすることをおすすめします。

マイナー バージョンのアップグレード

パッチ バージョンに関係なく、クラスタをマイナー バージョン間でアップグレードできます。つまり、1.N.X がお使いのクラスタのバージョンで、N+1 が次に使用可能なマイナー バージョンであれば、1.N.X から 1.N+1.Y にアップグレードできます。この場合、パッチ バージョン X と Y はアップグレード ロジックに影響しません。たとえば、1.9.3 から 1.10.8 にアップグレードできます。

クラスタのアップグレードでは、マイナー バージョンをスキップすることはできません。クラスタのバージョンから 2 つ以上離れたマイナー バージョンにアップグレードしようとすると、bmctl がエラーを出力します。たとえば、バージョン 1.8.0 のクラスタをバージョン 1.10.0 にアップグレードすることはできません。

管理クラスタは、同じマイナー バージョンまたは以前のマイナー バージョンのユーザー クラスタを管理できます。マネージド ユーザー クラスタは、管理クラスタより 1 つ前のマイナー バージョン以降でなければなりません。そのため、管理クラスタを新しいマイナー バージョンにアップグレードする前に、すべてのマネージド ユーザー クラスタが管理クラスタと同じマイナー バージョンであることを確認してください。

次のアップグレード手順の例では、バージョン 1.9.2 からベアメタル版 1.10.8 の Anthos クラスタへのアップグレード プロセスを示しています。

Pod の密度

ベアメタル版 Anthos クラスタは、nodeConfig.PodDensity.MaxPodsPerNode を持つノードあたり最大 250 個のポッドの構成をサポートしています。Pod 密度はクラスタの作成時にのみ構成できます。既存のクラスタのポッド密度設定を更新することはできません。

既知の問題

クラスタのアップグレードに関連する潜在的な問題については、既知の問題ページのベアメタル版 Anthos クラスタのアップグレードをご覧ください。

管理クラスタ、スタンドアロン クラスタ、ハイブリッド クラスタ、ユーザー クラスタをアップグレードする

新しいバージョンの bmctl をダウンロードしてインストールすると、以前のバージョンで作成した管理クラスタ、ハイブリッド クラスタ、スタンドアロン クラスタ、ユーザー クラスタをアップグレードできます。特定のバージョンの bmctl については、クラスタを同じバージョンにのみアップグレードできます。

まず、最新の bmctl をダウンロードしてから、適切なクラスタ構成ファイルを変更し、bmctl upgrade cluster コマンドを発行してアップグレードを完了します。

  1. 最新の bmctl を Cloud Storage バケットからダウンロードし、chmod を使用してすべてのユーザーに bmctl の実行権限を付与します。

    gsutil cp gs://anthos-baremetal-release/bmctl/1.10.8/linux-amd64/bmctl bmctl
chmod a+x bmctl

  2. クラスタの構成ファイルを修正して、ベアメタル版 Anthos クラスタのクラスタ バージョンを 1.9.2 から 1.10.8 に変更します。以下に、管理クラスタの構成ファイルの例を示します。

    ---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  # Cluster type. This can be:
  #   1) admin:  to create an admin cluster. This can later be used to create user clusters.
  #   2) user:   to create a user cluster. Requires an existing admin cluster.
  #   3) hybrid: to create a hybrid cluster that runs admin cluster components and user workloads.
  #   4) standalone: to create a cluster that manages itself, runs user workloads, but does not manage other clusters.
  type: admin
  # Anthos cluster version.
  # Change the following line from 1.9.2 to 1.10.8, shown below
  anthosBareMetalVersion: 1.10.8

  3. クラスタを 1.10.8 にアップグレードするときに、クラスタがまだ登録されていない場合は、Connect を使用してプロジェクトフリートに登録する必要があります。

    1. サービス アカウントを手動で作成して JSON キーファイルを取得する方法については、Google サービスとサービス アカウントの有効化に関するページの Connect に使用するサービス アカウントを構成するをご覧ください。
    2. ダウンロードした JSON キーを、クラスタ構成ファイルの gkeConnectAgentServiceAccountKeyPath および gkeConnectRegisterServiceAccountKeyPath フィールドで参照します。

  4. bmctl upgrade cluster コマンドを使用してアップグレードを完了します。

    bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    以下を置き換えます。

    • CLUSTER_NAME: アップグレードするクラスタの名前。
    • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

    プリフライト チェックは、クラスタのアップグレードの一環として実行され、クラスタのステータスとノードの健全性を検証します。プリフライト チェックに失敗した場合、クラスタのアップグレードは続行されません。