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
.
- Si quieres usar Filestore en una red de VPC compartida, consulta las instrucciones de configuración adicionales en Usar Filestore con una VPC compartida.
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
En la Google Cloud consola, ve a la página Crear un clúster de Kubernetes.
Configura el clúster para que se ajuste a tus necesidades.
En el panel de navegación, ve a Clúster y haz clic en Funciones.
Marca la casilla Habilitar controlador de CSI para Filestore.
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
Ve a la página Google Kubernetes Engine en la Google Cloud consola.
En la lista de clústeres, haga clic en el nombre del clúster que quiera modificar.
En Funciones, junto al campo Controlador de CSI para Filestore, haz clic en edit Editar controlador de CSI para Filestore.
Marca la casilla Habilitar controlador de CSI para Filestore.
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
En la Google Cloud consola, ve al menú Google Kubernetes Engine.
En la lista de clústeres, haga clic en el nombre del clúster que quiera modificar.
En Funciones, junto al campo Controlador de CSI para Filestore, haz clic en edit Editar controlador de CSI para Filestore.
Desmarca la casilla Enable Filestore CSI driver (Habilitar controlador de CSI para Filestore).
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
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
Para crear los recursos
PersistentVolumeClaim
yPersistentVolume
a partir del archivo de manifiestopreprov-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
- Usar un PersistentVolumeClaim para acceder al volumen
- Crea un Deployment que consuma el volumen
Crear un StorageClass
Después de habilitar el controlador CSI de Filestore, GKE instala automáticamente las siguientes StorageClasses para aprovisionar instancias de Filestore:
zonal-rwx
, con el nivel zonal de Filestore.enterprise-rwx
, que usa el nivel Enterprise de Filestore, donde cada PersistentVolume de Kubernetes se asigna a una instancia de Filestore.enterprise-multishare-rwx
, con el nivel Enterprise de Filestore, donde cada PersistentVolume de Kubernetes se asigna a un recurso compartido de una instancia de Filestore determinada. Para obtener más información, consulta Filestore multishares para Google Kubernetes Engine.standard-rwx
, con el nivel de servicio HDD básico de Filestore.premium-rwx
, con el nivel de servicio SSD básico 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.
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
aImmediate
, 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 comoWaitForFirstConsumer
, 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
oENTERPRISE
). - 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) yNFS_V4_1
. El protocolo predeterminado esNFS_V3
.
- Si asignas el valor
Para crear un recurso
StorageClass
basado en el archivo de manifiestofilestore-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
.
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
Para crear un recurso
PersistentVolumeClaim
basado en el archivo de manifiestopvc-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
.
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
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
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ó.PersistentVolumeClaim
PersistentVolume
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 ajusteanonUid
.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 accesoNO_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 modoROOT_SQUASH
. Si lo haces, se devolverá un mensaje de errorAccess 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:
- Crea un proyecto host y un proyecto de servicio.
- Habilita la API de Google Kubernetes Engine en los proyectos host y de servicio.
- En el proyecto host, crea una red y una subred.
- Habilita la VPC compartida en el proyecto host.
- En el proyecto host, concede el enlace de rol de usuario
HostServiceAgent
a la cuenta de servicio de GKE del proyecto de servicio. - 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:
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 │ └──────────────────────┴───────────────┴─────────────────────────────┘
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
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.
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.
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 elclaimRef
, asegúrate de hacer referencia al mismo PersistentVolumeClaim que en el paso 2.
Vuelve a implementar la especificación PersistentVolumeClaim.
Comprueba el estado de vinculación de tu PersistentVolumeClaim y PersistentVolume ejecutando
kubectl get pvc
.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
- Consulta cómo desplegar una carga de trabajo con estado de Filestore en GKE.
- Consulta cómo compartir una instancia de Filestore Enterprise con varios volúmenes persistentes.
- Consulta cómo usar la ampliación de volumen.
- Consulta cómo usar las capturas de volumen.
- Consulta más información sobre el controlador de CSI en GitHub.