A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://cloud.google.com/kubernetes-engine/docs/how-to/persistent-volumes/filestore-csi-driver below:

Access Filestore instances with the Filestore CSI driver | Google Kubernetes Engine (GKE)

The Filestore CSI driver is the primary way for you to use Filestore instances with Google Kubernetes Engine (GKE). The Filestore CSI driver provides a fully-managed experience powered by the open source Google Cloud Filestore CSI driver.

The Filestore CSI driver version is tied to Kubernetes minor version numbers. The Filestore CSI driver version is typically the latest driver available at the time that the Kubernetes minor version is released. The drivers update automatically when the cluster is upgraded to the latest GKE patch.

Note: Because the Filestore CSI driver and some of the other associated CSI components are deployed as separate containers, they incur resource usage (VM CPU, memory, and boot disk) on Kubernetes nodes. VM CPU usage is typically tens of millicores and memory usage is typically tens of MiB. Boot disk usage is mostly incurred by the logs of the CSI driver and other system containers in the Deployment. Benefits

The Filestore CSI driver provides the following benefits:

Requirements Before you begin

Before you start, make sure that you have performed the following tasks:

Enable the Filestore CSI driver on a new cluster Note: The Filestore CSI driver is enabled by default for Autopilot clusters.

To enable the Filestore CSI driver CSI driver when creating a new Standard cluster, follow these steps with Google Cloud CLI or the Google Cloud console.

gcloud 
gcloud container clusters create CLUSTER_NAME \
    --addons=GcpFilestoreCsiDriver \
    --cluster-version=VERSION

Replace the following:

Console

  1. In the Google Cloud console, go to the Create a Kubernetes cluster page.

    Go to Create a Kubernetes cluster

  2. Configure the cluster to fit your needs.

  3. From the navigation pane, under Cluster, click Features.

  4. Select the Enable Filestore CSI driver checkbox.

  5. Click Create.

If you want to use Filestore on a Shared VPC network, see Enable the Filestore CSI driver on a new cluster with Shared VPC.

After you enable the Filestore CSI driver, you can use the driver in Kubernetes volumes using the driver and provisioner name: filestore.csi.storage.gke.io.

Enable the Filestore CSI driver on an existing cluster Note: The Filestore CSI driver is enabled by default for Autopilot clusters.

To enable the Filestore CSI driver in existing clusters, use the Google Cloud CLI or the Google Cloud console.

To enable the driver on an existing cluster, complete the following steps:

gcloud 
gcloud container clusters update CLUSTER_NAME \
   --update-addons=GcpFilestoreCsiDriver=ENABLED

Replace CLUSTER_NAME with the name of the existing cluster.

Console

  1. Go to the Google Kubernetes Engine page in the Google Cloud console.

    Go to Google Kubernetes Engine

  2. In the cluster list, click the name of the cluster you want to modify.

  3. Under Features, next to the Filestore CSI driver field, click edit Edit Filestore CSI driver.

  4. Select the Enable Filestore CSI driver checkbox.

  5. Click Save Changes.

Disable the Filestore CSI driver

You can disable the Filestore CSI driver on an existing Autopilot or Standard cluster by using the Google Cloud CLI or the Google Cloud console.

Note: We strongly recommend not to manually disable the Filestore CSI driver on Autopilot clusters. Doing so causes any Pods using PersistentVolumes owned by the driver to fail to terminate. New pods attempting to use those PersistentVolumes will also fail to start. gcloud 
gcloud container clusters update CLUSTER_NAME \
    --update-addons=GcpFilestoreCsiDriver=DISABLED \
    --region REGION

Replace the following values:

Console

  1. In the Google Cloud console, go to the Google Kubernetes Engine menu.

    Go to Google Kubernetes Engine

  2. In the cluster list, click the name of the cluster you want to modify.

  3. Under Features, next to the Filestore CSI driver field, click edit Edit Filestore CSI driver.

  4. Clear the Enable Filestore CSI driver checkbox.

  5. Click Save Changes.

Access pre-existing Filestore instances using the Filestore CSI driver

