プリフライト チェック

プリフライト チェックは、クラスタの作成やアップグレードなどの大規模なクラスタ オペレーションを開始する前に問題を特定するのに役立つ予防策です。これらのチェックがオペレーションの前に自動的に実行される場合、すべてのプリフライト チェックに合格しない限り、クラスタは変更されません。オンデマンドでプリフライト チェックを実行することもできます。

このドキュメントでは、各チェック、どのような状況で自動的に実行されるか、手動で実行する方法とタイミング、結果の解釈方法について説明します。

GDCV for Bare Metal では、さまざまな状況でプリフライト チェックを実行できます。

  • GDCV for Bare Metal は、bmctl を使用してクラスタとノードプール リソースを作成またはアップグレードするときに、プリフライト チェックを実行します。チェックで不合格になると、変更は一切行われません。これらのチェックをバイパスすることも、明示的に実行することもできます。

  • GDCV for Bare Metal は、管理クラスタやハイブリッド クラスタがユーザー クラスタで Kubernetes リソースを作成または更新するときに、内部プリフライト チェックも実行します。このチェックは、影響を受けるユーザー クラスタに変更が適用される前に実行されます。チェックで不合格になると、変更は一切行われません。

PreflightCheck カスタム リソース

プリフライト チェックが実行されると、GDCV for Bare Metal は PreflightCheck カスタム リソースを作成します。PreflightCheck カスタム リソースは永続的で、プリフライト チェックのアクティビティと結果の記録を提供します。

PreflightCheck カスタム リソースを取得するには、以下を実行します。

  1. 特定のクラスタに対して実行されたプリフライト チェックのリストを取得します。

    kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
    

    次のように置き換えます。

    • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。
    • CLUSTER_NAMESPACE: クラスタの名前空間。

    レスポンスには、名前空間別にリソースが一覧表示されます。すべての名前空間で kubectl get preflightchecks を実行すると、包括的なリストを作成できます。リソースごとに、レスポンスにはリソースの経過時間とプリフライト チェックに合格したかどうかが示されます。次のサンプル レスポンスは、cluster-test-admin001 名前空間の PreflightCheck リソースを示しています。

    NAMESPACE              NAME                                PASS    AGE
    cluster-test-admin001   test-admin001                      true    52d
    cluster-test-admin001   test-admin001jkm4q                 true    52d
    cluster-test-admin001   test-admin001k79t7                 true    6d20h
    cluster-test-admin001   upgrade-cluster-20231106-222746    true    6d20h
    
  2. 特定の PreflightCheck カスタム リソースの詳細を取得します。

    kubectl describe preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
    

    次のように置き換えます。

    • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。
    • CLUSTER_NAMESPACE: クラスタの名前空間。

    次のサンプル コマンド レスポンスは、クラスタ作成の一環として実行されたプリフライト チェックが問題なく終了した PreflightCheck リソースを示しています。

    Name:         create-cluster-20230922-175006
    Namespace:    cluster-test-user001
    Labels:       <none>
    Annotations:  <none>
    API Version:  baremetal.cluster.gke.io/v1
    Kind:         PreflightCheck
    Metadata:
      Creation Timestamp:  2023-09-22T17:50:11Z
      Generation:          1
      Resource Version:    6502800
      UID:                 917daf64-963d-44b4-a1f9-c54972a39191
    Spec:
      Check Image Version:  latest
      Config YAML:          ---
    apiVersion: v1
    kind: Namespace
    metadata:
      name: cluster-test-user
    ---
    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      name: test-user001
      namespace: cluster-test-user001
    spec:
      type: user
      profile: default
      anthosBareMetalVersion: 1.15.0
      gkeConnect:
        projectID: clusters-project
      controlPlane:
        nodePoolSpec:
          nodes:
          - address: 192.0.2.53
      ...
    ---
    apiVersion: baremetal.cluster.gke.io/v1
    kind: NodePool
    metadata:
      name: node-pool-1
      namespace: cluster-test-user001
    spec:
      clusterName: test-user001
      nodes:
      - address: 192.0.2.54
      ...
    Status:
      Checks:
        192.0.2.53:
          Job UID:  d0b5dc1f-9d39-4cc8-b3d2-0841212f7f8c
          Message:
          Pass:     true
        192.0.2.53-gcp:
          Job UID:  b4d96ce5-0d4e-4e3c-97db-6317e0c15fc8
          Message:
          Pass:     true
        192.0.2.54:
          Job UID:  b67cf195-3951-46ad-b91c-0d79025cfc0a
          Message:
          Pass:     true
        192.0.2.54-gcp:
          Job UID:  aed509e2-4bf7-44c4-bfa0-8147ef8ea74e
          Message:
          Pass:     true
        Gcp:
          Job UID:  ac479ac4-e1c4-4681-9f2b-5773069bf6ae
          Message:
          Pass:     true
        Node - Network:
          Job UID:  8a57c4ee-ad17-4560-8809-b117c871ad5d
          Message:
          Pass:     true
        Pod - Cidr:
          Message:
          Pass:     true
      Cluster Spec:
        Anthos Bare Metal Version:  1.15.0
        Bypass Preflight Check:     false
        Cluster Network:
          Bundled Ingress:  true
          Pods:
            Cidr Blocks:
              10.0.0.0/16
          Services:
            Cidr Blocks:
              10.96.0.0/20
      ...
      Completion Time:                 2023-09-22T17:51:22Z
      Conditions:
        Last Transition Time:  2023-10-02T23:59:06Z
        Observed Generation:   1
        Reason:                Reconciling
        Status:                True
        Type:                  Reconciling
      Node Pool Specs:
        node-pool-1:
          Cluster Name:  test-user001
          Nodes:
            Address:         192.0.2.54
        ...
      Pass:                  true
      Start Time:            2023-09-22T17:50:32Z
    Events:                  <none>
    

    上記の PreflightCheck カスタム リソースでは、Status セクションに次の情報が含まれています。

    • Checks セクションには、実行された個々のプリフライト チェックと合格の有無が一覧表示されます。この例では、次のチェックが実行されています。
      • 192.0.2.53192.0.2.54: IP アドレス 192.0.2.53192.0.2.54 を持つマシンのノードチェック(OS 構成、リソース、ソフトウェア設定)。
      • 192.0.2.53-gpc192.0.2.54-gcp: IP アドレス 192.0.2.53192.0.2.54 を持つマシンの Google Cloud 接続チェック(Container Registry と Google API アクセス)を行います。
      • Gcp: クラスタのための Google Cloud 接続チェック。
      • Node - Network: クラスタのネットワーク チェック(接続、etcd オペレーション、VIP アクセス、ポート バインディング)。
      • Pod - Cidr: Pod IP アドレスでは、クラスタで重複するアドレスがないかどうか確認されます。
    • Cluster Spec セクションに、クラスタ構成が表示されます。
    • Pass フィールドには true が表示され、プリフライト チェックにまとめて合格したことが示されます。

