Acceder a instancias de Filestore con el controlador de CSI para Filestore

El controlador CSI de Filestore es la forma principal de usar instancias de Filestore con Google Kubernetes Engine (GKE). El controlador de CSI para Filestore proporciona una experiencia totalmente gestionada basada en el Google Cloud controlador de CSI para Filestore de código abierto.

La versión del controlador de CSI para Filestore está vinculada a los números de versión secundaria de Kubernetes. La versión del controlador CSI de Filestore suele ser la más reciente disponible en el momento en que se publica la versión secundaria de Kubernetes. Los controladores se actualizan automáticamente cuando el clúster se actualiza al último parche de GKE.

Ventajas

El controlador de CSI para Filestore ofrece las siguientes ventajas:

  • Puedes acceder al almacenamiento NFS totalmente gestionado a través de las APIs de Kubernetes (kubectl).

  • Puedes usar el controlador CSI de Filestore de GKE para aprovisionar dinámicamente tus PersistentVolumes.

  • Puedes usar capturas de volumen con el controlador de CSI de Filestore de GKE. Las instantáneas de volumen de CSI se pueden usar para crear copias de seguridad de Filestore.

    Una copia de seguridad de Filestore crea una copia diferencial del sistema de archivos compartido, incluidos todos los datos y metadatos de los archivos, y la almacena por separado de la instancia. Solo puedes restaurar esta copia en una nueva instancia de Filestore. No se admite la restauración en una instancia de Filestore. Puedes usar la API de snapshot de volumen de CSI para activar copias de seguridad de Filestore. Para ello, añade un campo type:backup a la clase de snapshot de volumen.

  • Puedes usar la ampliación de volumen con el controlador de CSI de Filestore para GKE. La ampliación de volumen te permite cambiar el tamaño de la capacidad de tu volumen.

  • Puedes acceder a las instancias de Filestore que ya tengas usando instancias de Filestore aprovisionadas previamente en cargas de trabajo de Kubernetes. También puedes crear o eliminar dinámicamente instancias de Filestore y usarlas en cargas de trabajo de Kubernetes con un StorageClass o un Deployment.

  • Admite multicomparticiones de Filestore para GKE. Esta función te permite crear una instancia de Filestore y asignarle varios volúmenes persistentes montados en NFS más pequeños simultáneamente en cualquier número de clústeres de GKE.

  • Admite el nivel de HDD básico con una capacidad mínima de 100 GiB.

Requisitos

  • Para usar el controlador de CSI de Filestore, tus clústeres deben usar el número de versión de GKE adecuado para tu nivel de servicio. Solo se admiten los siguientes niveles de servicio:

    • HDD básico con GKE 1.21 o versiones posteriores
    • HDD básico (de 100 GiB a 63,9 TiB) con la versión 1.33 de GKE o una posterior
    • SSD básica con GKE 1.21 o una versión posterior
    • Zonal (de 1 a 9,75 TiB) con la versión 1.31 o posterior de GKE
    • Zonal (de 10 a 100 TiB) con GKE versión 1.27 o posterior
    • Regional con la versión 1.33 de GKE o una posterior
    • Enterprise con la versión 1.25 o posterior de GKE
    • Para usar la función de varios recursos compartidos de Filestore, tus clústeres deben usar la versión 1.25 de GKE o una posterior.
  • El controlador CSI de Filestore solo se admite en clústeres que usen Linux. No se admiten nodos de Windows Server.

  • El tamaño mínimo de la instancia depende del nivel de servicio de Filestore que hayas seleccionado:

    • Al menos 100 GiB para un disco duro básico
    • Al menos 1 TiB para otros niveles de Filestore

    Para obtener más información, consulta Niveles de servicio.

  • Filestore usa el protocolo del sistema de archivos NFSv3 en la instancia de Filestore de forma predeterminada y admite cualquier cliente compatible con NFSv3.

  • El protocolo del sistema de archivos NFSv4.1 en instancias de Filestore es compatible con GKE 1.33 o versiones posteriores.

Antes de empezar

Antes de empezar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Cloud Filestore y la API de Google Kubernetes Engine.
  • Habilitar APIs
  • Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.

Habilitar el controlador de CSI para Filestore en un clúster nuevo

Para habilitar el controlador de CSI de Filestore al crear un clúster Standard, sigue estos pasos con la CLI de Google Cloud o la Google Cloud consola.

gcloud

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

