ACK の Pod でホストパス (HostPath) をボリュームとして使用する方法 - Container Service for Kubernetes

HostPath ボリュームは、ホストノードのファイルシステムからファイルまたはディレクトリを直接 Pod にマウントします。これにより、Pod はノードのファイルシステムに対して読み取りおよび書き込み操作を行うことができます。HostPath は、ノードのログを読み取る、特定の構成ファイルにアクセスする、開発環境でデータを共有するなどのタスクに使用します。

仕組み

ワークフロー

Pod がターゲットノードにスケジュールされると、そのノード上の kubelet はコンテナーの起動前に HostPath ボリュームをマウントします。kubelet は、hostPath フィールドで定義されたマウントタイプ (type) に基づいて、ホストパス (path) を検証および準備します。

DirectoryOrCreate: 指定されたホストの path が存在しない場合、kubelet は権限 0755 を設定した空のディレクトリを作成します。ディレクトリの所有者およびグループは kubelet と一致します。
Directory: 指定されたホストの path は存在し、かつディレクトリである必要があります。それ以外の場合、Pod は起動に失敗します。
FileOrCreate: 指定されたホストの path が存在しない場合、kubelet は権限 0644 を設定した空のファイルを作成します。ファイルの所有者およびグループは kubelet と一致します。
File: 指定されたホストの path は存在し、かつファイルである必要があります。それ以外の場合、Pod は起動に失敗します。

検証が成功した後、kubelet はホストの path をコンテナーにバインドマウントします。マウントポイントに対する以降のすべての読み取りおよび書き込み操作は、ホストのファイルシステム上で直接実行されます。

利用方法

Pod に直接 HostPath をマウントする: Pod の volumes に hostPath を直接定義します。この方法はシンプルですが、ストレージとアプリケーションが密結合します。長期的なメンテナンスが必要なプロダクション環境のアプリケーションや、今後ストレージの変更を要する可能性があるアプリケーションでは、この方法を避けてください。
PersistentVolume (PV) および PersistentVolumeClaim (PVC) を使用して HostPath をマウントする: 独立した PV に hostPath を定義します。その後、Pod は PVC を介してストレージを要求できます。これにより、ストレージとアプリケーションが分離され、Pod の構成を変更せずに基盤となるストレージを独立して管理できるようになります。

適用範囲

この機能は ECS ノードのみをサポートしています。GPU ノードや Lingjun ノードなどの異種コンピューティングノード、ECI や ACS などのサーバーレスコンピュートサービスには対応していません。

オプション 1: Pod に直接 HostPath をマウントする

pod-hostpath-direct.yaml という名前のファイルを作成します。

この例では、ノードの /data ディレクトリを Pod 内の /test ディレクトリにマウントします。

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
    name: test-container
    volumeMounts:
    - mountPath: /test
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      # ホストパスを指定
      path: /data
      # マウントタイプを指定
      type: DirectoryOrCreate

Pod をデプロイします。

kubectl apply -f pod-hostpath-direct.yaml

マウントを確認します。
Pod 内にファイルを作成し、そのファイルがノード上に存在することを確認します。これにより、マウントが正常に完了したことを確認できます。
1. Pod 内にファイルを作成します。
  マウントポイントである Pod の /test ディレクトリ内に test.txt ファイルを作成します。
```
kubectl exec test-pod -- sh -c 'echo "This file was created from within the Pod." > /test/test.txt'
```
2. Pod が実行されているノードの名前を取得します。
```
NODE_NAME=$(kubectl get pod test-pod -o jsonpath='{.spec.nodeName}')
echo "Pod is running on node: $NODE_NAME"
```
3. ノード上のファイルを確認します。
  詳細については、「ノードへのログイン」をご参照ください。ls /data コマンドを実行し、/data ディレクトリに先ほど作成したファイルが含まれているか確認します。
  出力に test.txt ファイルが表示される場合、HostPath ボリュームのマウントは正常に完了しています。

オプション 2: PV および PVC を使用して HostPath をマウントする

pv-pvc-hostpath.yaml という名前のファイルを作成します。

この例では、ホストの /data ディレクトリを指す PV、そのストレージを要求する PVC、および PVC を使用する Pod を作成します。

