GKE ノードの永続ボリュームアタッチの上限

Autopilot Standard

このドキュメントでは、Google Kubernetes Engine（GKE）ノードで Compute Engine 永続ディスクとハイパーディスクの永続ボリューム接続制限がどのように機能するかについて説明します。ワークロードの適切なスケジューリングとノードプールのサイジングを行うには、GKE ノードにアタッチできる永続ボリュームの最大数を理解することが重要です。ワークロードのスケジューリングをより詳細に制御する場合は、特に単一のインスタンスでアタッチ制限が異なる複数のディスクタイプを使用する場合は、ノードラベルを使用してデフォルトのアタッチ制限をオーバーライドできます。

このドキュメントは、ストレージの作成と割り当てを行うストレージスペシャリストと、ワークロードのスケジューリングとノードプールのサイズ設定を管理する GKE 管理者を対象としています。 Trusted Cloud by S3NS のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

概要

GKE で、Compute Engine Persistent Disk CSI ドライバ（pd.csi.storage.gke.io）を使用して PersistentVolume（PV）をリクエストすると、 Trusted Cloud Persistent Disk サービスからブロックストレージボリュームがプロビジョニングされます。

GKE クラスタで Compute Engine Persistent Disk CSI ドライバ（PDCSI）を有効にすると、PDCSI ドライバはノードごとの Persistent Volume のアタッチ上限を計算して kubelet に報告します。この情報に基づいて、Kubernetes スケジューラは、アタッチ容量に達したノードに永続ボリュームを必要とする Pod を過剰にスケジュールしないように、スケジューリングの決定を行います。PDCSI ドライバが誤ったアタッチ上限（実際の制限よりも大きい数値）を報告した場合、Pod はスケジュールされず、Pending 状態のままになります。これは、Hyperdisk と Persistent Disk のアタッチ上限が異なる C3 などの第 3 世代のマシンタイプで発生する可能性があります。

永続ボリュームのアタッチ上限について

第 4 世代より前のマシンでは、Compute Engine PDCSI ドライバは、すべてのマシンタイプで 128 個のディスク（127 個のデータディスクと 1 個のブートディスク）の永続ボリュームアタッチ上限を設定します。アタッチ上限は、Persistent Disk ボリュームと Hyperdisk ボリュームの両方の合計に適用されます。Hyperdisk の場合、アタッチの上限は、基盤となる Compute Engine マシンタイプ、マシンの vCPU 数、特定の Hyperdisk タイプによって決まります。

次に例を示します。

C4 などの第 4 世代のマシンタイプの場合、PDCSI ドライバは、ノードの vCPU 数に基づいて計算されたデフォルトのアタッチ上限を Kubernetes に正確に報告します。報告される上限は通常、8 ～ 128 個の永続ボリュームの範囲内です。
一方、C3 などの第 3 世代のマシンタイプの場合、PDCSI ドライバはデフォルトの接続上限を 128 個のディスクの固定上限として Kubernetes に報告します。実際の制限は vCPU 数に基づいて 128 個よりも小さくなる可能性があるため、Pod のスケジューリングが失敗する可能性があります。

ノードラベルを使用して、デフォルトのアタッチ上限をオーバーライドできます。

Compute Engine ドキュメントの次のリソースをご覧ください。

使用可能な Compute Engine マシンの世代については、Compute Engine の用語セクションの表をご覧ください。
マシンタイプと互換性のある Persistent Disk タイプのリストについては、マシンシリーズのサポートをご覧ください。
さまざまな Hyperdisk タイプの CPU 数に基づく、サポートされている Hyperdisk アタッチの上限については、VM あたりの Hyperdisk ボリュームの最大数をご覧ください。
Hyperdisk アタッチの上限がノードにどのように適用されるかについては、Hyperdisk VM あたりの上限の概要をご覧ください。

デフォルトの永続ボリュームの接続上限をオーバーライドする

特定の数の永続ボリュームをノードにアタッチする特定の要件やノード構成がある場合は、次のノードラベル node-restriction.kubernetes.io/gke-volume-attach-limit-override: VALUE を使用して、ノードプールのデフォルトの永続ボリュームアタッチ上限をオーバーライドできます。

このノードラベルは、次の GKE バージョンで使用できます。

1.32.4-gke.1698000 以降。
1.33.1-gke.1386000 以降。

新しいノードプール

特定の永続ボリューム接続上限を使用して新しいノードプールを作成するには、次のコマンドを実行します。

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --node-labels=node-restriction.kubernetes.io/gke-volume-attach-limit-override=VALUE

既存のノードプール

既存のノードプールの現在の永続ボリュームアタッチ上限を変更する手順は次のとおりです。

ノードプールの接続上限を更新します。

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --node-labels=node-restriction.kubernetes.io/gke-volume-attach-limit-override=VALUE

pdcsi-node DaemonSet を再起動します。
```
kubectl rollout restart ds pdcsi-node -n kube-system
```
新しいアタッチ上限は、pdcsi-node Pod が Running 状態になった後に適用されます。

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

NODE_POOL_NAME: 作成または更新するノードプールの名前。
CLUSTER_NAME: 作成または更新するノードプールのクラスタの名前。
VALUE: 0～127 の整数。アタッチ可能な永続ボリュームの新しい数を指定します。127 より大きい値を指定すると、ノードラベルは無視され、PDCSI ドライバはデフォルトの永続ボリュームの接続上限を使用します。デフォルトの上限は、第 3 世代マシンでは 128、第 4 世代マシンでは vCPU 数に基づく値です。

オーバーライドを確認する

オーバーライドが正しく適用されたかどうかを確認するには、ノードラベルとノード容量を確認します。

次のコマンドで、NODE_NAME は、ノードラベルのオーバーライドを適用した特定のノードプールに属するノードの名前に置き換えます。

ノードのラベルを確認します。
```
kubectl get node NODE_NAME --show-labels
```
出力には、node-restriction.kubernetes.io/gke-volume-attach-limit-override というラベルが含まれます。
ノード容量を確認します。
```
kubectl describe node NODE_NAME
```
出力には attachable-volumes-gce-pd 容量が含まれます。これは、ノードプールに設定したオーバーライド値と一致している必要があります。詳細については、ノードの割り当て可能なリソースを確認するをご覧ください。

次のステップ

GKE 永続ボリュームストレージについて学習する。
Kubernetes Scheduler の仕組みについて学習する。