Configuración de almacenamiento
Conceptos de almacenamiento de Kubernetes
Kubernetes proporciona una capa de abstracción de la infraestructura sobre la pila de tecnología de virtualización subyacente (opcional) y el hardware. La forma en la que Kubernetes abstrae el almacenamiento es mediante clases de almacenamiento. Al aprovisionar un pod, puede especificar una clase de almacenamiento para cada volumen. En el momento en el que se aprovisiona el pod, se llama al aprovisionador de la clase de almacenamiento para aprovisionar el almacenamiento y, a continuación, se crea un volumen persistente en el almacenamiento aprovisionado y, a continuación, el pod se monta en el volumen persistente mediante una notificación de volumen persistente.
Kubernetes proporciona una manera para que los proveedores de infraestructura de almacenamiento conecten controladores (también llamados "complementos") que amplían Kubernetes. Los complementos de almacenamiento deben ajustarse al estándar de Container Storage Interface. Hay docenas de complementos que se pueden encontrar en esta lista de controladores CSI no definitiva. El controlador CSI específico que utilice depende de factores como si está ejecutando en un servicio Kubernetes administrado y alojado en la nube o qué proveedor OEM utiliza para su hardware.
Para ver las clases de almacenamiento configuradas en su clúster Kubernetes, ejecute este comando:
kubectl get storageclass
Ejemplo de salida de un clúster de Azure Kubernetes Service (AKS):
NAME PROVISIONER AGE
azurefile kubernetes.io/azure-file 15d
azurefile-premium kubernetes.io/azure-file 15d
default (default) kubernetes.io/azure-disk 4d3h
managed-premium kubernetes.io/azure-disk 4d3h
Puede obtener detalles acerca de una clase de almacenamiento mediante la ejecución de este comando:
kubectl describe storageclass/<storage class name>
Ejemplo:
kubectl describe storageclass/azurefile
Name: azurefile
IsDefaultClass: No
Annotations: kubectl.kubernetes.io/last-applied-configuration={"allowVolumeExpansion":true,"apiVersion":"storage.k8s.io/v1beta1","kind":"StorageClass","metadata":{"annotations":{},"labels":{"kubernetes.io/cluster-service":"true"},"name":"azurefile"},"parameters":{"sku
Name":"Standard_LRS"},"provisioner":"kubernetes.io/azure-file"}
Provisioner: kubernetes.io/azure-file
Parameters: skuName=Standard_LRS
AllowVolumeExpansion: True
MountOptions: <none>
ReclaimPolicy: Delete
VolumeBindingMode: Immediate
Events: <none>
Puede ver los volúmenes persistentes aprovisionados actualmente y las notificaciones de volumen persistente mediante la ejecución de los siguientes comandos:
kubectl get persistentvolumes -n <namespace>
kubectl get persistentvolumeclaims -n <namespace>
Ejemplo de cómo mostrar los volúmenes persistentes:
kubectl get persistentvolumes -n arc
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-07fc7b9f-9a37-4796-9442-4405147120da 15Gi RWO Delete Bound arc/sqldemo11-data-claim default 7d3h
pvc-3e772f20-ed89-4642-b34d-8bb11b088afa 15Gi RWO Delete Bound arc/data-metricsdb-0 default 7d14h
pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665 10Gi RWO Delete Bound arc/sqldemo11-logs-claim default 7d3h
pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad 15Gi RWO Delete Bound arc/data-controller default 7d14h
pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91 10Gi RWO Delete Bound arc/logs-controller default 7d14h
pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493 10Gi RWO Delete Bound arc/logs-metricsdb-0 default 7d14h
pvc-8e2cacbc-e953-4901-8591-e77df9af309c 10Gi RWO Delete Bound arc/sqldemo10-logs-claim default 7d14h
pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513 15Gi RWO Delete Bound arc/sqldemo10-data-claim default 7d14h
pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5 15Gi RWO Delete Bound arc/data-controldb default 7d14h
pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb 10Gi RWO Delete Bound arc/logs-controldb default 7d14h
pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4 10Gi RWO Delete Bound arc/logs-logsdb-0 default 7d14h
pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd 15Gi RWO Delete Bound arc/data-logsdb-0 default 7d14h
Ejemplo de cómo mostrar las notificaciones de volumen persistente:
kubectl get persistentvolumeclaims -n arc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
data-controldb Bound pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5 15Gi RWO default 7d14h
data-controller Bound pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad 15Gi RWO default 7d14h
data-logsdb-0 Bound pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd 15Gi RWO default 7d14h
data-metricsdb-0 Bound pvc-3e772f20-ed89-4642-b34d-8bb11b088afa 15Gi RWO default 7d14h
logs-controldb Bound pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb 10Gi RWO default 7d14h
logs-controller Bound pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91 10Gi RWO default 7d14h
logs-logsdb-0 Bound pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4 10Gi RWO default 7d14h
logs-metricsdb-0 Bound pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493 10Gi RWO default 7d14h
sqldemo10-data-claim Bound pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513 15Gi RWO default 7d14h
sqldemo10-logs-claim Bound pvc-8e2cacbc-e953-4901-8591-e77df9af309c 10Gi RWO default 7d14h
sqldemo11-data-claim Bound pvc-07fc7b9f-9a37-4796-9442-4405147120da 15Gi RWO default 7d4h
sqldemo11-logs-claim Bound pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665 10Gi RWO default 7d4h
Factores a tener en cuenta al elegir la configuración de almacenamiento
La selección de la clase de almacenamiento correcta es importante de cara al rendimiento y la resistencia de los datos. La elección de una clase de almacenamiento incorrecta puede poner los datos en riesgo de una pérdida total en caso de que se produzca un error de hardware o puede dar lugar a un rendimiento menos óptimo.
Por lo general, hay dos tipos de almacenamiento:
- Almacenamiento local: almacenamiento aprovisionado en las unidades de disco duro local de un nodo determinado. Este tipo de almacenamiento puede ser idóneo en términos de rendimiento, pero requiere un diseño específico para la redundancia de datos mediante la replicación de los datos en varios nodos.
- Almacenamiento remoto compartido: almacenamiento aprovisionado en algún dispositivo de almacenamiento remoto (por ejemplo, un dispositivo SAN, NAS o un servicio de almacenamiento en la nube, como EBS o Azure Files). Este tipo de almacenamiento proporciona redundancia de datos automáticamente, pero generalmente no es tan rápido como puede serlo el almacenamiento local.
Clases de almacenamiento basadas en NFS
En función de la configuración del servidor NFS y del aprovisionador de la clase de almacenamiento, es posible que deba establecer la propiedad supplementalGroups en las configuraciones de pod para las instancias de base de datos y puede que tenga que cambiar la configuración del servidor NFS para usar los identificadores de grupo pasados por el cliente (en lugar de buscar los identificadores de grupo en el servidor mediante el identificador de usuario pasado). Consulte al administrador de NFS para determinar si este es el caso.
La propiedad supplementalGroups toma un array de valores que puede establecer en la implementación. El controlador de datos de Azure Arc los aplica a cualquier instancia de base de datos que cree.
Para establecer esta propiedad, ejecute el siguiente comando:
az arcdata dc config add --path custom/control.json --json-values 'spec.security.supplementalGroups="1234556"'
Configuración de almacenamiento del controlador de datos
Algunos servicios de Azure Arc para servicios de datos dependen de que estén configurados para usar almacenamiento compartido remoto, porque los servicios no tienen una funcionalidad para replicar los datos. Estos servicios se encuentran en la colección de pods del controlador de datos:
| Servicio | Notificaciones de volumen persistente |
|---|---|
| OpenSearch | <namespace>/logs-logsdb-0, <namespace>/data-logsdb-0 |
| InfluxDB | <namespace>/logs-metricsdb-0, <namespace>/data-metricsdb-0 |
| Instancia de SQL del controlador | <namespace>/logs-controldb, <namespace>/data-controldb |
| Servicio de API del controlador | <namespace>/data-controller |
En el momento en que se aprovisiona el controlador de datos, se especifica la clase de almacenamiento que se va a usar para cada uno de estos volúmenes persistentes mediante el uso del parámetro --storage-class (-sc) en el comando az arcdata dc create o mediante el establecimiento de las clases de almacenamiento en el archivo de plantilla de implementación control.json que se usa. Si utiliza el portal de Azure para crear el controlador de datos en el modo de conexión directa, la plantilla de implementación que elija tendrá la clase de almacenamiento predefinida en la plantilla o puede seleccionar una plantilla que no tenga una clase de almacenamiento predefinida. Si su plantilla no define una clase de almacenamiento, el portal le solicitará una. Si usa una plantilla de implementación personalizada, puede especificar la clase de almacenamiento.
Las plantillas de implementación que se proporcionan listas para usar tienen una clase de almacenamiento predeterminada especificada que es adecuada para el entorno de destino, pero se puede invalidar durante la implementación. Consulte los pasos detallados para crear plantillas personalizadas de configuración y cambiar la configuración de la clase de almacenamiento para los pods del controlador de datos en el momento de la implementación.
Si establece la clase de almacenamiento utilizando el parámetro --storage-class o -sc, esa clase de almacenamiento se utiliza tanto para las clases de almacenamiento de registro como de datos. Si establece las clases de almacenamiento en el archivo de plantilla de implementación, puede especificar clases de almacenamiento diferentes para los registros y los datos.
Factores importantes que se deben tener en cuenta al elegir una clase de almacenamiento para los pods del controlador de datos:
- Debe usar una clase de almacenamiento compartida remota para asegurar la durabilidad de los datos y, de este modo, si un pod o un nodo dejan de estar en funcionamiento, pueden conectarse de nuevo al volumen persistente cuando se recuperen.
- Los datos que se escriben en la instancia de SQL del controlador, la base de datos de métricas y la base de datos de registros suelen ser de un volumen bajo y no son sensibles a la latencia, por lo que un almacenamiento de rendimiento extremadamente rápido no es fundamental. Si tiene usuarios que usan con frecuencia las interfaces de Grafana y Kibana y tiene un gran número de instancias de base de datos, es posible que los usuarios se beneficien de un almacenamiento con un rendimiento más rápido.
- La capacidad de almacenamiento necesaria varía con el número de instancias de base de datos que ha implementado, porque se recopilan registros y métricas para cada instancia de base de datos. Los datos se conservan en las bases de datos de registros y métricas durante dos (2) semanas antes de que se purguen.
- Cambiar la clase de almacenamiento después de la implementación es difícil, no está documentado y no se admite. Asegúrese de elegir la clase de almacenamiento correcta en el momento de la implementación.
Nota:
Si no se especifica ninguna clase de almacenamiento, se utiliza la clase de almacenamiento por defecto. Solo puede haber una clase de almacenamiento predeterminada por cada clúster de Kubernetes. Puede cambiar la clase de almacenamiento predeterminada.
Configuración del almacenamiento de la instancia de base de datos
Cada instancia de base de datos tiene volúmenes persistentes de datos, registros y copia de seguridad. Las clases de almacenamiento de estos volúmenes persistentes se pueden especificar en el momento de la implementación. Si no se especifica ninguna clase de almacenamiento, se utilizará la clase de almacenamiento por defecto.
Cuando crea una instancia utilizando az sql mi-arc create o az postgres server-arc create, hay cuatro parámetros que puede utilizar para establecer las clases de almacenamiento:
| Nombre del parámetro, nombre abreviado | Se utiliza para |
|---|---|
--storage-class-data, -d |
Clase de almacenamiento de todos los archivos de datos (.mdf, ndf). Si no se especifica, el valor predeterminado es la clase de almacenamiento del controlador de datos. |
--storage-class-logs, -g |
Clase de almacenamiento de todos los archivos de registro. Si no se especifica, el valor predeterminado es la clase de almacenamiento del controlador de datos. |
--storage-class-data-logs |
Clase de almacenamiento de los archivos del registro de transacciones de la base de datos. Si no se especifica, el valor predeterminado es la clase de almacenamiento del controlador de datos. |
--storage-class-backups |
Clase de almacenamiento de todos los archivos de copia de seguridad. Si no se especifica, el valor predeterminado es la clase de almacenamiento de los datos (--storage-class-data).Utilice una clase de almacenamiento compatible con ReadWriteMany (RWX) para las copias de seguridad. Obtenga más información sobre los modos de acceso. |
Advertencia
Si no especifica una clase de almacenamiento para las copias de seguridad, la implementación usa la clase de almacenamiento especificada para los datos. Si esta clase de almacenamiento no es compatible con RWX, es posible que la restauración a un momento dado no funcione según lo deseado.
En la tabla siguiente se enumeran las rutas de acceso dentro del contenedor de Azure SQL Managed Instance que está asignado al volumen persistente para datos y registros:
| Nombre del parámetro, nombre abreviado | Ruta de acceso dentro del contenedor mssql-miaa |
Descripción |
|---|---|---|
--storage-class-data, -d |
/var/opt | Contiene directorios para la instalación de mssql y otros procesos del sistema. El directorio mssql contiene los directorios predeterminados para los datos (incluidos los registros de transacciones), el registro de errores y la copia de seguridad. |
--storage-class-logs, -g |
/var/log | Contiene los directorios que almacenan la salida de la consola (stderr, stdout) y otra información de registro de los procesos dentro del contenedor. |
En la tabla siguiente se enumeran las rutas de acceso dentro del contenedor de la instancia de PostgreSQL que está asignado al volumen persistente para datos y registros:
| Nombre del parámetro, nombre abreviado | Ruta de acceso en el contenedor de Postgres | Descripción |
|---|---|---|
--storage-class-data, -d |
/var/opt/postgresql | Contiene los directorios de datos y registro para la instalación de Postgres. |
--storage-class-logs, -g |
/var/log | Contiene los directorios que almacenan la salida de la consola (stderr, stdout) y otra información de registro de los procesos dentro del contenedor. |
Cada instancia de base de datos tiene un volumen persistente separado para archivos de datos, registros y copias de seguridad. Esto significa que existe una separación de la E/S para cada uno de estos tipos de archivos en función de cómo el proveedor de volumen aprovisione el almacenamiento. Cada instancia de base de datos tiene sus propias notificaciones de volumen persistente y sus volúmenes persistentes.
Si hay varias bases de datos en una instancia de base de datos determinada, todas las bases de datos utilizan la misma reclamación de volumen persistente, volumen persistente y clase de almacenamiento. Todas las copias de seguridad, tanto las de registro diferencial como las completas, utilizan la misma reclamación de volumen persistente y el mismo volumen persistente. A continuación se muestran las notificaciones de volumen persistente para los pods de la instancia de base de datos:
| Instancia | Notificaciones de volumen persistente |
|---|---|
| Instancia administrada de Azure SQL | <namespace>/logs-<instance name>-0, <namespace>/data-<instance name>-0 |
| Instancia de Azure Database for PostgreSQL | <namespace>/logs--<instance name>-0, <namespace>/data--<instance name>-0 |
| Azure PostgreSQL | <namespace>/logs-<instance name>-<ordinal>, <namespace>/data-<instance name>-0 |
Factores importantes que se deben tener en cuenta al elegir una clase de almacenamiento para los pods de la instancia de base de datos:
- A partir de la versión de febrero de 2022 de los servicios de datos de Azure Arc, es necesario especificar una clase de almacenamiento que admita ReadWriteMany (RWX) para crear copias de seguridad. Obtenga más información sobre los modos de acceso. Si no se especifica ninguna clase de almacenamiento para la creación de copias de seguridad, se usará la clase de almacenamiento predeterminada de Kubernetes. No obstante, si esta no fuera compatible con RWX, la implementación de la instancia administrada de Azure SQL podría no completarse correctamente.
- Las instancias de base de datos se pueden implementar con un patrón de un único pod o con un patrón de varios pods. Azure SQL Managed Instance con el plan de tarifa De uso general es un ejemplo de patrón de un único pod. Un ejemplo de patrón de varios pods sería un plan de tarifa Crítico para la empresa con alta disponibilidad de Azure SQL Managed Instance. Las instancias de base de datos implementadas con el patrón de un único pod deben usar una clase de almacenamiento compartida remota para asegurar la durabilidad de los datos y, de este modo, si un pod o un nodo dejan de estar en funcionamiento, pueden conectarse de nuevo al volumen persistente cuando se recuperen. En cambio, una instancia de Azure SQL Managed Instance con alta disponibilidad usa Grupos de disponibilidad Always On para replicar los datos de una instancia a otra de forma sincrónica o asincrónica. Especialmente cuando los datos se replican de forma sincrónica, siempre hay varias copias de los datos; normalmente, tres copias. Por este motivo, es posible usar clases de almacenamiento local o de almacenamiento remoto compartido para los archivos de datos y de registro. Si se usa el almacenamiento local, los datos se conservan incluso en caso de que se produzca un error en el pod, el nodo o el hardware de almacenamiento, ya que hay varias copias de los datos. Dada esta flexibilidad, puede optar por usar el almacenamiento local para mejorar el rendimiento.
- En gran medida, el rendimiento de la base de datos está en función del rendimiento de E/S de un dispositivo de almacenamiento determinado. Si la base de datos tiene numerosas lecturas o escrituras, debe elegir una clase de almacenamiento que tenga un hardware diseñado para ese tipo de carga de trabajo. Por ejemplo, si la base de datos se usa principalmente para escrituras, puede elegir un almacenamiento local con RAID 0. Si la base de datos se usa principalmente para lecturas de una pequeña cantidad de "datos activos", pero hay un gran volumen de almacenamiento total de datos inactivos, puede elegir un dispositivo SAN con funcionalidad de almacenamiento en capas. Elegir la clase de almacenamiento adecuada no es muy diferente a elegir el tipo de almacenamiento que se usaría para cualquier base de datos.
- Si está utilizando un proveedor de volumen de almacenamiento local, asegúrese de que los volúmenes locales que se aprovisionan para datos, registros y copias de seguridad están cada uno aterrizando en diferentes dispositivos de almacenamiento subyacentes para evitar la contención en E/S de disco. El sistema operativo también debe estar en un volumen montado en un disco independiente. Esta es en esencia la misma guía que se seguiría para una instancia de base de datos en hardware físico.
- Dado que todas las bases de datos de una instancia determinada comparten una notificación de volumen persistente y un volumen persistente, asegúrese de no coubicar las instancias de base de datos ocupadas en la misma instancia de base de datos. Si es posible, separe las bases de datos ocupadas en sus propias instancias de base de datos para evitar la contención de E/S. Además, use las etiquetas de nodo para que las instancias de base de datos tengan como destino nodos independientes para distribuir el tráfico de E/S global entre varios nodos. Si utiliza la virtualización, asegúrese de considerar la distribución del tráfico de E/S no solo a nivel de nodo, sino también la actividad combinada de E/S que realizan todas las máquinas virtuales de nodo en un host físico determinado.
Estimación de los requisitos de almacenamiento
Cada pod que contiene datos con estado usa al menos dos volúmenes persistentes: un volumen persistente para los datos y otro volumen persistente para los registros. En la tabla siguiente se muestra el número de volúmenes persistentes necesarios para un solo controlador de datos, una instancia de Azure SQL Managed Instance, una instancia de Azure Database for PostgreSQL y una instancia de Hiperescala de PostgreSQL de Azure:
| Tipo de recurso | Número de pods con estado | Número requerido de volúmenes persistentes |
|---|---|---|
| Controlador de datos | 4 (control, controldb, logsdb y metricsdb) |
4 * 2 = 8 |
| Instancia administrada de Azure SQL | 1 | 2 |
| Azure PostgreSQL | 1 | 2 |
La siguiente tabla muestra el número total de volúmenes persistentes necesarios para la implementación de ejemplo:
| Tipo de recurso | Número de instancias | Número requerido de volúmenes persistentes |
|---|---|---|
| Controlador de datos | 1 | 4 * 2 = 8 |
| Instancia administrada de Azure SQL | 5 | 5 * 2 = 10 |
| Azure PostgreSQL | 5 | 5 * 2 = 10 |
| Número total de volúmenes persistentes | 8 + 10 + 10 = 28 |
Este cálculo se puede usar para planear el almacenamiento del clúster de Kubernetes en función del aprovisionador de almacenamiento o el entorno. Por ejemplo, si se usa el aprovisionador de almacenamiento local con un clúster de Kubernetes con cinco (5) nodos, para la implementación de ejemplo anterior cada nodo requiere al menos el almacenamiento de 10 volúmenes persistentes. Del mismo modo, al aprovisionar un clúster de Azure Kubernetes Service (AKS) con cinco (5) nodos, es fundamental elegir un tamaño de máquina virtual adecuado para el grupo de nodos para que se puedan conectar 10 discos de datos. Puede encontrar más información sobre cómo ajustar el tamaño de los nodos para las necesidades de almacenamiento de los nodos de AKS aquí.
Elección de la clase de almacenamiento adecuada
Sitios locales y perimetrales
Microsoft y sus asociados de OEM, SO y Kubernetes disponen de un programa de validación para los servicios de datos de Azure Arc. Este programa proporciona resultados de pruebas comparables a partir de un conjunto de herramientas de pruebas de certificación. Las pruebas evalúan la compatibilidad de funciones, los resultados de las pruebas de estrés y el rendimiento y la escalabilidad. Los resultados de la prueba indican el sistema operativo utilizado, la distribución de Kubernetes utilizada, el HW utilizado, el complemento CSI utilizado y las clases de almacenamiento utilizadas. Esto ayuda a los clientes a elegir la mejor clase de almacenamiento, sistema operativo, distribución de Kubernetes y hardware para sus necesidades. Puede encontrar más información sobre este programa y los resultados de las pruebas aquí.
Servicios de Kubernetes administrado en la nube pública
En el caso de los servicios de Kubernetes administrado basados en la nube pública, podemos hacer las siguientes recomendaciones:
| Servicio en la nube pública | Recomendación |
|---|---|
| Azure Kubernetes Service (AKS) | Azure Kubernetes Service (AKS) tiene dos tipos de almacenamiento: Azure Files y Azure Managed Disks. Cada tipo de almacenamiento tiene dos niveles de precios y rendimiento: Estándar (HDD) y Premium (SSD). Por lo tanto, las cuatro clases de almacenamiento proporcionadas en AKS son azurefile (nivel Estándar de Azure Files), azurefile-premium (nivel Premium de Azure Files), default (nivel Estándar de Azure Disks) y managed-premium (nivel Premium de Azure Disks). La clase de almacenamiento predeterminada es default (nivel Estándar de Azure Disks). Hay diferencias sustanciales de precios entre los tipos y niveles que debe tener en cuenta. En el caso de cargas de trabajo de producción con requisitos de alto rendimiento, se recomienda usar managed-premium para todas las clases de almacenamiento. En el caso de cargas de trabajo de desarrollo y pruebas, pruebas de concepto, etc., donde el costo es una consideración, azurefile es la opción menos costosa. Las cuatro opciones se pueden usar en situaciones que requieran almacenamiento remoto compartido, ya que todas utilizan dispositivos de almacenamiento conectados a la red de Azure. Más información sobre Almacenamiento en AKS. |
| AWS Elastic Kubernetes Service (EKS) | Elastic Kubernetes Service de Amazon tiene una clase de almacenamiento principal basada en el controlador de almacenamiento CSI EBS. Se recomienda para las cargas de trabajo de producción. Hay un nuevo controlador de almacenamiento, el controlador de almacenamiento CSI EFS, que se puede agregar a un clúster de EKS, pero actualmente se encuentra en una fase beta y está sujeto a cambios. Aunque AWS indica que este controlador de almacenamiento se admite para producción, no se recomienda usarlo porque todavía está en versión beta y está sujeto a cambios. La clase de almacenamiento EBS es el valor predeterminado y se llama gp2. Más información sobre Almacenamiento en EKS. |
| Google Kubernetes Engine (GKE) | Google Kubernetes Engine (GKE) solo tiene una clase de almacenamiento llamada standard. Esta clase se usa para discos persistentes de GCE. Al ser la única, también es la predeterminada. Aunque hay un aprovisionador de volúmenes estáticos locales para GKE que puede usar con discos SSD con conexión directa, no es recomendable usarlo, ya que Google no lo mantiene ni presta servicio técnico. Más información sobre Almacenamiento en GKE. |