クラスタをアップグレードする

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

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

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

プレビューの機能

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

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

SELinux

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

GKE on Bare Metal は、RHEL システムと CentOS システムの SELinux のみをサポートしています。

プリフライト チェックをアップグレードする

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

アップグレードを実行する前に、プリフライト チェックを実行することで、クラスタのアップグレードの準備ができているかどうかを確認できます。詳しくは、アップグレードのプリフライト チェックをご覧ください。

ノード数

クラスタに 51 を超えるノードがある場合、ブートストラップ クラスタを使用する標準アップグレード オペレーションは障害の影響を受けます。失敗の原因は、ブートストラップ クラスタに割り当てられた Pod IP アドレスの量が限られていることです。ブートストラップ クラスタ内の Pod で使用できるデフォルトの IP アドレス範囲は、CIDR ブロック表記の /24 のマスクを使用します。

この状況を回避するには、次の 2 つの方法があります。

  1. （推奨）bmctl upgrade cluster コマンドで --use-bootstrap=false フラグを使用してインプレース アップグレードを実行します。このフラグにより、アップグレードはブートストラップ クラスタと関連する Pod アドレスの制限を完全にバイパスします。バージョン 1.13.0 クラスタのインプレース アップグレードに関する既知の問題をご覧ください。クラスタがバージョン 1.13.0 の場合は、既知の問題を参照して回避策と追加情報をご覧ください。

  2. --bootstrap-cluster-pod-cidr フラグを指定して bmctl upgrade cluster コマンドを使用すると、ブートストラップ クラスタに割り当てられる Pod IP アドレスの量が増えます。たとえば、アップグレード オペレーションのために実行される --bootstrap-cluster-pod-cidr=192.168.122.0/23 Pod が、デフォルトの CIDR 192.168.122.0/24（256 アドレス）の代わりに 192.168.122.0/23（512 アドレス）の IP アドレスを使用できるように指定する場合です。これらの追加アドレスにより、52 ノードまでのクラスタのアップグレードのブロックが解除されます。

    アップグレード中に同時に実行される Pod の数は、ノードの数の 5 倍までにできます。アップグレードを確実に成功させるには、ノード数の 5 倍の IP アドレス数を含む CIDR ブロックを指定します。このフラグには内部 IP アドレスが必要です。

  3. 上のいずれのオプションも使用しない場合は、--skip-bootstrap-cidr-check フラグを使用して検証をバイパスできます。ただし、この引数を渡すと、ブートストラップ クラスタの Pod CIDR に使用可能な IP アドレスが不十分なため、アップグレードが失敗する可能性があります。

セルフマネージド クラスタのインプレース アップグレード

ベアメタル リリース 1.13.1 の Anthos クラスタから、管理クラスタ、ハイブリッド クラスタ、スタンドアロン クラスタでインプレース アップグレードを実行できます。インプレース アップグレードにより、ブートストラップ クラスタが不要になり、プロセスが簡素化され、アップグレードのリソース要件が削減されます。セルフマネージド クラスタでインプレース アップグレードを行うには、バージョンが 1.13.0 以降である必要があります。

インプレース アップグレードを実行するには、bmctl または kubectl を使用します。

bmctl

アップグレード プロセスは、bmctl upgrade cluster コマンドを除いて標準のアップグレード プロセスと同じです。

  • インプレース アップグレードを開始するには、upgrade コマンドで --use-bootstrap=false フラグを使用します。

    bmctl upgrade cluster -c CLUSTER_NAME --use-bootstrap=false \
    --kubeconfig ADMIN_KUBECONFIG

    以下を置き換えます。

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

標準のアップグレード プロセスと同様に、クラスタのアップグレードの一環としてプリフライト チェックが実行され、クラスタのステータスとノードの健全性が検証されます。プリフライト チェックが不合格の場合、クラスタのアップグレードは停止します。ブートストラップ クラスタが作成されないため、障害をトラブルシューティングするには、クラスタと関連ログを調べます。

kubectl

