Skip to main content
Un grupo de instancias es una plantilla de lanzamiento más un recuento de destino. La plataforma mantiene ese número de instancias ejecutándose desde esa plantilla, reemplaza las que fallan y las distribuye entre los hosts. Es una primitiva para máquinas idénticas e intercambiables. Todo lo que hace se deriva de eso: las réplicas no pueden tener direcciones fijas, un cambio de plantilla no toca lo que ya está en ejecución, y un grupo es lo que hace que una dirección pública sea respondida por varias instancias a la vez.

Crear una agrupación

La plantilla de lanzamiento, los límites de tamaño y cómo se nombran las réplicas.

Dimensionamiento y curación

Lo que converge el grupo, lo que reemplaza y el contador para alertar.

Cambiar una plantilla

Por qué editar la plantilla no cambia nada, y qué hace una actualización.

Una dirección pública compartida

Anycast a través de las réplicas, y las formas en que no es un balanceador de carga.

​
Crear una agrupación

Vaya a Compute → Instance pools y elija Create instance pool. Después de Details viene una tarjeta Scaling con Min, Desired y Max; el resto del formulario es la plantilla de lanzamiento, tarjeta por tarjeta, igual que la creación de una instancia: Flavor, Image, Boot volume, Data volumes, Networking, IAM role, User data.Min es el piso y Max es el techo. Puedes cambiar ambos más tarde con Scale.Los dos mapas de etiquetas a continuación se llaman así por la diferencia entre ellos: Instance tags se estampan en cada réplica que lanza el grupo, mientras que Pool tags etiquetan el grupo en sí y no llegan a ninguna de sus instancias.
En las peticiones de creación y reemplazo, template es la configuración de inicio, en la misma forma que toma una instancia independiente create — mismos nombres de campo, mismos tipos, mismos significados. No hay un recurso de plantilla de lanzamiento separado para crear, publicar o compartir; la plantilla pertenece al grupo. Se requieren un flavor y una subred primaria: template.flavor y template.networks[0].subnet. El índice 0 es la NIC principal; el resto son extras.
Una plantilla no puede llevar una dirección fija dentro de addresses o un mac fijo. Cada réplica se inicia desde la misma plantilla, por lo que una dirección fija haría que la segunda réplica pidiera una que la primera ya tenga. Ambos son rechazados con un 400 en lugar de ser abandonados en silencio.

​
Referencias y respuestas de roles de IAM

Las solicitudes de creación y reemplazo aceptan template.iam_role como un UUID, CRN o cadena de nombre exacto para un rol en tu cuenta. Adjuntar el rol requiere iam:PassRole y autorización de confianza de instancia; consulte Roles e identidad de instancia. Las respuestas de la agrupación devuelven un resumen de rol opcional dentro de template, en lugar de iam_role_id. Este extracto de respuesta muestra la identidad del archivo adjunto:
El resumen contiene solo id, crn y name y es visible con acceso de lectura de la agrupación, sin iam:GetRole. Excluye los campos de rol confidenciales, como las políticas. template.iam_role se omite cuando no hay ningún rol adjunto, el rol se ha eliminado o pertenece a otra cuenta. La apertura de los detalles de IAM del rol todavía requiere iam:GetRole.

​
Referencias y respuestas de subred

Las solicitudes de creación y reemplazo toman template.networks[].subnet como una cadena: un UUID o un CRN completo de VPC/subred. Un nombre de subred sin más no es suficiente, porque los nombres de subred solo son únicos dentro de su VPC. Las respuestas de grupo incrustan toda la subred en cada NIC de plantilla, en lugar del anterior subnet_id. La incrustación lleva la VPC principal y el resumen de la tabla de rutas nullable descrito en ubicación de subred:
Por lo tanto, subnet.name y subnet.vpc.name son legibles directamente desde el grupo; no se necesita ninguna subred o VPC separada para mostrar dónde aterrizan las réplicas. En el SDK de Go estos son nic.Subnet y nic.Subnet.VPC. subnet es null cuando la subred referenciada ya no se resuelve, como una subred eliminada después de que se almacenó la plantilla. Trate esto como una ubicación no disponible en lugar de “sin subred”: muéstrelo como no disponible y actualícelo antes de actuar sobre él. La plantilla todavía nombra una subred en la que el grupo no puede iniciarse, por lo que el siguiente reemplazo que lanza falla.
Nunca devuelva el objeto incrustado. Las solicitudes toman una cadena, por lo que un reemplazo construido a partir de una respuesta tiene que convertir la subnet de cada NIC a su id o crn — vea Cambiar la plantilla. Una subnet nulo no tiene referencia para copiar: suministre una válida antes de la PATCH, o la ubicación de las tiendas de reemplazo que el pool no puede usar.