プリフライト チェックのログ

bmctl check preflight などの bmctl コマンドの結果としてプリフライト チェックが実行される場合、GDCV for Bare Metal はログファイルを作成します。生成される内容と場所は次のとおりです。

  • プリフライト チェックログは、次の命名パターン preflight-TIMESTAMP のディレクトリに生成されます。

  • このプリフライト ディレクトリは、bmctl ワークスペースのクラスタの log ディレクトリに作成されます。デフォルトでは、log ディレクトリ パスは bmctl-workspace/CLUSTER_NAME/log です。

  • プリフライト ログは次のファイルで構成されます。

    • ノードマシン チェックのログファイル(クラスタノードごとに 1 つ)。これらのログファイルには、ノードの IP アドレスを使用して名前が付けられます。たとえば、ファイル名は 192.0.2.53 のようになります。

    • Google Cloud アクセス チェックのログファイル(クラスタノードごとに 1 つ)。これらのログファイルには、ノードの IP アドレスを使用して名前が付けられます。たとえば、ファイル名は 192.0.2.53-gcp のようになります。

    • クラスタ Google Cloud アクセス チェックのログファイル。名前は gcp です。

    • ノード ネットワーキング チェックのログファイル。名前は node-network です。

プリフライト チェックに失敗した場合、これらのログファイルは問題の特定とトラブルシューティングに役立ちます。

クラスタ作成に対するプリフライト チェック

クラスタを作成すると、GDCV for Bare Metal は、変更を行う前にプリフライト チェックを自動的に実行します。

チェック対象