kubectl を使用してセルフマネージド クラスタをアップグレードするには、次の手順を行います。

  1. クラスタ構成ファイルを編集して、anthosBareMetalVersion をアップグレード先のターゲット バージョンに設定します。

  2. アップグレードを開始するには、次のコマンドを実行します。

    kubectl apply -f CLUSTER_CONFIG_PATH

    CLUSTER_CONFIG_PATH は、クラスタの構成ファイルへのパスに置き換えます。

標準のアップグレード プロセスと同様に、クラスタのアップグレードの一環としてプリフライト チェックが実行され、クラスタのステータスとノードの健全性が検証されます。プリフライト チェックが不合格の場合、クラスタのアップグレードは停止します。ブートストラップ クラスタが作成されないため、障害をトラブルシューティングするには、クラスタと関連ログを調べます。

Pod の密度

ベアメタル版 GKE は、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.14.11/linux-amd64/bmctl bmctl
chmod a+x bmctl

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

    ---
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.13.2 to 1.14.11, shown below
  anthosBareMetalVersion: 1.14.11

  3. クラスタを 1.14.11 にアップグレードするときに、クラスタがまだ登録されていない場合は、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 ファイルのパス。

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

ノードの並列アップグレード

一般的なクラスタ アップグレードでは、各クラスタノードが順次アップグレードされます。このセクションでは、クラスタをアップグレードするときに複数のノードが並行してアップグレードされるようにクラスタを構成する方法について説明します。

ノードを並行してアップグレードすると、特に数百のノードを持つクラスタの場合に、クラスタのアップグレードが速くなります。ノードの並列アップグレードはノードプールに基づいて構成され、ワーカー ノードプール内のノードのみを並列アップグレードできます。コントロール プレーンまたはロードバランサのノードプール内のノードは、一度に 1 つだけアップグレードできます。

ワーカーノードの並列アップグレードはプレビュー機能であるため、本番環境クラスタでは使用しないでください。

並列アップグレードの実行方法

ワーカー ノードプール内のノードの並列アップグレードを実行するには、次の手順に従います。

  1. アノテーション preview.baremetal.cluster.gke.io/parallel-upgrade: "enable" をクラスタ構成ファイルに追加します。

    ---
gcrKeyPath: /path/to/gcr-sa
gkeConnectAgentServiceAccountKeyPath: /path/to/gke-connect
gkeConnectRegisterServiceAccountKeyPath: /path/to/gke-register
sshPrivateKeyPath: /path/to/private-ssh-key
cloudOperationsServiceAccountKeyPath: /path/to/logging-sa
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-cluster1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    baremetal.cluster.gke.io/maintenance-mode-deadline-seconds: "180"
    preview.baremetal.cluster.gke.io/parallel-upgrade: "enable"
    ...

  2. upgradeStrategy セクションをワーカー ノードプールのマニフェストに追加します。このマニフェストはクラスタ構成ファイルに含まれている必要があります。別のマニフェスト ファイルに表示される場合、bmctl upgrade cluster コマンドは機能しません。次に例を示します。

    ---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-ci-bf8b9aa43c16c47
spec:
  clusterName: ci-bf8b9aa43c16c47
  nodes:
  - address:  10.200.0.7
  - address:  10.200.0.8
  - address:  10.200.0.9
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5

    この例では、フィールド concurrentNodes の値は 5 です。つまり、5 つのノードが並列でアップグレードされます。このフィールドの最小値（デフォルト値）は 1 で、最大許容値はワーカー ノードプール内のノード数です。ただし、この値はクラスタ内の総ノード数の 3% 未満に設定することをおすすめします。concurrentNodes の値が大きすぎると、並行アップグレード中にワークロードが損なわれる可能性があります。

  3. 前の管理クラスタ、スタンドアロン クラスタ、ハイブリッド クラスタ、ユーザー クラスタをアップグレードするのセクションの説明に沿ってクラスタをアップグレードします。

ノードの並列アップグレードを無効にする方法

ノードの並列アップグレードを無効にするには、クラスタ構成ファイルでアノテーション preview.baremetal.cluster.gke.io/parallel-upgrade を disable に設定します。