​
La imagen se resuelve una vez

template.image toma las mismas tres formas que instance create — un id, name:version, o un name desnudo. A diferencia de la creación de instancias, la referencia se resuelve una vez, cuando se crea el grupo (o cuando se reemplaza la plantilla), y el id de imagen resultante es lo que arranca cada réplica, incluidos los reemplazos generados meses después. Eso es deliberado. Una etiqueta re-resuelta por réplica permitiría a un miembro curado arrancar una compilación más nueva que sus hermanos, y un grupo cuyos miembros no son idénticos es la premisa de la ruptura primitiva silenciosa. Para mover un grupo a una nueva compilación, cambie la plantilla y actualice.

​
Cómo se llaman las réplicas

Cada réplica recibe un número de secuencia, estable mientras tenga el espacio, y se llama <pool-name>-<sequence_num> — web-asg-0, web-asg-1, y así sucesivamente. Un reemplazo se hace cargo del número liberado. GET /v1/instance-pools/{pool_id}/instances Devoluciones completas Instance Los objetos en instances, más paginación metaCada objeto incluye su estado, direcciones, tipo de instancia, imagen y rol; no necesita una solicitud de instancia separada para cada miembro. Lee la secuencia de réplicas desde la lista de instancias de nivel superior. metadata["basalt:pool:sequence_num"]. Su valor es una cadena, incluyendo "0" para la primera ranura. Filtrar esta lista con name, crn, current_state, flavor o image. También acepta limit y marker. Mientras meta.has_more es true, solicita la siguiente página usando meta.marker como marker, manteniendo los mismos filtros y límites. Recoge instances de cada página para listar todos los miembros coincidentes.
Los nombres de instancia son únicos por cuenta, por lo que un grupo llamado web no puede coexistir con una instancia que ya hayas nombrado web-0. Los nombres de grupo son de 1 a 127 caracteres de letras, dígitos, punto, guion y subrayado, únicos por cuenta.

​
Discos y direcciones por réplica

template.volumes crea un disco con cada réplica y lo recupera con esa réplica. delete_on_termination es por defecto true; póngalo en false y una réplica escalada, reemplazada o destruida con el pool libera su volumen de nuevo a available en lugar de destruirlo. template.networks[0].floating_ip_assignment le da a cada réplica su propia IP flotante en su NIC principal, asignada a medida que el grupo se escala hacia afuera y liberada a medida que se escala hacia adentro. Una NIC en template.networks[] lleva su propia bandera, por lo que una interfaz secundaria puede ser la pública. Cada dirección cuenta contra su cuota floating_ips. Eso es algo diferente de la dirección compartida del grupo — Ver más abajo.

​
Dimensionamiento y convergencia

Los tres campos de dimensionamiento son enteros mutables. Los valores resultantes deben satisfacer 0 ≤ min_count ≤ desired_count ≤ max_count ≤ 100. En crear solamente, los límites omitidos por defecto a desired_count. En PATCH, los límites omitidos mantienen sus valores almacenados. Si omite desired_count, el objetivo actual se sujeta en los nuevos límites: elevar el mínimo por encima de él eleva el objetivo; bajar el máximo por debajo de él baja el objetivo. Un objetivo que ya está dentro de los límites no cambia. Si envía explícitamente desired_count, debe ajustarse a los límites resultantes. El tamaño no válido devuelve 400 sin aplicar ninguna parte de la actualización, incluidas las etiquetas o una plantilla enviada con ella. Cero es válido, incluyendo ambos límites en cero. El redimensionamiento no reemplaza la plantilla de lanzamiento ni solicita una actualización. Estos controles se aplican a los grupos administrados por el cliente. Los grupos de propiedad de un servicio administrado no se pueden redimensionar a través de la API de grupo de instancias; usa los controles de ese servicio.

​
Escalado automático