インストールのプリフライト チェックでは、以下を確認します。

  • ノードマシンのチェック:

    • クラスタマシンが、サポートされているオペレーティング システム(OS)を使用している。

    • OS バージョンがサポートされている。

    • OS で、サポートされているカーネル バージョンが使用されている。

    • Ubuntu の場合、Uncomplicated Firewall(UFW)が無効になっていること。

    • Ubuntu の場合、パッケージ管理システム apt が動作可能で、必要なパッケージを利用できること。

    • Red Hat Enterprise Linux の場合、パッケージ管理システム dnf が動作可能で、必要なパッケージを利用できること。

    • Red Hat Enterprise Linux の場合、Podman がインストールされていないこと。

    • ノードマシンが最小 CPU 要件を満たしていること。

    • ノードマシンが最小メモリ要件を満たしていること。

    • ノードマシンが最小ディスク ストレージ要件を満たしていること。

    • ノードマシンで時刻同期が構成されていること。

    • kubelet はアクティブで、ノードマシンで実行中であること。

    • containerd はアクティブで、ノードマシンで実行中であること。

    • デフォルト ゲートウェイにパケットをルーティングするためのデフォルト ルートがノード内に存在すること。

    • ドメイン ネーム システム(DNS)が正常に機能していること。クラスタがプロキシの背後で実行されるように構成されている場合、このチェックはスキップされます。

    • Pod CIDR がノードマシンの IP アドレスと重複しないこと。

    • クラスタがレジストリ ミラーを使用するように構成されている場合、そのレジストリ ミラーにアクセスできること。

  • Google Cloud は、各ノードとクラスタをチェックします。

    • Container Registry、gcr.io、ネットワーク到達性をチェック。クラスタがレジストリ ミラーを使用するように構成されている場合、このチェックはスキップされます。

    • Google API に到達できること。

  • ノード ネットワーキング チェック(ロード バランシング構成によって異なる):

    • Kubernetes API サーバーの VIP にアクセスできる。

    • ロードバランサの VIP にアクセスできる。

    • ノードは必要なポートで通信できる。

    • etcd イベントのインスタンスがプロビジョニングされ、ポート要件が満たされている。

すべてのチェックに合格すると、GDCV for Bare Metal でクラスタが作成されます。クラスタ作成の要件の詳細については、インストールの前提条件の概要をご覧ください。

クラスタ作成に対するオンデマンド プリフライト チェックの実行

また、クラスタを作成する前にプリフライト チェックを実行することもできます。クラスタの作成などの大規模なクラスタ オペレーションには時間がかかるため、事前の実行によりメリットが得られます。大規模なクラスタ オペレーションを開始する前に、問題を個別に特定して解決すると、スケジューリングに役立ちます。

セルフマネージド クラスタ

  • 次のコマンドは、指定されたクラスタ構成ファイルを検証しますが、クラスタ自体の作成は行いません。

    bmctl check config --cluster CLUSTER_NAME
    

    CLUSTER_NAME は、確認する構成ファイルに関連付けられているクラスタの名前に置き換えます。

  • このコマンドは、マシンとネットワークが、クラスタを作成できる状態にあることを確認します。

    bmctl check preflight --cluster CLUSTER_NAME
    

    CLUSTER_NAME は、確認するクラスタの名前に置き換えます。

ユーザー クラスタ

  • 次のコマンドは、指定されたクラスタ構成ファイルを検証しますが、クラスタ自体の作成は行いません。

    bmctl check config --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG
    

    次のように置き換えます。

    • CLUSTER_NAME: 確認するユーザー クラスタの名前。
    • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。
  • このコマンドは、マシンとネットワークが、クラスタを作成できる状態にあることを確認します。

    bmctl check preflight --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG
    

bmctl では、--admin-kubeconfig フラグのエイリアスとして --kubeconfig の使用がサポートされます。

クラスタ アップグレードのプリフライト チェック

クラスタをアップグレードすると、GDCV for Bare Metal は、変更を行う前に自動的にプリフライト チェックを実行します。

チェック対象