This section describes the typical process for using a Kubernetes volume to access pre-existing Filestore instances using Filestore CSI driver in GKE:

Create a PersistentVolume and a PersistentVolumeClaim to access the instance

  1. Create a manifest file like the one shown in the following example, and name it preprov-filestore.yaml:

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: PV_NAME
spec:
  storageClassName: ""
  capacity:
    storage: 1Ti
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  volumeMode: Filesystem
  csi:
    driver: filestore.csi.storage.gke.io
    volumeHandle: "modeInstance/FILESTORE_INSTANCE_LOCATION/FILESTORE_INSTANCE_NAME/FILESTORE_SHARE_NAME"
    volumeAttributes:
      ip: FILESTORE_INSTANCE_IP
      volume: FILESTORE_SHARE_NAME
      protocol: FILESYSTEM_PROTOCOL
  claimRef:
    name: PVC_NAME
    namespace: NAMESPACE
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: PVC_NAME
  namespace: NAMESPACE
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  resources:
    requests:
      storage: 1Ti

  2. To create the PersistentVolumeClaim and PersistentVolume resources based on the preprov-filestore.yaml manifest file, run the following command:

    kubectl apply -f preprov-filestore.yaml

To specify the NFSv4.1 file system protocol, set the protocol field to NFS_V4_1 in the volumeAttributes field of a PersistentVolume object. To use the NFSv3 file system protocol, set the protocol field to NFS_V3 or omit the protocol field.

Then, proceed to create a Deployment that consumes the volume.

Create a volume using the Filestore CSI driver

The following sections describe the typical process for using a Kubernetes volume backed by a Filestore CSI driver in GKE:

Create a StorageClass

After you enable the Filestore CSI driver, GKE automatically installs the following StorageClasses for provisioning Filestore instances:

Each StorageClass is only available in GKE clusters running in their respective supported GKE version numbers. For a list of supported versions required for each service tier, see Requirements.

You can find the name of your installed StorageClass by running the following command:

kubectl get sc

You can also install a different StorageClass that uses the Filestore CSI driver by adding filestore.csi.storage.gke.io in the provisioner field.

Filestore needs to know on which network to create the new instance. The automatically installed StorageClasses use the default network created for GKE clusters. If you have deleted this network or want to use a different network, you must create a new StorageClass as described in the following steps. Otherwise, the automatically installed StorageClasses won't work.

  1. Save the following manifest as filestore-example-class.yaml:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: filestore-example
provisioner: filestore.csi.storage.gke.io
volumeBindingMode: Immediate
allowVolumeExpansion: true
parameters:
  tier: standard
  network: default

    From the manifest, consider the following parameter configuration:

  2. To create a StorageClass resource based on the filestore-example-class.yaml manifest file, run the following command:

    kubectl create -f filestore-example-class.yaml

If you want to use Filestore on a Shared VPC network, see Create a StorageClass when using the Filestore CSI driver with Shared VPC.

Use a PersistentVolumeClaim to access the volume

You can create a PersistentVolumeClaim resource that references the Filestore CSI driver's StorageClass.

You can use either a pre-installed or custom StorageClass.

The following example manifest file creates a PersistentVolumeClaim that references the StorageClass named filestore-example.

  1. Save the following manifest file as pvc-example.yaml:

    kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
  - ReadWriteMany
  storageClassName: filestore-example
  resources:
    requests:
      storage: 1Ti

  2. To create a PersistentVolumeClaim resource based on the pvc-example.yaml manifest file, run the following command:

    kubectl create -f pvc-example.yaml
Create a Deployment that consumes the volume

The following example Deployment manifest consumes the PersistentVolume resource named pvc-example.yaml.

