Ediciones ENI Editorial | líder en informática
Escalado automático
Objetivos del capítulo y requisitos previos
Hasta ahora, las aplicaciones desplegadas se iniciaban con un solo pod y el cambio a varios se realizaba manualmente, usando el comando kubectl scale. También se han abordado los mecanismos de no afinidad durante la configuración de los controladores Ingress (Nginx y Traefik) para aumentar la resiliencia del sistema.
Para gestionar la redundancia de una aplicación o de un pequeño número de servicios, estos mecanismos son suficientes. Por otro lado, en un contexto un poco más dinámico, esta gestión se puede volver problemática rápidamente.
El propósito de este capítulo es presentar el escalado horizontal (Horizontal Pod Autoscaler) y los requisitos previos necesarios para su correcta implementación (metrics-server y asignación de recursos).
Otro aspecto que se discutirá es el establecimiento de grupos de máquinas con diferentes funciones: presencia de GPU, ratio memoria/CPU. El lector también abordará la noción de las llamadas instancias «Spot», para ahorrar cuando sea posible.
El servidor de métricas
1. Presentación del componente metrics-server
La función del servidor de métricas es recopilar el consumo de los diferentes elementos de un clúster de Kubernetes para que estén disponibles.
Este servidor va a escanear la actividad de dos tipos de elementos: pods y nodos de clúster. Las métricas recuperadas serán las relacionadas con el consumo de CPU y memoria.
2. Activar el servidor de métricas
a. Verificar la presencia del servidor de métricas
El servidor de métricas tiene la etiqueta k8s-app=metrics-server y se inicia en el espacio de nombres kube-system.
Verifique su presencia usando el siguiente comando:
$ kubectl -n kube-system get pods -l k8s-app=metrics-server En algunos casos, la etiqueta que hay que verificar será app=metrics-server. Si el comando no devuelve nada con la etiqueta k8s-app, haga la misma prueba con la etiqueta app=metrics-server.
Si el servidor está presente (que seguramente será el caso de los clústeres gestionados), el comando devolverá el siguiente resultado:
NAME READY STATUS RESTARTS AGE
metrics-server-77fddcc-95crc 1/1 Running 0 6m7s...Activar el autoscaling
1. Prueba con la aplicación MailHog
El servidor de métricas está implementado y le permite consultar el consumo de los componentes básicos del clúster (nodos y pods). Sin embargo, este no es el único punto importante que debe tenerse en cuenta.
De hecho, el autoscaling requiere definir la capacidad de los pods. Además, esta limitación permite evitar el consumo descontrolado de recursos e indicar cuándo se activará un aumento o disminución en el número de pods.
Las pruebas de carga se realizarán mediante la aplicación MailHog. Para simplificar las cosas tanto como sea posible, la persistencia de datos no estará activa. En cuanto a la capacidad de cada pod, estos tendrán 10 milésimas de CPU (10m) reservadas y la misma cantidad como máximo.
Para determinar mejor los valores que se deben usar para iniciar un pod, es necesario configurar una herramienta para supervisar el consumo de recursos del sistema. No dude en consultar el capítulo sobre la supervisión con Prometheus.
A continuación, se muestra el archivo de despliegue que se utilizará para las pruebas:
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: mailhog
name: mailhog
spec:
selector:
matchLabels:
app: mailhog
template:
metadata:
labels:
app: mailhog
spec:
containers:
- image: mailhog/mailhog
name: mailhog
resources:
requests:
memory: "64Mi"
cpu: "10m"
limits:
memory: "64Mi"
cpu: "10m" Esta declaración está...
Escalabilidad de los nodos de un clúster
1. Contexto
Se ha abordado el escalado automático de un despliegue. Por otro lado, en caso de saturación de un nodo, el administrador debe intervenir para aumentar la capacidad de procesamiento del clúster agregando nuevas máquinas.
En el caso de un clúster interno, desafortunadamente no hay soluciones milagrosas: será necesario crear una nueva máquina e integrarla usando Kubespray.
Por otro lado, para un clúster gestionado, es bastante posible crear (o eliminar) automáticamente los nodos a demanda.
2. Presentación de Autoscaler
El autoscaler es un servicio de Kubernetes que supervisa el estado de las nuevas peticiones de pods para determinar si se crean o no nuevos nodos. Los pods en estado Pending (debido a un déficit de memoria o CPU) se encuentran dentro de estos criterios.
A continuación, hay un ejemplo de un evento asociado con un pod que indica un déficit de CPU:
0/3 nodes are available: 3 Insufficient cpu. 3. Activar autoscaler con Google Cloud
Para recuperar clústeres existentes, use el siguiente comando:
$ gcloud container clusters list El comando devolverá las características de los clústeres existentes, así como sus regiones.
En Google, la activación del autoscaler se puede realizar desde la interfaz web o desde la línea de comandos con gcloud. Este comando recibe como argumentos las siguientes opciones:
-
Las instrucciones containers clusters update seguidas del nombre del clúster.
-
Las opciones de activación del autoscaling (--enable-autoscaling).
-
El número mínimo/máximo de nodos (--min-nodes y --max-nodes).
-
La región que se va a usar para lanzar los nodos (--region).
Para permitir que el autoscaler de clústeres eni-test tenga de 1 a 5 nodos como máximo en la región europe-west3-c, ejecute el siguiente comando:
$ gcloud container clusters update eni-test \
--enable-autoscaling --min-nodes=1 --max-nodes=5 \
--region europe-west3-c 4. Activar autoscaler con Azure AKS
El mecanismo de escalado de AKS se basa en el servicio Azure VMSS (por Virtual Machine Scale Set). Para controlar este mecanismo, utilice el comando az acompañado de las siguientes opciones:
-
Activar la opción...
Definir grupos de máquinas
1. Contexto
Hasta ahora, el usuario siempre ha utilizado grupos uniformes de máquinas:
-
Misma cantidad de memoria.
-
Mismo número de CPU.
Además de estas características, pueden entrar en juego otros criterios:
-
Querer separar tipos de cargas de aplicación (base de datos, servidores web).
-
Usar máquinas con diferentes ratios CPU/memoria.
-
Usar la GPU para el cálculo vectorial.
-
Reducir su factura usando nodos de disponibilidad no garantizada (instancia Spot).
Todas estas razones pueden llevar al administrador a separar los diferentes tipos de carga en diferentes grupos de máquinas.
2. Los diferentes tipos de máquina
a. Las máquinas preferentes (Spot)
En el lenguaje de los proveedores informáticos en la nube, una instancia Spot hace referencia a máquinas disponibles a precios bajos, pero con disponibilidad no garantizada o a un coste variable.
La diferencia en el coste puede ser importante (generalmente, un factor de tres o cuatro o incluso mucho más alto; ciertos tipos de máquinas pueden tener bonificaciones aplicadas en un 90 %). La contrapartida es que estas máquinas pueden ser retiradas muy rápidamente por el proveedor de la nube o estar sujetas a subasta.
Esta diferencia de costes se explica muy fácilmente: para absorber los picos de carga, el proveedor tiene una capacidad de procesamiento muy grande. Fuera de estos períodos, estas reservas de potencia están infrautilizadas: es posible utilizarlas a bajo coste.
Un caso de uso típico para este tipo de máquina se puede imaginar durante el procesamiento pesado en los períodos de baja actividad (por la noche, durante las vacaciones de verano, fuera de los períodos de rebaja, etc.). Solo falta tener una aplicación compatible con este modo de funcionamiento. Por ejemplo, es preferible que las aplicaciones soporten fallos, paradas no planificadas o retrasos en el procesamiento.
Tenga en cuenta que este tipo de máquinas existe en AWS, Azure y Google.
Por parte de OVH, este tipo de oferta no existe. Sin embargo, los costes de este proveedor son más bajos que los demás. La ausencia de este servicio no plantea ningún problema en realidad.
b. Reservar instancias
Estos aspectos de facturación se basan en cifras de catálogos de proveedores disponibles para el público...