クラスタ アップグレードのプリフライト チェックでは、以下を確認します。

  • ノードマシンのチェック:

    • クラスタマシンが、サポートされているオペレーティング システム(OS)を使用している。

    • OS バージョンがサポートされている。

    • OS で、サポートされているカーネル バージョンが使用されている。

    • Ubuntu の場合、Uncomplicated Firewall(UFW)が無効になっていること。

    • ノードマシンが最小 CPU 要件を満たしていること。

    • ノードマシンの CPU リソースが 20% 以上利用できる。

    • ノードマシンが最小メモリ要件を満たしていること。

    • ノードマシンが最小ディスク ストレージ要件を満たしていること。

    • ノードマシンで時刻同期が構成されていること。

    • デフォルト ゲートウェイにパケットをルーティングするためのデフォルト ルートがノード内に存在すること。

    • ドメイン ネーム システム(DNS)が正常に機能していること。クラスタがプロキシの背後で実行されるように構成されている場合、このチェックはスキップされます。

    • クラスタがレジストリ ミラーを使用するように構成されている場合、そのレジストリ ミラーにアクセスできること。

    * メンテナンス モードのコントロール プレーン ノードまたはロードバランサのノードはありません。 (GDCV for Bare Metal バージョン 1.15.2 で追加)。

  • Google Cloud は、各ノードとクラスタをチェックします。

    • Container Registry、gcr.io、ネットワーク到達性をチェック。クラスタがレジストリ ミラーを使用するように構成されている場合、このチェックはスキップされます。

    • Google API に到達可能です。

  • マシンチェック:

    • kubelet はアクティブで、ノードマシンで実行中であること。

    • containerd はアクティブで、ノードマシンで実行中であること。

    • Container Network Interface(CNI)のヘルス エンドポイントのステータスが正常です。

    • Pod CIDR がノードマシンの IP アドレスと重複しないこと。

  • ノード ネットワーキング チェック(ロード バランシング構成によって異なる):

    • Kubernetes API サーバーの VIP にアクセスできる。

    • ロードバランサの VIP にアクセスできる。

    • ノードは必要なポートで通信できる。

    • etcd イベントのインスタンスがプロビジョニングされ、ポート要件が満たされている。

すべてのチェックに合格すると、GDCV for Bare Metal はクラスタをアップグレードします。クラスタのアップグレードの詳細については、GDCV for Bare Metal クラスタのアップグレードに関するベスト プラクティスクラスタ アップグレードのライフサイクルとステージをご覧ください。

クラスタ アップグレード用のオンデマンド プリフライト チェックを実行する

bmctl check preflight コマンドによって、クラスタをアップグレードする前にプリフライト チェックを実行できます。アップグレードを開始する前に、次のプリフライト チェック コマンドを実行することで、クラスタのアップグレードの準備ができているかどうかを確認できます。

  1. クラスタ構成ファイルのクラスタ バージョン(anthosBareMetalVersion)を更新します。

  2. 次のコマンドを使用して、クラスタがアップグレードの準備ができているかどうかを確認し、プリフライト チェックを実行します。

    bmctl check preflight --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
    

    次のように置き換えます。

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

    このコマンドでプリフライト チェックを作成してクラスタのアップグレードをテストすると、管理クラスタに PreflightCheck カスタム リソースが作成されます。

既存のクラスタに対する内部プリフライト チェック

GDCV for Bare Metal は、Kubernetes リソースを既存のクラスタに適用する際に、内部プリフライト チェックを自動的に実行します。いずれかのチェックが失敗した場合、チェックを明示的にバイパスしない限り、GDCV for Bare Metal は関連ノードを変更しません。

Kubernetes リソース適用時のプリフライト チェックをバイパスする

既存のクラスタにリソースを適用する際に内部プリフライト チェックを無視する場合は、クラスタ構成ファイルの BypassPreflightCheck フィールドを true に設定する必要があります。

以下は、bypassPreflightCheck フィールドが true に設定されているクラスタ構成ファイルの一部です。

apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user1
  namespace: cluster-user1
spec:
  type: user
  bypassPreflightCheck: true
  # Anthos cluster version.
  anthosBareMetalVersion: 1.15.11
...

最新のプリフライト チェックとヘルスチェックを実行する

bmctl を使用してプリフライト チェックまたはヘルスチェックを実行する場合は、コマンドに --check-image-version latest フラグを追加して、最新の GDCV for Bare Metal パッチ バージョンからチェックを実行できます。これにより、最初にクラスタを作成またはアップグレードすることなく、既知の問題を特定できます。

  • 最新のチェックリストを使用して、マシンとネットワークにクラスタを作成する準備が整っているかどうかを判断するには、次の手順を行います。

    bmctl check preflight --cluster CLUSTER_NAME --check-image-version latest
    

    CLUSTER_NAME は、確認するクラスタの名前に置き換えます。

ライブクラスタの最新のヘルスチェックを実行して、クラスタが正常かどうかを判断することもできます。

  • ライブクラスタで最新のヘルスチェックを実行するには、次の手順を行います。

    bmctl check cluster --cluster CLUSTER_NAME --check-image-version latest
    

    CLUSTER_NAME は、確認するクラスタの名前に置き換えます。

自動プリフライト チェックの結果を無視する

クラスタを作成またはアップグレードする前にプリフライト チェックをオンデマンドで実行すると、自動プリフライト チェックをバイパスできます。自動化されたプリフライト チェックをバイパスするには、bmctl create cluster または bmctl upgrade cluster の実行時にオプションの --force フラグを使用します。

次のステップ