Multiple Pods can share the same PersistentVolumeClaim resource.

  1. Save the following manifest as filestore-example-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: mypvc
      volumes:
      - name: mypvc
        persistentVolumeClaim:
          claimName: podpvc
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: filestore-example
  resources:
    requests:
      storage: 1Ti

  2. To create a Deployment based on the filestore-example-deployment.yaml manifest file, run the following command:

    kubectl apply -f filestore-example-deployment.yaml

  3. Confirm the Deployment was successfully created:

    kubectl get deployment

    It might take a while for Filestore instances to complete provisioning. Before that, deployments won't report a READY status. You can check the progress by monitoring your PVC status by running the following command:

    kubectl get pvc

    You should see the PVC reach a BOUND status, when the volume provisioning completes.

Label Filestore instances

You can use labels to group related instances and store metadata about an instance. A label is a key-value pair that helps you organize your Filestore instances. You can attach a label to each resource, then filter the resources based on their labels.

You can provide labels by using the labels key in StorageClass.parameters. A Filestore instance can be labeled with information about what PersistentVolumeClaim/PersistentVolume the instance was created for. Custom label keys and values must comply with the label naming convention. See the Kubernetes storage class example to apply custom labels to the Filestore instance.

Use NFSv4.1 file system protocol with Filestore

The Filestore CSI driver supports the NFSv4.1 file system protocol with GKE version 1.33 or later. In case of static provisioning, set the protocol field to NFS_V4_1 in the volumeAttributes field of a PersistentVolume object.

For dynamic provisioning, set the protocol field to NFS_V4_1 in the parameters of a StorageClass object.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: enterprise-multishare-rwx
provisioner: filestore.csi.storage.gke.io
parameters:
  tier: enterprise
  multishare: "true"
  instance-storageclass-label: "enterprise-multishare-rwx"
  protocol: NFS_V4_1
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

You cannot mount the Filestore instance with the NFSv4.1 protocol with mountOptions set to nfsvers=3 in the StorageClass object.

Use fsgroup with Filestore volumes

Kubernetes uses fsGroup to change permissions and ownership of the volume to match a user-requested fsGroup in the Pod's SecurityContext. An fsGroup is a supplemental group that applies to all containers in a Pod. You can apply an fsgroup to volumes provisioned by the Filestore CSI driver.

Configure IP access rules with Filestore volumes

Filestore supports IP-based access control rules for volumes. This feature is available on GKE clusters running version 1.29.5 or later.

This feature allows administrators to specify which IP address ranges are allowed to access a Filestore instance provisioned dynamically through GKE. This enhances security by restricting access to only authorized clients, especially in scenarios where the GKE cluster's IP range is too broad, potentially exposing the Filestore instance to unauthorized users or applications.

These rules can be configured directly through the Filestore API, or through the Filestore CSI driver when a volume is created. You can provide the selected configuration in JSON format in the StorageClass using the nfs-export-options-on-create parameter.

The following example manifest shows how to specify the configuration:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: filestore-example
provisioner: filestore.csi.storage.gke.io
volumeBindingMode: Immediate
allowVolumeExpansion: true
parameters:
  tier: "enterprise"
  nfs-export-options-on-create: '[
    {
      "accessMode": "READ_WRITE",
      "ipRanges": [
        "10.0.0.0/24"
      ],
      "squashMode": "ROOT_SQUASH",
      "anonUid": "1003",
      "anonGid": "1003"
    },
    {
      "accessMode": "READ_WRITE",
      "ipRanges": [
        "10.0.0.0/28"
      ],
      "squashMode": "NO_ROOT_SQUASH"
    }
  ]'
Note: Use the node primary IP range instead of the Pod IP in the nfs-export-options-on-create parameter. Security options

Filestore IP access rules simplify the configuration of shared file storage permissions for your GKE workloads. However, understanding how it manages file ownership and access requires grasping a few key concepts:

Recommendations

This section covers how to use a Filestore instance on a Shared VPC network from a service project.

To set up your clusters with a Shared VPC network, follow these steps:

  1. Create a host and service project.
  2. Enable the Google Kubernetes Engine API on both your host and service projects.
  3. In your host project, create a network and a subnet.
  4. Enable Shared VPC in the host project.
  5. On the host project, grant the HostServiceAgent user role binding for the service project's GKE service account.
  6. Enable private service access on the Shared VPC network.