Haz los cambios siguientes:

  • CLUSTER_NAME: el nombre de tu clúster.
  • VERSION: el número de versión de GKE. Para usar esta función, debes seleccionar un número de versión compatible. Consulta los [requisitos] para obtener más información. También puedes usar la marca --release-channel y especificar un canal de lanzamiento.

Consola

  1. En la Google Cloud consola, ve a la página Crear un clúster de Kubernetes.

    Ir a Crear un clúster de Kubernetes

  2. Configura el clúster para que se ajuste a tus necesidades.

  3. En el panel de navegación, ve a Clúster y haz clic en Funciones.

  4. Marca la casilla Habilitar controlador de CSI para Filestore.

  5. Haz clic en Crear.

Si quieres usar Filestore en una red de VPC compartida, consulta Habilitar el controlador CSI de Filestore en un clúster nuevo con una VPC compartida.

Después de habilitar el controlador de CSI para Filestore, puedes usarlo en volúmenes de Kubernetes con el nombre del controlador y del aprovisionador: filestore.csi.storage.gke.io.

Habilitar el controlador de CSI para Filestore en un clúster

Para habilitar el controlador CSI de Filestore en clústeres, usa la CLI de Google Cloud o la Google Cloud consola.

Para habilitar el controlador en un clúster, sigue estos pasos:

gcloud

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

Sustituye CLUSTER_NAME por el nombre del clúster.

Consola

  1. Ve a la página Google Kubernetes Engine en la Google Cloud consola.

    Ir a Google Kubernetes Engine

  2. En la lista de clústeres, haga clic en el nombre del clúster que quiera modificar.

  3. En Funciones, junto al campo Controlador de CSI para Filestore, haz clic en Editar controlador de CSI para Filestore.

  4. Marca la casilla Habilitar controlador de CSI para Filestore.

  5. Haz clic en Guardar cambios.

Inhabilitar el controlador de CSI para Filestore

Puedes inhabilitar el controlador CSI de Filestore en un clúster Autopilot o Standard mediante la CLI de Google Cloud o la Google Cloud consola.

gcloud

gcloud container clusters update CLUSTER_NAME \
    --update-addons=GcpFilestoreCsiDriver=DISABLED \
    --region REGION

Sustituye los siguientes valores:

  • CLUSTER_NAME: el nombre del clúster que ya existe.
  • REGION: la región de tu clúster (por ejemplo, us-central1).

Consola

  1. En la Google Cloud consola, ve al menú Google Kubernetes Engine.

    Ir a Google Kubernetes Engine

  2. En la lista de clústeres, haga clic en el nombre del clúster que quiera modificar.

  3. En Funciones, junto al campo Controlador de CSI para Filestore, haz clic en Editar controlador de CSI para Filestore.

  4. Desmarca la casilla Enable Filestore CSI driver (Habilitar controlador de CSI para Filestore).

  5. Haz clic en Guardar cambios.

Acceder a instancias de Filestore ya creadas mediante el controlador de CSI para Filestore

En esta sección se describe el proceso habitual para usar un volumen de Kubernetes con el fin de acceder a instancias de Filestore preexistentes mediante el controlador CSI de Filestore en GKE:

Crea un PersistentVolume y un PersistentVolumeClaim para acceder a la instancia

  1. Crea un archivo de manifiesto como el que se muestra en el siguiente ejemplo y asígnale el nombre 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. Para crear los recursos PersistentVolumeClaim y PersistentVolume a partir del archivo de manifiesto preprov-filestore.yaml, ejecuta el siguiente comando:

    kubectl apply -f preprov-filestore.yaml
    

Para especificar el protocolo del sistema de archivos NFSv4.1, asigna el valor NFS_V4_1 al campo protocol del campo volumeAttributes de un objeto PersistentVolume. Para usar el protocolo del sistema de archivos NFSv3, asigna el valor NFS_V3 al campo protocol o no incluyas el campo protocol.

A continuación, crea un Deployment que consuma el volumen.

Crear un volumen con el controlador de CSI de Filestore

En las siguientes secciones se describe el proceso habitual para usar un volumen de Kubernetes respaldado por un controlador CSI de Filestore en GKE:

Crear un StorageClass

Después de habilitar el controlador CSI de Filestore, GKE instala automáticamente las siguientes StorageClasses para aprovisionar instancias de Filestore:

Cada StorageClass solo está disponible en los clústeres de GKE que se ejecutan en sus respectivos números de versión de GKE compatibles. Para ver una lista de las versiones admitidas que se requieren para cada nivel de servicio, consulta Requisitos.

Para encontrar el nombre de tu StorageClass instalado, ejecuta el siguiente comando:

kubectl get sc

También puedes instalar un StorageClass diferente que utilice el controlador de CSI de Filestore añadiendo filestore.csi.storage.gke.io en el campo provisioner.

Filestore necesita saber en qué red crear la nueva instancia. Las StorageClasses instaladas automáticamente usan la red predeterminada creada para los clústeres de GKE. Si has eliminado esta red o quieres usar otra, debes crear una StorageClass, tal como se describe en los pasos siguientes. De lo contrario, las StorageClasses instaladas automáticamente no funcionarán.

  1. Guarda el siguiente archivo de manifiesto como 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
    

    En el manifiesto, considera la siguiente configuración de parámetros:

    • Si asignas el valor volumeBindingMode a Immediate, el aprovisionamiento del volumen comenzará inmediatamente. Esto es posible porque se puede acceder a las instancias de Filestore desde cualquier zona. Por lo tanto, GKE no necesita saber la zona en la que se programa el pod, a diferencia de Persistent Disk de Compute Engine. Si se define como WaitForFirstConsumer, GKE empieza a aprovisionar solo después de que se haya programado el pod. Para obtener más información, consulta VolumeBindingMode.
    • Se puede especificar cualquier nivel de Filestore compatible en el parámetro tier (por ejemplo, BASIC_HDD, BASIC_SSD, ZONAL o ENTERPRISE).
    • El parámetro network se puede usar al aprovisionar instancias de Filestore en VPCs que no sean predeterminadas. Las VPCs no predeterminadas requieren que se configuren reglas de cortafuegos especiales.
    • El parámetro protocol se puede usar para definir el protocolo del sistema de archivos de la instancia de Filestore. Puede tener los siguientes valores: NFS_V3 (valor predeterminado) y NFS_V4_1. El protocolo predeterminado es NFS_V3.
  2. Para crear un recurso StorageClass basado en el archivo de manifiesto filestore-example-class.yaml, ejecuta el siguiente comando:

    kubectl create -f filestore-example-class.yaml
    

Si quieres usar Filestore en una red de VPC compartida, consulta Crear una StorageClass al usar el controlador CSI de Filestore con una VPC compartida.

Usar un PersistentVolumeClaim para acceder al volumen

Puedes crear un recurso PersistentVolumeClaim que haga referencia al StorageClass del controlador CSI de Filestore.

Puedes usar un StorageClass preinstalado o personalizado.

El siguiente archivo de manifiesto de ejemplo crea un PersistentVolumeClaim que hace referencia al StorageClass llamado filestore-example.

  1. Guarda el siguiente archivo de manifiesto como pvc-example.yaml:

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: podpvc
    spec:
      accessModes:
      - ReadWriteMany
      storageClassName: filestore-example
      resources:
        requests:
          storage: 1Ti
    
  2. Para crear un recurso PersistentVolumeClaim basado en el archivo de manifiesto pvc-example.yaml, ejecuta el siguiente comando:

    kubectl create -f pvc-example.yaml
    

Crear un despliegue que consuma el volumen

El siguiente manifiesto de Deployment usa el recurso PersistentVolume llamado pvc-example.yaml.

Varios pods pueden compartir el mismo recurso PersistentVolumeClaim.

  1. Guarda el siguiente archivo de manifiesto como 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. Para crear un Deployment basado en el archivo de manifiesto filestore-example-deployment.yaml, ejecuta el siguiente comando:

    kubectl apply -f filestore-example-deployment.yaml
    
  3. Confirma que el despliegue se ha creado correctamente:

    kubectl get deployment
    

    Las instancias de Filestore pueden tardar un tiempo en completar el aprovisionamiento. Antes de eso, las implementaciones no mostrarán el estado READY. Para comprobar el progreso, monitoriza el estado de tu PVC ejecutando el siguiente comando:

    kubectl get pvc
    

    Cuando se complete el aprovisionamiento del volumen, el PVC debería alcanzar el estado BOUND.

Etiquetar instancias de Filestore

Puedes usar etiquetas para agrupar instancias relacionadas y almacenar metadatos sobre una instancia. Una etiqueta es un par clave-valor que le ayuda a organizar sus instancias de Filestore. Se puede adjuntar una etiqueta a cada recurso y luego filtrar los recursos en función de sus etiquetas.

