GKE 用に Cloud Storage FUSE CSI ドライバのサイドカー コンテナを構成する

このガイドでは、限定公開イメージ、カスタム書き込みバッファ、カスタム読み取りキャッシュ ボリュームの設定など、Cloud Storage FUSE CSI ドライバ サイドカー コンテナのリソースを構成する方法について説明します。通常、これらの設定を変更する必要はありません。

Cloud Storage FUSE CSI ドライバは、カスタマイズ可能なサイドカー コンテナを使用して、Cloud Storage バケットを効率的にマウントしてアクセスします。サイドカーを構成することで、アプリケーションのパフォーマンスとリソース使用量を微調整できます。これにより、データアクセスの高速化、処理時間の短縮、アプリケーションの全体的なリソース使用量の削減が可能になります。

このガイドは、GKE とやり取りするアプリケーションのパフォーマンス、セキュリティ、効率を最適化したいデベロッパー、管理者、アーキテクトを対象としています。

このページを読む前に、Cloud Storage、Kubernetes、コンテナ化のコンセプトの基本を理解しておいてください。

サイドカー コンテナの仕組み

Cloud Storage FUSE CSI ドライバは、サイドカー コンテナを使用して Cloud Storage バケットをマウントし、Kubernetes アプリケーションからローカル ファイル システムとしてアクセスできるようにします。このサイドカー コンテナ（gke-gcsfuse-sidecar という名前）は、同じ Pod 内のワークロード コンテナとともに実行されます。ドライバは、Pod 仕様で gke-gcsfuse/volumes: "true" アノテーションを検出すると、サイドカー コンテナを自動的に挿入します。このサイドカー コンテナ アプローチは、セキュリティを確保し、リソースを効果的に管理するのに役立ちます。

サイドカー コンテナは、Cloud Storage バケットのマウントの複雑さを処理し、Cloud Storage FUSE ランタイムを直接管理することなく、アプリケーションへのファイル システム アクセスを提供します。gke-gcsfuse/cpu-limit や gke-gcsfuse/memory-limit などのアノテーションを使用して、サイドカー コンテナのリソース上限を構成できます。サイドカー コンテナ モデルでは、Cloud Storage FUSE インスタンスがワークロードのライフサイクルに関連付けられるため、リソースが不必要に消費されることはありません。つまり、ワークロード コンテナが終了すると、サイドカー コンテナは自動的に終了します。特に、RestartPolicy が Never の Job ワークロードまたは Pod の場合です。

Istio の互換性

Cloud Storage FUSE CSI ドライバのサイドカー コンテナと Istio は、Pod 内で共存して同時に実行できます。Istio のサイドカー プロキシがネットワーク トラフィックを管理し、CSI サイドカーがストレージ アクセスを最適化するため、アプリケーションは Google Cloud Storage と効率的にやり取りし、パフォーマンスとオブザーバビリティを向上させることができます。

カスタム書き込みバッファを構成する

Cloud Storage FUSE は、ローカル ディレクトリに書き込みをステージングし、close オペレーションまたは fsync オペレーションで Cloud Storage にアップロードします。

このセクションでは、Cloud Storage FUSE 書き込みバッファリング用のカスタム バッファ ボリュームを構成する方法について説明します。このシナリオは、Cloud Storage FUSE のデフォルトの emptyDir ボリュームを置き換えて、書き込みオペレーションでファイルをステージングする必要がある場合に適用できます。これは、Autopilot クラスタで 10 GiB を超えるファイルを書き込む必要がある場合に有効です。

ファイル キャッシュに、Cloud Storage FUSE CSI ドライバでサポートされている任意のタイプのストレージ（ローカル SSD、Persistent Disk ベースのストレージ、RAM ディスク（メモリ）など）を指定できます。GKE は、指定されたボリュームをファイルの書き込みバッファに使用します。これらのオプションの詳細については、ファイル キャッシュのバックアップ用ストレージを選択するをご覧ください。

カスタム バッファ ボリュームを使用するには、ゼロ以外の fsGroup を指定する必要があります。

次の例は、バッファ ボリュームとして事前定義された PersistentVolumeClaim を使用する方法を示しています。

apiVersion: v1
kind: Pod
metadata:
  annotations:
    gke-gcsfuse/volumes: "true"
spec:
  securityContext:
    fsGroup: FS_GROUP
  containers:
  ...
  volumes:
  - name: gke-gcsfuse-buffer
    persistentVolumeClaim:
      claimName: BUFFER_VOLUME_PVC

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

  • FS_GROUP: fsGroup ID。
  • BUFFER_VOLUME_PVC: 事前定義された PVC 名。