To enable the Filestore CSI driver on a new cluster with Shared VPC, follow these steps:

  1. Verify the usable subnets and secondary ranges. When creating a cluster, you must specify a subnet and the secondary IP address ranges to be used for the cluster's Pods and Service.

    gcloud container subnets list-usable \
   --project=SERVICE_PROJECT_ID \
   --network-project=HOST_PROJECT_ID

    The output is similar to the following:

    PROJECT                   REGION       NETWORK     SUBNET  RANGE
HOST_PROJECT_ID  us-central1  shared-net  tier-1  10.0.4.0/22
┌──────────────────────┬───────────────┬─────────────────────────────┐
│ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE │            STATUS           │
├──────────────────────┼───────────────┼─────────────────────────────┤
│ tier-1-pods          │ 10.4.0.0/14   │ usable for pods or services │
│ tier-1-services      │ 10.0.32.0/20  │ usable for pods or services │
└──────────────────────┴───────────────┴─────────────────────────────┘

  2. Create a GKE cluster. The following examples show how you can use gcloud CLI to create an Autopilot or Standard cluster configured for Shared VPC. The following examples use the network, subnet, and range names from Creating a network and two subnets.

    Autopilot 
    gcloud container clusters create-auto tier-1-cluster \
   --project=SERVICE_PROJECT_ID \
   --region=COMPUTE_REGION \
   --network=projects/HOST_PROJECT_ID/global/networks/NETWORK_NAME \
   --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET_NAME \
   --cluster-secondary-range-name=tier-1-pods \
   --services-secondary-range-name=tier-1-services
    Standard 
    gcloud container clusters create tier-1-cluster \
   --project=SERVICE_PROJECT_ID \
   --zone=COMPUTE_REGION \
   --enable-ip-alias \
   --network=projects/HOST_PROJECT_ID/global/networks/NETWORK_NAME \
   --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET_NAME \
   --cluster-secondary-range-name=tier-1-pods \
   --services-secondary-range-name=tier-1-services \
   --addons=GcpFilestoreCsiDriver

  3. Create firewall rules to allow communication between nodes, Pods, and Services in your cluster. The following example shows how you can create a firewall rule named my-shared-net-rule-2.

    gcloud compute firewall-rules create my-shared-net-rule-2 \
   --project HOST_PROJECT_ID \
   --network=NETWORK_NAME \
   --allow=tcp,udp \
   --direction=INGRESS \
   --source-ranges=10.0.4.0/22,10.4.0.0/14,10.0.32.0/20

    In the example, the source ranges IP values come from the previous step where you verified the usable subnets and secondary ranges.

The following example shows how you can create a StorageClass when using the Filestore CSI driver with Shared VPC:

cat <<EOF | kubectl apply -f -

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: filestore-sharedvpc-example
provisioner: filestore.csi.storage.gke.io
parameters:
  network: "projects/HOST_PROJECT_ID/global/networks/SHARED_VPC_NAME"
  connect-mode: PRIVATE_SERVICE_ACCESS
  reserved-ip-range: RESERVED_IP_RANGE_NAME
allowVolumeExpansion: true

EOF

Replace the following:

If you want to provision a volume backed by Filestore multishares on GKE clusters running version 1.23 or later, see Optimize storage with Filestore multishares for GKE.

Reconnect Filestore single share volumes

If you are using Filestore with the basic HDD, basic SSD, or enterprise (single share) tier, you can follow these instructions to reconnect your existing Filestore instance to your GKE workloads.

  1. Find the details of your pre-provisioned Filestore instance by following the instructions in Getting information about a specific instance.

  2. Redeploy your PersistentVolume specification. In the volumeAttributes field, modify the following fields to use the same values as your Filestore instance from step 1:

  3. Redeploy your PersistentVolumeClaim specification.

  4. Check the binding status of your PersistentVolumeClaim and PersistentVolume by running kubectl get pvc.

  5. Redeploy your Pod specification and ensure that your Pod is able to access the Filestore share again.

What's next

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4