Puedes proporcionar etiquetas con la tecla labels en StorageClass.parameters. Se puede etiquetar una instancia de Filestore con información sobre para qué se creó.PersistentVolumeClaimPersistentVolume Las claves y los valores de las etiquetas personalizadas deben cumplir la convención de nomenclatura de las etiquetas. Consulta el ejemplo de clase de almacenamiento de Kubernetes para aplicar etiquetas personalizadas a la instancia de Filestore.

Usar el protocolo de sistema de archivos NFSv4.1 con Filestore

El controlador CSI de Filestore es compatible con el protocolo del sistema de archivos NFSv4.1 en GKE 1.33 o versiones posteriores. En el caso del aprovisionamiento estático, asigna el valor NFS_V4_1 al campo protocol en el campo volumeAttributes de un objeto PersistentVolume.

Para el aprovisionamiento dinámico, asigna el valor NFS_V4_1 al campo protocol en los parámetros de un objeto StorageClass.

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

No puedes montar la instancia de Filestore con el protocolo NFSv4.1 si mountOptions tiene el valor nfsvers=3 en el objeto StorageClass.

Usar fsgroup con volúmenes de Filestore

Kubernetes usa fsGroup para cambiar los permisos y la propiedad del volumen de forma que coincidan con el fsGroup solicitado por el usuario en el SecurityContext del pod. Un fsGroup es un grupo complementario que se aplica a todos los contenedores de un pod. Puedes aplicar un fsgroup a los volúmenes aprovisionados por el controlador de CSI para Filestore.

Configurar reglas de acceso por IP con volúmenes de Filestore

Filestore admite reglas de control de acceso basado en IP para volúmenes. Esta función está disponible en los clústeres de GKE que ejecutan la versión 1.29.5 o posterior.

Esta función permite a los administradores especificar qué intervalos de direcciones IP pueden acceder a una instancia de Filestore aprovisionada dinámicamente a través de GKE. De esta forma, se mejora la seguridad, ya que solo pueden acceder los clientes autorizados, sobre todo en situaciones en las que el intervalo de IPs del clúster de GKE es demasiado amplio, lo que podría exponer la instancia de Filestore a usuarios o aplicaciones no autorizados.

Estas reglas se pueden configurar directamente a través de la API de Filestore o a través del controlador CSI de Filestore cuando se crea un volumen. Puede proporcionar la configuración seleccionada en formato JSON en StorageClass mediante el parámetro nfs-export-options-on-create.

En el siguiente ejemplo de archivo de manifiesto se muestra cómo especificar la configuración:

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"
    }
  ]'

Opciones de seguridad

Las reglas de acceso por IP de Filestore simplifican la configuración de los permisos de almacenamiento de archivos compartidos para tus cargas de trabajo de GKE. Sin embargo, para entender cómo gestiona la propiedad y el acceso a los archivos, es necesario comprender algunos conceptos clave:

  • NFS y asignaciones de usuarios: NFS (Network File System) es el protocolo que usa Filestore. Para ello, asigna los usuarios de los sistemas cliente (tus pods de GKE) a los usuarios del servidor de Filestore. Si un archivo del servidor es propiedad del ID de usuario 1003 y un cliente se conecta con el ID de usuario 1003, tendrá acceso al archivo.

  • Compresión de la raíz y anonUid:

    • Root Squashing ROOT_SQUASH es una función de seguridad que impide que los clientes accedan a la instancia de Filestore con privilegios de superusuario completos. Cuando el squash en raíz está habilitado, los usuarios raíz de los sistemas cliente se asignan a un usuario sin privilegios especificado por el ajuste anonUid.

    • Sin compresión de raíz (NO_ROOT_SQUASH): permite que los clientes accedan a la instancia de Filestore con privilegios de raíz completos, lo que resulta práctico para la configuración inicial, pero menos seguro para las operaciones habituales.

  • Configuración inicial y permisos: de forma predeterminada, una instancia de Filestore nueva es propiedad exclusiva del usuario raíz. Si habilitas la compresión de root sin configurar primero los permisos de otros usuarios, perderás el acceso. Por eso, necesitas al menos una regla de exportación de NFS con NO_ROOT_SQUASH para configurar inicialmente el acceso de otros usuarios y grupos.

Recomendaciones

  • Configuración inicial: empieza siempre con al menos una regla de exportación de NFS que especifique un intervalo de administrador con permisos READ_WRITE y permita el acceso NO_ROOT_SQUASH. Utiliza este acceso para crear directorios, definir permisos y asignar la propiedad según sea necesario.
  • Seguridad: habilita la compresión de root (ROOT_SQUASH) para mejorar la seguridad. Ten en cuenta que, una vez creado un volumen, solo puedes modificar las reglas de acceso a través de la API de Filestore.
  • Acceso compartido: usa fsGroup en tus contextos de seguridad de pods para gestionar la propiedad de grupo de los volúmenes compartidos. Asegúrate de que el ajuste no se solape con el modo ROOT_SQUASH. Si lo haces, se devolverá un mensaje de error Access denied.

