プリフライト チェック

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

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

Google Distributed Cloud では、さまざまな状況でプリフライト チェックを実行できます。

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

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

PreflightCheck カスタム リソース

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

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

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

    kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
    

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

    • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。
    • CLUSTER_NAMESPACE: クラスタの Namespace。

    レスポンスでは、Namespace ごとにリソースが示されます。すべての Namespace に対して kubectl get preflightchecks を実行すると、包括的なリストを取得できます。レスポンスには、リソースごとにリソースの存続期間とプリフライト チェックの合否が示されます。次のサンプル レスポンスは、cluster-test-admin001 Namespace の 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: クラスタの 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.16.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.16.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 コマンドの実行結果としてプリフライト チェックが実行されると、Google Distributed Cloud によってログファイルが作成されます。生成されるファイルと生成場所は次のとおりです。

  • プリフライト チェックのログは、次の命名パターン 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 です。

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

クラスタ作成のプリフライト チェック

クラスタを作成すると、Google Distributed Cloud では、変更が行われる前に自動的にプリフライト チェックが実行されます。

チェックの対象

インストールのプリフライト チェックでは、次の項目がチェックされます。

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

    • クラスタマシンが、サポートされているオペレーティング システム(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 イベント インスタンスがプロビジョニングされ、ポート要件を満たしている。

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

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

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

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

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

    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 の使用がサポートされます。

クラスタ アップグレードに対するプリフライト チェック

クラスタをアップグレードすると、Google Distributed Cloud では、変更が行われる前に自動的にプリフライト チェックが実行されます。

チェックの対象

クラスタのアップグレードのプリフライト チェックでは、次の項目がチェックされます。

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

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

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

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

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

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

    • ノードマシンで使用可能な CPU リソースが 20% を超えている。

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

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

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

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

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

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

    * コントロール プレーン ノードまたはロードバランサ ノードがメンテナンス モードになっていない。

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

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

    • Google API に到達できる。

  • マシンチェック:

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

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

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

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

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

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

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

    • ノードが必要なポートで通信を行うことができる。

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

すべてのチェックに合格すると、Google Distributed Cloud によりクラスタがアップグレードされます。クラスタのアップグレードの詳細については、Google Distributed Cloud クラスタのアップグレードに関するベスト プラクティスクラスタ アップグレードのライフサイクルとステージをご覧ください。

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

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

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

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

    bmctl check preflight --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
    

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

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

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

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

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

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.30.200-gke.101
...

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

既知の問題が特定されると、プリフライト チェック(とヘルスチェック)が更新されます。インストールされているマイナー バージョンの最新のパッチイメージからチェックを実行するように bmctl に指示するには、--check-image-version latest オプション フラグを使用します。

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

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

これにより、クラスタを作成またはアップグレードせずに、最近特定された既知の問題を検出できます。

ライブクラスタの最新のヘルスチェックを実行して、クラスタが正常に動作するかどうか確認することもできます。詳細については、最新のヘルスチェックを実行するをご覧ください。

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

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

次のステップ