# --- PersistentVolume 定義 ---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: hostpath-pv
  labels:
    type: local
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/data"
---
# --- PersistentVolumeClaim 定義 ---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: hostpath-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  # セレクターを使用して、PVC が前述の PV にバインドされることを保証
  selector:
    matchLabels:
      type: local
---
# --- Pod 定義 ---
apiVersion: v1
kind: Pod
metadata:
  name: test-pod-pvc
spec:
  containers:
    - name: test-container
      image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
      ports:
        - containerPort: 80
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: storage
  volumes:
    - name: storage
      persistentVolumeClaim:
        # 前述の PVC を参照
        claimName: hostpath-pvc

PV、PVC、および Pod を作成します。
```
kubectl apply -f pv-pvc-hostpath.yaml
```
マウントを確認します。
Pod 内にファイルを作成し、そのファイルがノード上に存在することを確認します。これにより、マウントが正常に完了したことを確認できます。
1. Pod 内にファイルを作成します。
  マウントポイントである Pod の /usr/share/nginx/html ディレクトリ内に test.txt ファイルを作成します。
```
kubectl exec test-pod-pvc -- sh -c 'echo "File from PV/PVC Pod." > /usr/share/nginx/html/test.txt'
```
2. Pod が実行されているノードの名前を取得します。
```
NODE_NAME=$(kubectl get pod test-pod-pvc -o jsonpath='{.spec.nodeName}')
echo "Pod is running on node: $NODE_NAME"
```
3. ノード上のファイルを確認します。
  詳細については、「ノードへのログイン」をご参照ください。ls /data コマンドを実行し、/data ディレクトリに先ほど作成したファイルが含まれているか確認します。
  出力に test.txt ファイルが表示される場合、PV および PVC を使用した HostPath ボリュームのマウントは正常に完了しています。

本番環境に適用

セキュリティ隔離の強化
- 読み取り専用でマウントする: アプリケーションがノードからのデータ読み取りのみを必要とする場合は、ボリュームを読み取り専用 (ReadOnlyMany) でマウントしてください。これにより、ホストファイルへの誤った変更を防止できます。
- 最小権限の原則に従う: ホストのルートディレクトリ (/) や /etc、/var などの機密性の高いシステムディレクトリをマウントしないでください。代わりに、HostPath 用に専用のディレクトリを使用してください。
ノードリソースの監視
- ホストディスクの監視: HostPath ボリュームに書き込むコンテナーは、ノードのディスク領域を消費します。ディスクパーティションの監視およびアラートを実装し、ディスク不足によるノード障害を防止してください。
- I/O 影響の評価: HostPath ボリュームに対する頻繁な読み取りおよび書き込み操作は、ノードの I/O リソースを消費します。これにより、他のアプリケーション Pod に影響を与えるほか、kubelet の安定性にも悪影響を及ぼす可能性があります。潜在的なパフォーマンス影響を評価してください。
HostPath ボリュームは、Pod を特定のノード上の物理ストレージに直接バインドします。HostPath ボリューム内のデータはそのノードに固有であり、Pod が別のノードに移動した場合、データは保持されません。
- データベースやキャッシュなど、高可用性および永続ストレージを必要とするステートフルアプリケーションでは、HostPath を使用しないでください。
  - HostPath ボリューム内のデータは 1 つのノード上でのみ存在します。Pod が再起動または更新されて別のノードに再スケジュールされた場合、元のデータへのアクセスができなくなります。
  - Pod がホストのファイルシステムにアクセスできるようにすると、コンテナーの隔離が破られます。たとえば、ルートディレクトリ / をマウントするなどの誤った構成や、コンテナーの脆弱性が原因で、ノードのセキュリティおよび安定性が損なわれる可能性があります。
- HostPath は、読み取り専用のルートファイルシステムを持つノード（例： ContainerOS）には適していません。

よくある質問

Pod を削除して再作成した後、HostPath ボリューム内のデータは保持されますか？

これは、新規 Pod がスケジュールされるノードによって異なります。

同じノードにスケジュールされる場合: 新規 Pod はノード上の同一ディレクトリをマウントし、以前のすべてのデータにアクセスできます。
新しいノードにスケジュールされる場合: 新規 Pod は新しいノード上の空のディレクトリをマウントします。元のノード上のデータは、新規 Pod からアクセスできなくなります。