Usar Filestore con una VPC compartida

En esta sección se explica cómo usar una instancia de Filestore en una red de VPC compartida desde un proyecto de servicio.

Configurar un clúster con VPC compartida

Para configurar tus clústeres con una red de VPC compartida, sigue estos pasos:

  1. Crea un proyecto host y un proyecto de servicio.
  2. Habilita la API de Google Kubernetes Engine en los proyectos host y de servicio.
  3. En el proyecto host, crea una red y una subred.
  4. Habilita la VPC compartida en el proyecto host.
  5. En el proyecto host, concede el enlace de rol de usuario HostServiceAgent a la cuenta de servicio de GKE del proyecto de servicio.
  6. Habilita el acceso a servicios privados en la red de VPC compartida.

Habilitar el controlador CSI de Filestore en un clúster nuevo con VPC compartida

Para habilitar el controlador CSI de Filestore en un clúster nuevo con una VPC compartida, sigue estos pasos:

  1. Verifica las subredes y los intervalos secundarios utilizables. Cuando creas un clúster, debes especificar una subred y los intervalos de direcciones IP secundarias que se usarán para los pods y el servicio del clúster.

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

    El resultado debería ser similar al siguiente:

    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. Crea un clúster de GKE. En los siguientes ejemplos se muestra cómo puedes usar la CLI de gcloud para crear un clúster de Autopilot o Estándar configurado para una VPC compartida. En los siguientes ejemplos se usan los nombres de la red, la subred y el intervalo de Crear una red y dos subredes.

    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
    

    Estándar

    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. Crea reglas de cortafuegos para permitir la comunicación entre nodos, pods y servicios de tu clúster. En el siguiente ejemplo se muestra cómo crear una regla de firewall llamada 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
    

    En el ejemplo, los valores de IP de los intervalos de origen proceden del paso anterior, en el que verificaste las subredes y los intervalos secundarios utilizables.

Crear un StorageClass al usar el controlador CSI de Filestore con una VPC compartida

En el siguiente ejemplo se muestra cómo crear un StorageClass al usar el controlador CSI de Filestore con una VPC compartida:

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

Haz los cambios siguientes:

  • HOST_PROJECT_ID: el ID o el nombre del proyecto host de la red de VPC compartida.
  • SHARED_VPC_NAME: el nombre de la red de VPC compartida que has creado anteriormente.
  • RESERVED_IP_RANGE_NAME: el nombre del intervalo de direcciones IP reservadas específico en el que se va a aprovisionar la instancia de Filestore. Este campo es opcional. Si se especifica un intervalo de direcciones IP reservado, debe ser un intervalo de direcciones con nombre en lugar de un valor CIDR directo.

Si quieres aprovisionar un volumen respaldado por Filestore multishares en clústeres de GKE que ejecuten la versión 1.23 o posterior, consulta Optimizar el almacenamiento con Filestore multishares para GKE.

Volver a conectar volúmenes de un solo recurso compartido de Filestore

Si utilizas Filestore con el nivel HDD básico, SSD básico o Enterprise (recurso compartido único), puedes seguir estas instrucciones para volver a conectar tu instancia de Filestore a tus cargas de trabajo de GKE.

  1. Para consultar los detalles de tu instancia de Filestore preprovisionada, sigue las instrucciones que se indican en Obtener información sobre una instancia específica.

  2. Vuelve a implementar la especificación PersistentVolume. En el campo volumeAttributes, modifica los siguientes campos para que usen los mismos valores que tu instancia de Filestore del paso 1:

    • ip: modifica este valor por la dirección IP de la instancia de Filestore preaprovisionada.
    • volume: Modifica este valor por el nombre del recurso compartido de la instancia de Filestore preprovisionada. En el claimRef, asegúrate de hacer referencia al mismo PersistentVolumeClaim que en el paso 2.
  3. Vuelve a implementar la especificación PersistentVolumeClaim.

  4. Comprueba el estado de vinculación de tu PersistentVolumeClaim y PersistentVolume ejecutando kubectl get pvc.

  5. Vuelve a implementar la especificación de tu pod y asegúrate de que pueda acceder de nuevo al recurso compartido de Filestore.

Siguientes pasos