Una política de autoscaling ajusta desired_count dentro de los límites configurados. La misma política está disponible en load balancers. La creación o actualización de una directiva no cambia la plantilla de inicio. El seguimiento de objetivos de CPU requiere min_count de al menos 1.
Abre la agrupación y elige Scale. Establezca Minimum count, Maximum count y Desired count, y luego active Automatic scaling. Elija una Metric source y establezca su objetivo; para CPU, use Target CPU (%). Elija Scale para guardar. La pestaña Scaling muestra la política y las decisiones de escalado recientes.
El objetivo es la utilización de CPU como porcentaje de las vCPU asignadas de los miembros. Los miembros deben estar corriendo y haber pasado su período de calentamiento antes de que se evalúe la demanda. El escalado espera mientras la capacidad converge, los miembros se retiran o se está actualizando. También puedes escalar desde una métrica que publiques a Telemetry, como la profundidad de la cola. El propietario de la política necesita telemetry:ReadMetrics; ese permiso se comprueba de nuevo mientras se ejecuta la política. Solo son válidas las métricas de la cuenta y la región del grupo.
Una profundidad de cola de 750 con un objetivo de 100 trabajos por instancia recomienda ocho instancias, antes de aplicar límites y límites de paso. Las muestras se agregan dentro de cada serie primero, luego entre series. expected_series debe coincidir con el número de series seleccionadas; una serie faltante impide la escala. Las métricas de contador pueden usar sample_aggregation: "rate" para tener en cuenta los reajustes antes de que las tasas se combinen en las series. Publicar un cero nuevo cuando la cola está vacía. Los datos que faltan, están obsoletos o incompletos nunca significan cero y no pueden eliminar la capacidad. Las métricas de demanda personalizadas pueden hacer crecer un grupo desde cero; las políticas de CPU no pueden. Con varias métricas, la recomendación de capacidad válida más grande gana. Los datos que faltan aún permiten una recomendación de escalado válida de otra métrica. El calentamiento predeterminado es de 180 segundos, el tiempo de reutilización es de 60 segundos y la estabilización de reducción es de 300 segundos. Cada decisión añade como máximo cuatro instancias o elimina como máximo una. Estos límites y drain_seconds (por defecto 120) son configurables. El tiempo de enfriamiento y la estabilización permanecen en vigor durante los reinicios del servicio. Lea autoscaling_status.reason y autoscaling_status.history para la condición de espera actual y los cambios recientes de capacidad. Aún puedes cambiar el tamaño manualmente. La evaluación automática se reanuda después del tiempo de reutilización. Para detener los cambios automáticos, envíe la política con enabled: false; su configuración de métrica se conserva cuando se envía de vuelta. Las políticas se reemplazan en su totalidad, por lo que debe incluir la configuración de la métrica cuando inhabilite una. La escalabilidad inicial marca primero un miembro como retirado y lo retira de los conjuntos de backend del balanceador de carga y de las IP flotantes compartidas. La eliminación espera el acuse de recibo de retiro y el período de gracia de drenaje. Esto no invoca un gancho de cierre de aplicación; los trabajos de larga ejecución deben tolerar la terminación de la instancia. Las sesiones TCP, UDP y WebSocket de larga duración pueden terminar en el plazo de drenaje. Los cambios en la membresía de reenvío de IP flotante compartida también pueden cambiar la ubicación de la conexión durante la retirada.

​
Ajuste de los límites

La siguiente secuencia comienza con un mínimo de 2, el deseado 3 y el máximo 6. Eleva el objetivo a 4, lo baja a 2 y luego escala a cero. Escalar a cero retira a todos los miembros; sus discos siguen delete_on_termination.
Abra el grupo y elija Scale para abrir Scale instance pool. Establezca Minimum count en 4, mantenga Maximum count en 6 y deje Desired count sin cambios. Elija Scale; el objetivo se convierte en 4.Vuelva a abrir Scale, establezca Minimum count en 2 y Maximum count en 2, y deje Desired count sin cambios; el objetivo se convierte en 2. Para escalar a cero, vuelva a abrir el diálogo y establezca ambos límites en 0, de nuevo dejando Desired count sin cambios. La consola omite un valor deseado sin cambios para que la API pueda ajustarlo automáticamente.
Crear el grupo devuelve 201 inmediatamente. Las instancias son generadas por un reconciliador de fondo, que es también lo que converge el grupo hacia desired_count cada vez que lo cambias, así que observa el grupo en lugar de esperar miembros en la respuesta de creación. Cuatro contadores le dicen dónde se encuentra una agrupación, y confundir dos de ellos es la fuente habitual de una falsa alarma:
status: "active" significa member_count == desired_count — el grupo tiene los miembros que se le pidieron. No es una afirmación de que todos ellos están arriba. Un grupo puede ser active con live_count por debajo de desired_count cuando los miembros se han detenido. Lee live_count para la vivacidad.scaling significa que no mantiene su objetivo y está convergiendo: después de una creación, después de un cambio en desired_count, y durante la duración de una actualización. error significa un error de error activo — lea cada entrada en faults — y todavía está reconciliado: el grupo sigue siendo reintentado. deleting es un desmontaje en curso.
Los códigos de escalado (POOL_LAUNCH_FAILED, POOL_SCALE_OUT_FAILED, POOL_SCALE_IN_FAILED) se borran cuando el grupo alcanza su objetivo. Un cambio de tamaño posterior no los borra primero: un grupo que no pudo generarse y se está escalando de nuevo aún no ha demostrado que el error está detrás de él.

