プリフライト チェックは、クラスタの作成やアップグレードなどの大規模なクラスタ オペレーションを開始する前に問題を特定する際に役立つ予防策です。これらのチェックがオペレーションの前に自動的に実行される場合、すべてのプリフライト チェックに合格しない限り、クラスタは変更されません。オンデマンドでプリフライト チェックを実行することもできます。
このドキュメントでは、各チェックの内容、どのような状況で自動的に実行されるか、手動で実行する方法とタイミング、結果の解釈方法について説明します。
Google Distributed Cloud では、さまざまな状況でプリフライト チェックを実行できます。
Google Distributed Cloud では、
bmctlを使用してクラスタとノードプール リソースを作成またはアップグレードするときに、プリフライト チェックが実行されます。チェックで不合格になると、変更は一切行われません。これらのチェックをバイパスすることも、明示的に実行することもできます。また、管理クラスタまたはハイブリッド クラスタが、ユーザー クラスタで Kubernetes リソースを作成または更新するときに、Google Distributed Cloud は内部プリフライト チェックを実行します。このチェックは、影響を受けるユーザー クラスタに変更が適用される前に実行されます。チェックで不合格になると、変更は一切行われません。
PreflightCheck カスタム リソース
プリフライト チェックが実行されると、Google Distributed Cloud は PreflightCheck カスタム リソースを作成します。PreflightCheck カスタム リソースは永続的であり、プリフライト チェックのアクティビティと結果が記録されます。
PreflightCheck カスタム リソースを取得するには、以下を実行します。
特定のクラスタに対して実行されたプリフライト チェックのリストを取得します。
kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE次のように置き換えます。
ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。CLUSTER_NAMESPACE: クラスタの Namespace。
レスポンスでは、Namespace ごとにリソースが示されます。すべての Namespace に対して
kubectl get preflightchecksを実行すると、包括的なリストを取得できます。レスポンスには、リソースごとにリソースの存続期間とプリフライト チェックの合否が示されます。次のサンプル レスポンスは、cluster-test-admin001Namespace の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: クラスタの 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 コマンドの実行結果としてプリフライト チェックが実行されると、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_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 の使用がサポートされます。
クラスタ アップグレードに対するプリフライト チェック
クラスタをアップグレードすると、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 コマンドによって、クラスタをアップグレードする前にプリフライト チェックを実行できます。アップグレードを開始する前に、次のプリフライト チェック コマンドを実行することで、クラスタのアップグレードの準備ができているかどうかを確認できます。
クラスタ構成ファイルでクラスタ バージョン（
anthosBareMetalVersion）を更新します。次のコマンドを使用して、クラスタがアップグレードの準備ができているかどうかを確認し、プリフライト チェックを実行します。
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.29.200-gke.243
...
最新のプリフライト チェックとヘルスチェックを実行する
bmctl を使用してプリフライト チェックやヘルスチェックを実行する場合、コマンドに --check-image-version latest フラグを追加することで、最新の Google Distributed Cloud パッチ バージョンからチェックを実行できます。これにより、クラスタを作成またはアップグレードせずに既知の問題を特定できます。
最新のチェックリストを使用して、マシンとネットワークにクラスタを作成する準備が整っているかどうかを判断するには、次の操作を行います。
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 フラグを使用します。