カスタム読み取りキャッシュ ボリュームを構成する

このセクションでは、Cloud Storage FUSE 読み取りキャッシュ用にカスタム キャッシュ ボリュームを構成する方法について説明します。

このシナリオは、Cloud Storage FUSE のデフォルトの emptyDir ボリュームを置き換えて、読み取りオペレーションでファイルをキャッシュに保存する必要がある場合に適用できます。GKE でサポートされている任意のタイプのストレージ（PersistentVolumeClaim など）を指定できます。GKE は、指定されたボリュームをファイル キャッシュに使用します。これは、Autopilot クラスタで 10 GiB を超えるファイルをキャッシュに保存する必要がある場合に便利です。カスタム キャッシュ ボリュームを使用するには、ゼロ以外の fsGroup を指定する必要があります。

次の例は、キャッシュ ボリュームとして事前定義済みの PersistentVolumeClaim を使用する方法を示しています。

apiVersion: v1
kind: Pod
metadata:
  annotations:
    gke-gcsfuse/volumes: "true"
spec:
  securityContext:
    fsGroup: FS_GROUP
  containers:
  ...
  volumes:
  - name: gke-gcsfuse-cache
    persistentVolumeClaim:
      claimName: CACHE_VOLUME_PVC

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

  • FS_GROUP: fsGroup ID。
  • CACHE_VOLUME_PVC: 事前定義された PersistentVolumeClaim 名。

サイドカー コンテナの非公開イメージを構成する

このセクションでは、限定公開コンテナ レジストリにホストされているサイドカー コンテナ イメージの使用方法について説明します。このシナリオは、セキュリティのためにプライベート ノードを使用する必要がある場合に該当します。

限定公開のサイドカー コンテナ イメージを構成して使用するには、次の操作を行います。

  1. 互換性のある公開サイドカー コンテナ イメージについては、こちらの GKE 互換性表をご覧ください。
  2. ローカル環境に pull して限定公開コンテナ レジストリに push します。

  3. マニフェストで、image フィールドのみを含む gke-gcsfuse-sidecar という名前のコンテナを指定します。GKE は、指定されたサイドカー コンテナ イメージを使用して、サイドカー コンテナ インジェクションを準備します。

    以下に例を示します。

    apiVersion: v1
kind: Pod
metadata:
  annotations:
    gke-gcsfuse/volumes: "true"
spec:
  containers:
  - name: gke-gcsfuse-sidecar
    image: PRIVATE_REGISTRY/gcs-fuse-csi-driver-sidecar-mounter:PRIVATE_IMAGE_TAG
  - name: main # your main workload container.

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

    • PRIVATE_REGISTRY: 限定公開のコンテナ レジストリ。
    • PRIVATE_IMAGE_TAG: 限定公開のサイドカー コンテナ イメージのタグ。

サイドカー コンテナ リソースを構成する

デフォルトでは、サイドカー コンテナは次のリソース リクエストで構成され、リソースの上限は設定されていません（Standard クラスタの場合）。

  • 250m CPU
  • 256 MiB のメモリ
  • 5 GiB のエフェメラル ストレージ

これらの値を上書きするには、必要に応じて次の例に示すようにアノテーション gke-gcsfuse/[cpu-limit|memory-limit|ephemeral-storage-limit|cpu-request|memory-request|ephemeral-storage-request] を指定します。

apiVersion: v1
kind: Pod
metadata:
  annotations:
    gke-gcsfuse/volumes: "true"
    gke-gcsfuse/cpu-limit: "10"
    gke-gcsfuse/memory-limit: 10Gi
    gke-gcsfuse/ephemeral-storage-limit: 1Ti
    gke-gcsfuse/cpu-request: 500m
    gke-gcsfuse/memory-request: 1Gi
    gke-gcsfuse/ephemeral-storage-request: 50Gi

値 "0" を使用すると、Standard クラスタに対するリソース上限またはリクエストの設定を解除できます。たとえば、アノテーション gke-gcsfuse/memory-limit: "0" により、サイドカー コンテナのメモリ上限はデフォルトのメモリ リクエストで空になります。これは、ワークロードに対して Cloud Storage FUSE で必要になるリソースの量を特定できず、ノード上の使用可能なすべてのリソースを Cloud Storage FUSE が消費できるようにする必要がある場合に有効です。ワークロードの指標に基づいて Cloud Storage FUSE のリソース要件を計算した後、適切な上限を設定できます。

次のステップ