プリフライト チェックは、クラスタの作成やアップグレードなどの大規模なクラスタ オペレーションを開始する前に問題を特定するのに役立つ予防策です。これらのチェックがオペレーションの前に自動的に実行される場合、すべてのプリフライト チェックに合格しない限り、クラスタは変更されません。オンデマンドでプリフライト チェックを実行することもできます。
このドキュメントでは、各チェック、どのような状況で自動的に実行されるか、手動で実行する方法とタイミング、結果の解釈方法について説明します。
GDCV for Bare Metal では、さまざまな状況でプリフライト チェックを実行できます。
GDCV for Bare Metal は、
bmctlを使用してクラスタとノードプール リソースを作成またはアップグレードするときに、プリフライト チェックを実行します。チェックで不合格になると、変更は一切行われません。これらのチェックをバイパスすることも、明示的に実行することもできます。GDCV for Bare Metal は、管理クラスタやハイブリッド クラスタがユーザー クラスタで Kubernetes リソースを作成または更新するときに、内部プリフライト チェックも実行します。このチェックは、影響を受けるユーザー クラスタに変更が適用される前に実行されます。チェックで不合格になると、変更は一切行われません。
PreflightCheck カスタム リソース
プリフライト チェックが実行されると、GDCV for Bare Metal は PreflightCheck カスタム リソースを作成します。PreflightCheck カスタム リソースは永続的で、プリフライト チェックのアクティビティと結果の記録を提供します。
PreflightCheck カスタム リソースを取得するには、以下を実行します。
特定のクラスタに対して実行されたプリフライト チェックのリストを取得します。
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特定の
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.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.53と192.0.2.54: IP アドレス192.0.2.53と192.0.2.54を持つマシンのノードチェック（OS 構成、リソース、ソフトウェア設定）。192.0.2.53-gpcと192.0.2.54-gcp: IP アドレス192.0.2.53と192.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_NAMECLUSTER_NAMEは、確認する構成ファイルに関連付けられているクラスタの名前に置き換えます。このコマンドは、マシンとネットワークが、クラスタを作成できる状態にあることを確認します。
bmctl check preflight --cluster CLUSTER_NAMECLUSTER_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）が正常に機能していること。クラスタがプロキシの背後で実行されるように構成されている場合、このチェックはスキップされます。
クラスタがレジストリ ミラーを使用するように構成されている場合、そのレジストリ ミラーにアクセスできます。
* メンテナンス モードのコントロール プレーン ノードまたはロードバランサのノードはありません。
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 コマンドによって、クラスタをアップグレードする前にプリフライト チェックを実行できます。アップグレードを開始する前に、次のプリフライト チェック コマンドを実行することで、クラスタのアップグレードの準備ができているかどうかを確認できます。
クラスタ構成ファイルのクラスタ バージョン（
anthosBareMetalVersion）を更新します。次のコマンドを使用して、クラスタがアップグレードの準備ができているかどうかを確認し、プリフライト チェックを実行します。
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.16.8
...
最新のプリフライト チェックとヘルスチェックを実行する
bmctl を使用してプリフライト チェックまたはヘルスチェックを実行する場合は、コマンドに --check-image-version latest フラグを追加して、最新の GDCV for Bare Metal パッチ バージョンからチェックを実行できます。これにより、最初にクラスタを作成またはアップグレードすることなく、既知の問題を特定できます。
最新のチェックリストを使用して、マシンとネットワークにクラスタを作成する準備が整っているかどうかを判断するには、次の手順を行います。
bmctl check preflight --cluster CLUSTER_NAME --check-image-version latestCLUSTER_NAMEは、確認するクラスタの名前に置き換えます。
ライブクラスタの最新のヘルスチェックを実行して、クラスタが正常かどうかを判断することもできます。
ライブクラスタで最新のヘルスチェックを実行するには、次の手順を行います。
bmctl check cluster --cluster CLUSTER_NAME --check-image-version latestCLUSTER_NAMEは、確認するクラスタの名前に置き換えます。
自動プリフライト チェックの結果を無視する
クラスタを作成またはアップグレードする前にプリフライト チェックをオンデマンドで実行すると、自動プリフライト チェックをバイパスできます。自動化されたプリフライト チェックをバイパスするには、bmctl create cluster または bmctl upgrade cluster の実行時にオプションの --force フラグを使用します。