​
Qué se reemplaza y qué no

Cada paso, el grupo reemplaza cualquier miembro cuyo current_state es error o deleted, y cualquier enlace cuya instancia se ha eliminado de debajo de él. El reemplazo toma el número de secuencia liberado y se inicia desde la plantilla actual del grupo.
El grupo no realiza una comprobación de estado de nada dentro del invitado, y no reemplaza a un miembro que detuvo. Una réplica que es stopped, o que se ejecuta pero sirve errores, sigue siendo un miembro: live_count Cae para una parada, y nada cambia en absoluto para una aplicación en cuña.La sustitución se determina por el fallo de la instancia, no por el fallo de la carga de trabajo. Si necesitas una comprobación de estado a nivel de aplicación, pon un balanceador de carga al frente.
Escalar elimina los números de secuencia más altos primero, por lo que una escala de 5 a 3 retira -4 y -3. Cada retiro ejecuta la eliminación de instancia completa, por lo que su cuota, sus volúmenes y sus direcciones se manejan exactamente como para una instancia independiente. Las réplicas se distribuyen entre los hosts: mejor esfuerzo. Cada nueva réplica evita los hosts que sus hermanos ya ocupan, pero cuando la flota no tiene espacio, la propagación se elimina en lugar de que el lanzamiento falle, por lo que las réplicas pueden terminar compartiendo un host.

​
Cambiar la plantilla

PATCH /v1/instance-pools/{pool_id} cambia desired_count, min_count, max_count, autoscaling, las tags del pool, la template, o cualquier combinación. Cada campo es opcional; el envío de ninguno de ellos es un 400 en lugar de un silencioso no-op.
La pestaña Settings del grupo edita tres partes del mismo: Tags en el grupo y Instance tags y Instance metadata en la plantilla de lanzamiento. Minimum count, Maximum count y Desired count están bajo Scale en el encabezado.
El resto de la plantilla es solo API. No hay control de consola para el tipo de instancia de la plantilla, imagen, volumen de arranque, red, claves SSH, rol IAM o datos de usuario — la página del grupo muestra estos como detalles de solo lectura, y cambiar cualquiera de ellos es un PATCH.
Debido a que el PATCH reemplaza la plantilla por completo, al guardar cualquiera de las dos tarjetas de plantilla se reenvía toda la configuración almacenada: la consola convierte la subred integrada de cada NIC de nuevo a su ID para que no se pierda ninguna interfaz. Si la subred de cualquier NIC no se resuelve, informa a la interfaz y no envía nada, en lugar de guardar una plantilla corta de una NIC.
Una nueva template reemplaza la almacenada por completo. Cualquier cosa que se omita se borra, no se mantiene — reemplazo en lugar de una fusión profunda, por lo que un array networks o volumes más corto no puede ser leído como una truncado y silenciosamente soltar una interfaz o un disco. Envía toda la configuración que quieras.
Cuando se construye un reemplazo a partir de una respuesta de grupo, convierta el resumen de rol a una referencia de cadena: por ejemplo, establezca template.iam_role al id o crn del resumen. No devuelva el objeto de resumen. Omitir iam_role de un reemplazo borra el adjunto para futuros lanzamientos. De igual manera, convierta la subnet incrustada de cada NIC de respuesta a su cadena id o crn en la solicitud de reemplazo — vea referencias y respuestas de subred. Una subred nula necesita una referencia de reemplazo válida; no copie los objetos de respuesta directamente en la solicitud. Haga esto para cada entrada de networks, no solo la primaria: una NIC extra que se ha eliminado porque su subred no pudo convertirse es una interfaz sin la que se inicia la próxima réplica. Un cambio de plantilla decide lo que el grupo lanza a continuación. Las instancias que ya se están ejecutando mantienen lo que arrancaron, porque una máquina virtual en vivo no puede cambiar el tipo de instancia, el nivel, la subred o sus etiquetas en su lugar. Así que entre la edición y un roll, el grupo tiene legítimamente miembros de dos plantillas diferentes. stale_instance_count es cuántas instancias hay en la más antigua, y un valor diferente a cero es la señal de que un cambio de plantilla aún no se ha implementado.
Esta es la misma división entre “editar la plantilla” y “reemplazar las instancias” que un PATCH que reemplaza silenciosamente a cada miembro en ejecución borraría — una operación destructiva que lleva la forma de una edición.

