Preparar Linux para volúmenes perimetrales
En el artículo se describe cómo preparar Linux para volúmenes perimetrales mediante AKS habilitado por Azure Arc, Edge Essentials o Ubuntu.
Nota:
La versión mínima admitida del kernel de Linux es la 5.1. En este momento, hay problemas conocidos con la versión 6.4 y 6.2.
Requisitos previos
Nota:
Azure Container Storage habilitado por Azure Arc solo está disponible en las siguientes regiones: Este de EE. UU., Este de EE. UU. 2, Oeste de EE. UU., Oeste de EE. UU. 2, Oeste de EE. UU. 3, Norte de Europa, Oeste de Europa.
Desinstalación de la instancia anterior de la extensión de Azure Container Storage habilitado por Azure Arc
Si instaló anteriormente una versión de Azure Container Storage habilitado por Azure Arc anterior a la versión preliminar 2.1.0, debe desinstalar esa instancia anterior para instalar la versión más reciente. Si instaló la versión 1.2.0-preview o una versión anterior, use estas instrucciones. Las versiones posteriores a 2.1.0-preview se pueden actualizar y no requieren esta desinstalación.
Para eliminar la versión anterior de la extensión, los recursos de Kubernetes que contienen referencias a la versión anterior de la extensión deben limpiarse. Los recursos pendientes pueden retrasar la limpieza de la extensión. Hay al menos dos maneras de limpiar estos recursos: usar
kubectl delete <resource_type> <resource_name>
o "no aplicar" los archivos YAML usados para crear los recursos. Los recursos que deben eliminarse suelen ser los pods, el PVC al que se hace referencia y el CRD de subvolumen (si se configuró el volumen de perimetral de ingesta en la nube). Como alternativa, los cuatro archivos YAML siguientes se pueden pasar akubectl delete -f
mediante los siguientes comandos en el orden especificado. Estas variables deben actualizarse con la información:YOUR_DEPLOYMENT_FILE_NAME_HERE
: agregue los nombres de archivo de implementación. En el ejemplo de este artículo, el nombre de archivo usado eradeploymentExample.yaml
. Si ha creado varias implementaciones, cada una debe eliminarse en una línea independiente.YOUR_PVC_FILE_NAME_HERE
: agregue los nombres de archivo de notificación de volumen persistente. En el ejemplo de este artículo, si usó el volumen perimetral de ingesta en la nube, el nombre de archivo usado eracloudIngestPVC.yaml
. Si usó el volumen perimetral compartido local, el nombre de archivo usado eralocalSharedPVC.yaml
. Si ha creado varios PVC, cada uno debe eliminarse en una línea independiente.YOUR_EDGE_SUBVOLUME_FILE_NAME_HERE
: agregue los nombres de archivo de subvolume perimetral. En el ejemplo de este artículo, el nombre de archivo usado eraedgeSubvolume.yaml
. Si ha creado varias subvolúmenes, cada una debe eliminarse en una línea independiente.YOUR_EDGE_STORAGE_CONFIGURATION_FILE_NAME_HERE
: agregue el nombre del archivo de configuración de almacenamiento perimetral aquí. En el ejemplo de este artículo, el nombre de archivo usado eraedgeConfig.yaml
.
kubectl delete -f "<YOUR_DEPLOYMENT_FILE_NAME_HERE.yaml>" kubectl delete -f "<YOUR_PVC_FILE_NAME_HERE.yaml>" kubectl delete -f "<YOUR_EDGE_SUBVOLUME_FILE_NAME_HERE.yaml>" kubectl delete -f "<YOUR_EDGE_STORAGE_CONFIGURATION_FILE_NAME_HERE.yaml>"
Después de eliminar los archivos de las implementaciones, PVC, subvolumes perimetrales y la configuración de almacenamiento perimetral del paso anterior, puede desinstalar la extensión mediante el siguiente comando. Reemplace
YOUR_RESOURCE_GROUP_NAME_HERE
,YOUR_CLUSTER_NAME_HERE
yYOUR_EXTENSION_NAME_HERE
por su información respectiva:az k8s-extension delete --resource-group YOUR_RESOURCE_GROUP_NAME_HERE --cluster-name YOUR_CLUSTER_NAME_HERE --cluster-type connectedClusters --name YOUR_EXTENSION_NAME_HERE
Clúster de Kubernetes conectado a Arc
En estas instrucciones se supone que ya tiene un clúster de Kubernetes conectado a Arc. Para conectar un clúster de Kubernetes existente a Azure Arc, consulte estas instrucciones.
Si quiere usar Azure Container Storage habilitado por Azure Arc con Azure IoT Operations, siga las instrucciones para crear un clúster para Azure IoT Operations.
Clústeres de un solo nodo y varios nodos
Un clúster de un solo nodo se usa normalmente con fines de desarrollo o pruebas debido a su simplicidad en la configuración y los requisitos mínimos de recursos. Estos clústeres ofrecen un entorno ligero y sencillo para que los desarrolladores experimenten con Kubernetes sin la complejidad de una configuración de varios nodos. Además, en situaciones en las que los recursos como CPU, memoria y almacenamiento están limitados, un clúster de un solo nodo es más práctico. Su facilidad de configuración y los requisitos mínimos de recursos lo convierten en una opción adecuada en entornos con restricciones de recursos.
Sin embargo, los clústeres de nodo único incluyen limitaciones, principalmente en forma de características que faltan, como su falta de alta disponibilidad, tolerancia a errores, escalabilidad y rendimiento.
Normalmente, se usa una configuración de Kubernetes de varios nodos para escenarios de producción, almacenamiento provisional o a gran escala debido a características, como la alta disponibilidad, la tolerancia a errores, la escalabilidad y el rendimiento. Un clúster de varios nodos también presenta desafíos y desventajas, como la complejidad, la sobrecarga, el costo y la eficiencia. Por ejemplo, la configuración y el mantenimiento de un clúster de varios nodos requiere conocimientos, aptitudes, herramientas y recursos adicionales (red, almacenamiento, proceso). El clúster debe controlar la coordinación y la comunicación entre los nodos, lo que conduce a posibles latencias y errores. Además, la ejecución de un clúster de varios nodos consume más recursos y es más rentable que un clúster de un solo nodo. La optimización del uso de recursos entre nodos es fundamental para mantener la eficiencia y el rendimiento de las aplicaciones y del clúster.
En resumen, un clúster de Kubernetes de un solo nodo podría ser adecuado para entornos de desarrollo, pruebas y limitados por recursos. Un clúster de varios nodos es más adecuado para implementaciones de producción, alta disponibilidad, escalabilidad y escenarios en los que las aplicaciones distribuidas son un requisito. Esta elección depende en última instancia de sus necesidades y objetivos específicos para la implementación.
Requisitos mínimos de hardware
Clúster de un solo nodo o 2 nodos
- Máquina virtual recomendada: Standard_D8ds_v5
- Especificaciones equivalentes por nodo:
- 4 CPU
- 16 GB de RAM
Clúster con varios nodos
- Máquina virtual recomendada: Standard_D8as_v5
- Especificaciones equivalentes por nodo:
- 8 CPU
- 32 GB de RAM
32 GB de RAM sirven como búfer; sin embargo, 16 GB de RAM deberían ser suficientes. Las configuraciones de Edge Essentials requieren 8 CPU con 10 GB de RAM por nodo, lo que hace que 16 GB de RAM sea el requisito mínimo.
Requisitos mínimos de almacenamiento
Requisitos de volúmenes perimetrales
Cuando se usa la opción de almacenamiento tolerante a errores, los volúmenes perimetrales asignan espacio en disco fuera de un grupo de almacenamiento tolerante a errores, que se compone del almacenamiento exportado por cada nodo del clúster.
El grupo de almacenamiento está configurado para usar la replicación de tres vías para garantizar la tolerancia a errores. Cuando se aprovisiona un volumen perimetral, se asigna espacio en disco del grupo de almacenamiento, y se asigna almacenamiento en tres de las réplicas.
Por ejemplo, en un clúster de tres nodos con 20 GB de espacio en disco por nodo, el clúster tiene un grupo de almacenamiento de 60 GB. Sin embargo, debido a la replicación, tiene un tamaño de almacenamiento efectivo de 20 GB.
Cuando se aprovisiona un volumen perimetral con un tamaño solicitado de 10 GB, asigna un volumen del sistema reservado (de tamaño estático a 1 GB) y un volumen de datos (con el tamaño del volumen solicitado, por ejemplo, 10 GB). El volumen del sistema reservado consume 3 GB (3 x 1 GB) de espacio en disco en el grupo de almacenamiento y el volumen de datos consume 30 GB (3 x 10 GB) de espacio en disco en el grupo de almacenamiento, para un total de 33 GB.
Requisitos de volúmenes de caché
Los volúmenes de caché requieren al menos 4 GB por nodo de almacenamiento. Por ejemplo, si tiene un clúster de tres nodos, necesita al menos 12 GB de almacenamiento.