​
Rodando la agrupación

  1. Abra Instance pools y seleccione su grupo.
  2. Elija Roll instances junto a Scale.
  3. Confirme el reemplazo de cada miembro en ejecución en una plantilla antigua o desconocida. Los miembros de la plantilla actual se conservan. Sin margen de sobrecarga, el rollo espera; use Scale para aumentar Maximum count por encima de Desired count (hasta 100).
  4. Observa Roll in progress e Stale instances. Un conteo de cero no significa que el rollo haya terminado mientras que Roll in progress permanece.
Refresh recarga los datos de la página. No se rotan instancias.
Responde 202 con el grupo tal como está, y reemplaza todos los miembros no lanzados desde la plantilla actual, incluyendo cualquiera que sea anterior al seguimiento de plantillas. Asíncrono, y deliberadamente así: cada reemplazo es un arranque de VM, y una solicitud que esperaba se agotaría mucho antes de que un grupo de cualquier tamaño terminara.
1

Un miembro por pase

El conciliador retira a un miembro obsoleto a la vez, el más antiguo primero, de modo que el rollo recorre el grupo en un orden predecible.
2

Y solo una vez que la agrupación está entera

La próxima retirada espera hasta que el grupo esté por encima del tamaño deseado con todos los miembros en ejecución. Una plantilla que no arranca, por lo tanto, detiene el rollo con el grupo intacto, en lugar de bajarlo una instancia a la vez.
3

La capacidad no se hunde

Con el margen de maniobra, el grupo lanza una instancia sobre su objetivo, por lo que un reemplazo ya está en servicio antes de que se retire cualquier cosa. desired_count no se toca — el aumento se deriva, no se escribe en lo que usted pidió.
Cuando max_count == desired_count, una actualización espera en lugar de retirar un miembro obsoleto por debajo de la capacidad deseada. Esto también se aplica si una actualización de límites elimina el espacio libre durante un lanzamiento. El escalamiento y la curación normales continúan; la reducción deseada todavía puede retirar a los miembros como parte del escalamiento.Aumenta max_count por encima de desired_count para permitir que continúe la actualización gradual. Por ejemplo, con un valor deseado de 3 y un máximo de 3, aumenta el máximo a 4 y deja el valor deseado sin cambios mediante los controles de tamaño. La actualización en espera se reanuda automáticamente. Al alcanzar el límite de 100 de la plataforma, añadir capacidad libre requiere reducir primero el valor deseado, lo que reduce la capacidad solicitada.
Observe refresh_in_progress y stale_instance_count para el progreso del rollo, y member_count y live_count para la capacidad. Un conteo de cero obsoletos solo significa que ningún miembro usa una plantilla antigua. Después de que se borre el indicador de actualización, es posible que el grupo aún necesite quitar su miembro de aumento y converger al deseado. Espere a que la bandera sea false, status: "active", y ambos conteos sean iguales antes de tratar la capacidad como liquidada. Si se vuelve a preguntar mientras se está ejecutando un rollo, se acepta y no se reinicia.

​
Dos conjuntos de etiquetas

Un grupo lleva dos mapas de etiquetas y responden a preguntas diferentes.

tags

Etiqueta el recurso de grupo. Leído por las condiciones de IAM como basalt:ResourceTag/<key> y utilizado para la atribución de costos. Toma efecto inmediatamente, no toca ninguna instancia y reemplaza todo el conjunto — un objeto vacío los borra, un campo omitido los deja solos.

Etiquetas de template.tags

Estampado en cada réplica de la agrupación lanza. Parte de la configuración de lanzamiento, por lo que cambiarlo afecta solo a lanzamientos futuros y necesita una actualización para alcanzar lo que ya está en ejecución.
Editar template.tags solo es la forma más fácil de terminar con un grupo cuyos miembros llevan dos conjuntos de etiquetas diferentes, lo que importa si una política de IAM o un informe de costos tiene claves en ellos. stale_instance_count es cuántas instancias aún están en el conjunto antiguo.

​
Una dirección para toda la agrupación

POST /v1/instance-pools/{pool_id}/floating-ips vincula una IP flotante que ya ha asignado al grupo. Una IP pública, respondida por cada réplica — una dirección anycast — en oposición a template.networks[0].floating_ip_assignment, que da a cada réplica la suya propia.
La pestaña Floating IPs del grupo muestra sus direcciones compartidas y ofrece Attach floating IP, que selecciona las direcciones que tienes que no están adjuntas a nada.One address, every replica explica la membresía y la preparación. Las columnas Members, Healthy, Unhealthy y Unknown health distinguen la membresía de la elegibilidad de tráfico. Un grupo vacío conserva la propiedad de sus direcciones compartidas.
El attached_to de la IP flotante nombra el CRN canónico del grupo, incluso cuando members está vacío. Todas las réplicas activas pueden convertirse en miembros, incluidas las réplicas del mismo host. Lea la interfaz embebida y los resúmenes de instancia en members para identificarlos; vea Leyendo los enlaces. La membresía se mantiene para usted: un miembro de escalada se une, un miembro de escalada se va, un miembro reemplazado se intercambia. No hay que realizar ningún acoplamiento por réplica, y los propios acoplamiento y desconectado del servicio de red se rechazan en la dirección de un grupo; use estos dos extremos.

​
No es un balanceador de carga

Con más de un miembro, el borde de la región elige un miembro por conexión, mediante el hash de las direcciones y puertos del flujo, y cada paquete de esa conexión va a la misma. Eso extiende las conexiones a través de instancias independientes y sobrevive a la pérdida de un host.
Sin una IP flotante configurada health_check, el estado indica la actividad del invitado, no la preparación de la aplicación. Los miembros de arranque permanecen en la lista como no activos y no reciben tráfico hasta que se admiten; las imágenes que nunca se comunican con el servicio de metadatos de instancia se admiten después de unos minutos. Configure una comprobación de preparación si el tráfico debe esperar a su aplicación. Los miembros no saludables no reciben tráfico, y si todos fallan la dirección se oscurece.Las conexiones en curso a un miembro que se va terminan. No hay terminación TLS, enrutamiento de solicitudes ni manera de ponderar a los miembros.

​
Requisitos y retiro

La IP flotante debe ser unattached (attached_to: null) y suya, y la subred del grupo debe ya enrutar 0.0.0.0/0 a una puerta de enlace de internet. La adjunción es idempotente: volver a adjuntar la misma dirección al mismo grupo la devuelve sin cambios. Un 409 significa que la dirección ya está adjunta a algo, o ya pertenece a otro grupo. DELETE /v1/instance-pools/{pool_id}/floating-ips/{floating_ip_id} detiene el enrutamiento de la dirección al grupo. En la consola es la acción de fila en la pestaña Floating IPs, confirmada como Detach floating IP.
La dirección no se libera. La asignaste, permanece tuya y no adjunta, para reutilizarla o liberarla con DELETE /v1/floating-ips/{floating_ip_id}. Desconectar uno del grupo no contiene respuestas 204.
GET /v1/instance-pools/{pool_id}/floating-ips lista las direcciones compartidas con sus miembros actuales en floating_ips, más paginación meta, usando la misma forma de respuesta que la lista de IP flotante de nivel superior. Acepta name, crn, limit y marker. Las IP flotantes no tienen nombre, por lo que si se proporciona name se devuelve una lista vacía. Mientras meta.has_more es true, pasa meta.marker como marker en la siguiente solicitud, preservando los filtros y el límite, y recolecta floating_ips de cada página. Las direcciones por réplica no están aquí, pertenecen a la réplica y se leen desde la lista de NIC de la instancia.

​
Eliminar un grupo

Delete pool está en la pestaña Settings de la agrupación, en la zona de peligro. La confirmación reitera el costo (termina todas las máquinas virtuales del grupo) y necesita que se escriba de nuevo el nombre del grupo.
Derriba todas las instancias que posee el pool y deja caer el pool. Es idempotente, y responde 204. Eliminar el grupo es la única forma de eliminar sus miembros: eliminar una réplica directamente solo libera su número de secuencia, y el grupo genera un reemplazo para ella en la siguiente pasada.

​
Permisos

Cada operación de grupo autoriza contra crn:compute:<region>:<account>:instance-pool/<name>, que es el valor que una declaración de política de IAM debe nombrar para ampliar un permiso a un grupo.
Una actualización autoriza como compute:UpdateInstancePool, la misma acción que un PATCH, no como una acción propia. Por lo tanto, otorgar a alguien la capacidad de editar un grupo también le otorga la capacidad de rodarlo, lo que reemplaza a todos los miembros en ejecución.
Las réplicas se lanzan como el principal que creó el grupo, de modo que el permiso compute:CreateInstance del principal — y su iam:PassRole en template.iam_role, si la plantilla tiene uno — es lo que se ejecuta bajo cada curación y escalado posterior. Consulte policies y roles.

​
Solución de problemas

active significa member_count == desired_count, no que los miembros estén activos. Lee live_count. Un espacio entre ellos son los miembros que existen y no se están ejecutando (detenidos, todavía arrancando o enclavados) y el grupo no reemplaza a un miembro detenido.
Primero compara max_count con desired_count. Si no hay espacio libre para sobretensiones, aumente el máximo por encima del deseado (hasta 100). La actualización permanece solicitada y se reanuda sin otra llamada de actualización. Los cambios de límites durante una actualización pueden ponerlo en este estado de espera; el escalado normal continúa.Con espacio libre, el rollo espera un reemplazo por encima del deseado con cada miembro corriendo antes de retirar al siguiente. Si la nueva plantilla no arranca, el rollo se detiene allí por diseño en lugar de vaciar el grupo — compruebe los faults de la réplica más reciente y su salida de consola.stale_instance_count deja de caer tan pronto como eso sucede, y refresh_in_progress permanece verdadero.
Se esperaba. Cuando se construye un reemplazo a partir de una respuesta de grupo, convierta el resumen de rol a una referencia de cadena: por ejemplo, establezca template.iam_role al id o crn del resumen. No devuelva el objeto de resumen. Omitir iam_role de un reemplazo borra el adjunto para futuros lanzamientos.Un cambio de plantilla decide qué lanza el grupo a continuación; las instancias que ya se están ejecutando mantienen lo que arrancaron. stale_instance_count los cuenta, y POST /v1/instance-pools/{pool_id}/refresh los actualiza.
template en un PATCH reemplaza por completo la configuración almacenada: se borra todo lo que se omita. Vuelve a leer el pool y prepara la solicitud completa de reemplazo, convirtiendo el resumen del rol en una referencia de cadena, como se describe en Cambiar la plantilla.
Compare las réplicas en vivo del grupo con los resúmenes de miembros incrustados de la dirección. La membresía converge a medida que se colocan y eliminan réplicas; los miembros pueden compartir un host. Compruebe la health y la reason de cada miembro por separado: los miembros que arrancan o fallan permanecen en la lista pero no reciben tráfico. Una lista de miembros vacía no borra la propiedad attached_to del grupo.
Tres causas, y el mensaje dice cuál: el id falta o está mal formado; la subred del grupo no tiene ruta predeterminada a una puerta de enlace de Internet; o la región no tiene direcciones de grupo compartidas activadas. Un 409 es diferente — es una dirección ya adjunta a otra cosa, o ya poseída por otro grupo.
El grupo converge hacia desired_count, por lo que la eliminación de un miembro se lee como deriva y se rellena en el número de secuencia liberado. Baja desired_count, o elimina el grupo.
Utilice números enteros con 0 ≤ min_count ≤ max_count ≤ 100. Un desired_count explícito debe caer dentro de esos límites. Al crear, los límites omitidos se establecen por defecto en los deseados; al actualizar, conservan los límites almacenados. Omita lo deseado en la actualización para sujetarlo automáticamente. El tamaño no válido no aplica ninguna de las actualizaciones. Para crecer más allá del máximo original, aumente max_count antes o junto con desired.

​
Siguiente

Instancias

Todo lo que es una réplica: tipos de instancia, imágenes, discos, interfaces y el ciclo de vida.

Imágenes

Fijar una compilación para que las réplicas de un grupo permanezcan idénticas.