> ## Documentation Index > Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt > Use this file to discover all available pages before exploring further. # Balanceadores de carga > Balanceadores de carga administrados: escuchas, reglas de enrutamiento, grupos de destino, comprobaciones de estado y las réplicas que sirven su tráfico. Los ejemplos de cliente utilizan CLI v0.24.0 y Go SDK v0.28.0. Consulte [Configuración de CLI](/es/cli) y [Configuración de Go](/es/reference-resolution#released-go-sdk). Los fragmentos de Go asumen un `cfg` configurado, un `ctx` de `context.Background()`, e importaciones para `log`, `basaltic` (`github.com/basaltic-sh/sdk-go`) y `loadbalancer` (`github.com/basaltic-sh/sdk-go/loadbalancer`). `LOAD_BALANCER_ID`, `LISTENER_ID` y `TARGET_GROUP_ID` (y sus equivalentes en Go) son UUIDs devueltos. Vea [Resource references](/es/reference-resolution) para los tipos de referencia aceptados, los ámbitos de búsqueda, las identidades canónicas y los filtros de lista exacta. Vea [Resource faults](/es/resource-faults) para el array `faults` activo. Un balanceador de carga acepta conexiones en uno o más oyentes y las reenvía a un grupo objetivo. Se ejecuta en instancias de cómputo que la plataforma opera para usted (las **réplicas**) dentro de su propia subred VPC, por lo que llega a sus backends a través de direcciones privadas. Una IP flotante pública proporciona su dirección de Internet. Las direcciones IPv6 nativas de réplica no pueden aceptar nuevas conexiones desde fuera de la VPC; use las direcciones de equilibrador de carga regidas por [exposure](#exposure). El servicio es **regional**: `https://loadbalancer.sa-saopaulo-1.basaltic.sh`. Capa 7. Hosts `http` y `https` oyentes, rutas en el host, ruta, encabezado, consulta y método, y termina TLS. Capa 4. Alberga escuchas `tcp` y `udp` y reenvía flujos a un único grupo objetivo. `type` se fija en crear. No hay parche que convierta uno en el otro: cree un segundo balanceador de carga y mueva la dirección. La subred, la familia de tipos de instancia y el requisito del grupo de seguridad que hace tropezar a las personas. El VIP privado, la IP flotante que solo puede elegir en crear, y el nombre de host al que apunta un nombre. Protocolos, exposición, certificados y cómo una solicitud elige un grupo objetivo. Objetivos, comprobaciones de estado, viscosidad y protocolo PROXY. Escala, el rollo de tipo de instancia de primera onda, y cómo verlo. Activo pero inalcanzable, objetivos atascados en `initial`, un redimensionamiento que se detiene. ## Crear un balanceador de carga Vaya a **Compute → Load Balancers** y elija **Create Load Balancer**. En **Load balancer details**, dale un **Name** y elige el **Type**: **Application** para la capa 7, **Network** para la capa 4. **Placement** toma el **VPC**, la **Subnet** de la que se reserva la IP virtual y los **Security groups** que hereda cada réplica. En **IP addresses**, elija la IP flotante privada y pública opcional para cada familia habilitada. Las direcciones privadas tienen el valor predeterminado **Automatic — allocate from this subnet**; las direcciones públicas tienen el valor predeterminado **None**. Elija un **Flavor** (la lista ya está filtrada para la familia de balanceadores de carga) y, a continuación, establezca **Minimum count**, **Maximum count** y **Desired count** en **Scale**. Habilite **Automatic scaling** para configurar los objetivos de métrica. Un balanceador de carga sin una IP flotante pública permanece interno — ver el artículo sobre el balanceador de carga. [Cómo obtiene su dirección](#how-a-load-balancer-gets-its-address). Cada lista flotante de IP ofrece solo direcciones elegibles que no están unidas a nada. Asigna una en **Networking → Floating IPs** primero si está vacía. ```bash theme={null} POST https://loadbalancer.sa-saopaulo-1.basaltic.sh/v1/load-balancers { "name": "web-lb", "type": "application", "vpc": "c3d4e5f6-a7b8-4901-c2d3-e4f5a6b7c8d9", "subnet": "d4e5f6a7-b8c9-4012-d3e4-f5a6b7c8d9e0", "flavor": "e5f6a7b8-c9d0-4123-e4f5-a6b7c8d9e0f1", "security_groups": ["d1b6f3a8-4c2e-4a9d-8f7b-1e5c3a2d9b4f"], "min_count": 2, "max_count": 4, "desired_count": 2 } ``` ```bash theme={null} basaltic loadbalancer load-balancer create --name web-lb --type application \ --vpc c3d4e5f6-a7b8-4901-c2d3-e4f5a6b7c8d9 --subnet d4e5f6a7-b8c9-4012-d3e4-f5a6b7c8d9e0 \ --flavor e5f6a7b8-c9d0-4123-e4f5-a6b7c8d9e0f1 \ --security-groups d1b6f3a8-4c2e-4a9d-8f7b-1e5c3a2d9b4f --replica-count 2 ``` ```go theme={null} _, err := loadbalancer.New(cfg).CreateLoadBalancer(ctx, &loadbalancer.CreateLoadBalancerRequest{ Name: "web-lb", Type: "application", VPC: "c3d4e5f6-a7b8-4901-c2d3-e4f5a6b7c8d9", Subnet: "d4e5f6a7-b8c9-4012-d3e4-f5a6b7c8d9e0", Flavor: "e5f6a7b8-c9d0-4123-e4f5-a6b7c8d9e0f1", SecurityGroups: []string{"d1b6f3a8-4c2e-4a9d-8f7b-1e5c3a2d9b4f"}, ReplicaCount: basaltic.Int(2), }) if err != nil { log.Fatal(err) } ``` Las entradas de relación aceptan UUIDs, CRNs o nombres exactos inmutables. La VPC abarca los nombres de subred; los recursos a los que se hace referencia deben pertenecer a su cuenta en la misma región. Los tipos de instancia provienen del catálogo regional. Las IP flotantes solo aceptan UUID o CRN. Los puntos finales de la lista aceptan filtros exactos `name` y `crn`; un filtro vacío no selecciona filas, y los CRN mal formados devuelven un error de validación. Las réplicas heredan estos en cada NIC, y una NIC en ningún grupo de seguridad acepta nada. Un balanceador de carga sin uno seguiría aprovisionando, seguiría tomando una IP flotante y seguiría reportando `active`, mientras no responde a nadie. La creación se rechaza en su lugar. **El puerto de escucha debe estar abierto por un grupo de seguridad que se enumera aquí**, o el balanceador de carga es inalcanzable en él. Las réplicas son operadas por plataformas y tienen un precio en consecuencia, por lo que un tipo de instancia general o de base de datos se rechaza con la familia del tipo de instancia nombrada en el error. Las réplicas obtienen NICs aquí y la IP virtual se reserva fuera del rango de esta subred. Utilice `1 ≤ min_count ≤ desired_count ≤ max_count ≤ 10`. Desired por defecto es 1; los límites omitidos por defecto son desired. Escoge un mínimo de al menos 2 para HA. Deja espacio por debajo del máximo para un reemplazo de tipo de instancia. Consulte [escalación](#scaling). `replica_count` sigue siendo un alias obsoleto de `desired_count`. Si se envían ambos, sus valores deben coincidir. La CLI y el SDK de Go admiten límites independientes y políticas de escalado automático. Mantén el máximo por encima de la cantidad deseada para permitir sustituciones durante un cambio de tipo de instancia. La respuesta es **`201`** con el balanceador de carga en `provisioning`. Se cambia a `active` en la primera réplica cuyo proxy informa que está listo — las réplicas arrancan, instalan su software y extraen su configuración, así que espere unos minutos. Las réplicas ejecutan el software proxy propio de la plataforma. Se llega a un balanceador de carga a través de su dirección; no hay acceso SSH de inquilino a sus réplicas. ### Colocación de lectura atrás Una respuesta de balanceador de carga incrusta toda su `subnet`, en lugar de los campos `subnet_id` y `vpc_id` anteriores. La incrustación lleva la VPC principal y el resumen de la tabla de rutas nullable descrito en [ubicación de subred](/es/networking/subnets#reading-placement): ```json theme={null} { "load_balancer": { "subnet": { "id": "d4e5f6a7-b8c9-4012-d3e4-f5a6b7c8d9e0", "crn": "crn:network:sa-saopaulo-1:my-account:vpc/production/subnet/public", "name": "public", "cidr": "10.0.0.0/24", "vpc": { "id": "c3d4e5f6-a7b8-4901-c2d3-e4f5a6b7c8d9", "name": "production" }, "route_table": { "id": "…", "crn": "…", "name": "public-routes" } } } } ``` No hay un campo `vpc` separado: el VPC es `subnet.vpc`, por lo que `subnet.name` y `subnet.vpc.name` son ambos legibles desde el balanceador de carga sin una segunda lectura. Eso es lo que la descripción general de la consola enlaza. En el SDK de Go estos son `lb.Subnet` y `lb.Subnet.VPC`. `subnet` es **null** cuando la subred referenciada ya no se resuelve. Trate esto como una ubicación no disponible y actualice en lugar de como un balanceador de carga no ubicado: las réplicas y la IP virtual siguen estando donde estaban. En Go, compruebe `lb.Subnet != nil` antes de leer `lb.Subnet.VPC`. Create todavía toma `vpc` y `subnet` como referencias **string**, y `PATCH /v1/load-balancers/{id}` no toma ninguna de las dos — la ubicación es inmutable. Cuando copie la ubicación de una respuesta a otra solicitud (creando un segundo balanceador de carga o un clúster en la misma subred, por ejemplo), pase el `id` o `crn` de la subred incrustada, nunca el objeto. ## Cómo un balanceador de carga obtiene su dirección Un balanceador de carga utiliza IP flotantes para direcciones privadas y públicas. Al crearlo, `floating_ips` puede seleccionar una dirección por familia y visibilidad: IPv4 privado, IPv4 público, IPv6 privado e IPv6 público. Las direcciones privadas seleccionadas deben pertenecer a la subred del balanceador de carga. Cualquier familia privada que falte se asigna automáticamente cuando esa familia está habilitada en la subred. Las direcciones públicas son opcionales y deben seleccionarse explícitamente. ```json theme={null} { "floating_ips": [ "f6a7b8c9-d0e1-4234-f5a6-b7c8d9e0f1a2", "e2c19b77-7374-4793-a8ab-23e1b9cc0001" ] } ``` Utilice las IP flotantes libres existentes en la misma cuenta y región. La matriz `floating_ips` de la respuesta incluye sus identidades, familias, visibilidad y direcciones. `internal_ipv4`, `internal_ipv6`, y `public_ipv6` resumen las direcciones correspondientes cuando están presentes. Estas IP flotantes reenvían el tráfico de escucha a réplicas sanas; no son direcciones adicionales configuradas dentro de los invitados. En la consola, use la tarjeta **IP addresses** en **Create Load Balancer**. Cada selección privada tiene el valor predeterminado **Automatic — allocate from this subnet**, y cada selección pública tiene el valor predeterminado **None**. Las opciones disponibles siguen las familias y rutas habilitadas de la subred. Las IP flotantes privadas asignadas automáticamente pertenecen al balanceador de carga, están cubiertas por su cuota y se liberan cuando se elimina. Las direcciones existentes que proporcionó se separan y se conservan cuando se elimina. Ninguno de los dos tipos puede ser separado de forma independiente mientras el balanceador de carga lo posee. La selección de direcciones se fija en la creación. `PATCH /v1/load-balancers/{id}` no lo cambia. Para agregar exposición pública o reemplazar una dirección, cree un nuevo balanceador de carga con las IP flotantes necesarias y mueva el tráfico a él. La IPv4 pública requiere `0.0.0.0/0` a través de una puerta de enlace de Internet en la tabla de rutas de la subred; la IPv6 pública requiere `::/0` a través de una puerta de enlace de Internet y una subred habilitada para IPv6. Las puertas de enlace NAT y de solo salida no proporcionan exposición de escucha pública. Una subred ULA privada puede usar una IP flotante IPv6 pública: NAT66 la traduce a las direcciones de réplica. El campo `floating_ip` create sigue siendo una abreviatura de IPv4 público. No se puede combinar con `floating_ips`, y no asigna una dirección IPv6 pública. ### Señalando un nombre a ella La respuesta lleva `dns_name`, un nombre de host publicado para usted en una zona regional compartida, con la forma `{name}.{account}.lb..`. Se resuelve a la IP flotante en un balanceador de carga orientado a Internet y al VIP privado de lo contrario. Lee `dns_name` de la respuesta en lugar de ensamblarla. Está vacía en una región donde la zona de conveniencia no está configurada; la IP VIP y flotante permanecen autoritativas de cualquier manera. El nombre del balanceador de carga se fija después de la creación, por lo que las actualizaciones conservan su nombre de host. Para su propio dominio, publique un `CNAME` a `dns_name` — o un registro `A` a la IP flotante si necesita un apex — con [DNS](/es/dns). ## Listeners Un receptor vincula un protocolo y un puerto en el balanceador de carga. El par tiene que ser único — un segundo oyente en el mismo protocolo y puerto es rechazado — así que un balanceador de carga de red puede servir `tcp` y `udp` en el mismo número de puerto, pero nunca dos oyentes `tcp` en uno. Abra el balanceador de carga y elija **Add Listener**. La tarjeta **Listener** toma el **Protocol**, el **Port** y la **Exposure**; al elegir HTTP o HTTPS, el puerto se mueve al 80 o 443. **Routing** establece el **Default target group**. Un receptor HTTPS genera una tarjeta de certificados **TLS certificates**. Elija uno o más bajo **Certificates** — la consola nota que el primero que seleccione se convierte en el predeterminado y el resto son opciones SNI. La lista **Protocol** solo ofrece lo que acepta este tipo de balanceador de carga, por lo que la falta de coincidencia descrita a continuación no se puede hacer aquí. ```bash theme={null} POST /v1/load-balancers/{id}/listeners { "protocol": "https", "port": 443, "certificates": [{ "certificate": "crn:certificate::my-account:certificate/prod-web" }], "default_target_group": "b8c9d0e1-f2a3-4456-b7c8-d9e0f1a2b3c4" } ``` ```bash theme={null} basaltic loadbalancer listener create "$LOAD_BALANCER_ID" --protocol https --port 443 \ --certificates '[{"certificate":"crn:certificate::my-account:certificate/prod-web"}]' \ --default-target-group b8c9d0e1-f2a3-4456-b7c8-d9e0f1a2b3c4 ``` ```go theme={null} _, err := loadbalancer.New(cfg).CreateListener(ctx, loadBalancerID, &loadbalancer.CreateListenerRequest{ Protocol: "https", Port: 443, Certificates: []*loadbalancer.CreateListenerCertificate{{ Certificate: "crn:certificate::my-account:certificate/prod-web", }}, DefaultTargetGroup: basaltic.String("b8c9d0e1-f2a3-4456-b7c8-d9e0f1a2b3c4"), }) if err != nil { log.Fatal(err) } ``` | Balanceador de carga `type` | Aceptado `protocol` | | - | - | | `application` | `http`, `https` | | `network` | `tcp`, `udp` | Mezclarlos es rechazado en crear con la razón nombrada. Los valores de protocolo son en minúsculas, que es la convención de la plataforma para los enums que definimos; los valores que provienen de un estándar mantienen la propia mayúscula de ese estándar — un método HTTP en una condición de regla es `GET`, no `get`. ### Exposición `exposure` selecciona cuál de las direcciones IP flotantes del balanceador de carga reenvía el tráfico al receptor. La selección se aplica tanto a IPv4 como a IPv6. Se reenvían solo a través de las direcciones privadas del balanceador de carga. Se reenvían solo a través de las direcciones públicas del balanceador de carga. Se reenvía a través de las direcciones privadas y públicas. Los grupos de seguridad también deben permitir el puerto de escucha. Permitir un puerto en un grupo de seguridad no lo hace disponible a través de una dirección LB excluida por `exposure`. En subredes con GUA IPv6 enrutado, las réplicas administradas también tienen direcciones NIC nativas. Las nuevas conexiones desde fuera de la VPC a esas direcciones nativas se bloquean, incluso cuando un grupo de seguridad permite el puerto. Los clientes públicos deben usar una dirección de balanceador de carga pública. Las conexiones iniciadas por réplicas y sus respuestas siguen funcionando, al igual que el tráfico dentro de la VPC. Esta directiva se aplica a los balanceadores de carga públicos e internos; las NIC de instancia ordinaria mantienen la accesibilidad IPv6 nativa. La consola escribe las mismas tres opciones **Solo privado (VPC-VIP interno)**, **Público + privado** y **Solo público (IP flotante)** en el campo **Exposure** de **Add Listener**. El valor por defecto se adapta al balanceador de carga: `both` cuando lleva una IP flotante pública, `private_only` cuando no. Se rechaza la solicitud de `public_only` o `both` en un balanceador de carga sin IP flotante pública. La consola desactiva ambas opciones públicas en ese caso y dice **Exposición pública no disponible**. Un servidor de escucha `public_only` deja de ser servido por completo si la IP flotante desaparece — no tiene ninguna dirección que vincular. Un oyente `both` sigue sirviendo en privado. Parche `exposure` a `private_only` si querías mantenerlo interno. ### Certificados en un dispositivo de escucha HTTPS Un receptor HTTPS necesita al menos un certificado, nombrado **por CRN**. No se envía material de clave a esta API: el receptor almacena una referencia y las réplicas obtienen el material del [servicio de certificados](/es/certificates) bajo su propia identidad. Un receptor puede tener varios certificados y elige uno por conexión haciendo coincidir el SNI del cliente con las SAN de cada certificado. El marcado `is_default` es el fallback para un cliente cuyo SNI no coincide con nada, o que no envía nada en absoluto. ```bash theme={null} POST /v1/load-balancers/{id}/listeners/{listener_id}/certificates { "certificate": "crn:certificate::my-account:certificate/prod-web", "is_default": true } ``` Establecer un nuevo valor predeterminado degrada el anterior en la misma transacción, por lo que un receptor siempre tiene exactamente uno. Adjuntar y separar en un escuchador *en vivo* es *solo API*. La consola elige los certificados una vez, mientras está agregando el receptor; después la página del receptor los muestra como de solo lectura, marcando el predeterminado con una insignia `default`. Cambiar el conjunto — o promover un valor por defecto diferente — pasa por estas dos llamadas. La desconexión se rechaza en dos casos: al eliminar el certificado **último** de un dispositivo de escucha HTTPS y al eliminar el certificado **predeterminado actual** mientras que otros certificados aún están adjuntos. Promover un reemplazo primero, luego desprenderse. Un CRN de certificado termina en `certificate/`, por lo que la barra diagonal debe estar codificada en porcentaje como `%2F` cuando el CRN se encuentra en un segmento de ruta. Enviado en bruto, se dirige a una ruta diferente que no existe. ```bash theme={null} DELETE /v1/load-balancers/{id}/listeners/{listener_id}/certificates/crn:certificate::my-account:certificate%2Fprod-web ``` Los certificados que la plataforma renueva se recogen por sí mismos: una reemisión cambia la huella digital que las réplicas rastrean y vuelven a recuperar. Para forzar una nueva comprobación de un certificado ya adjunto, parche el receptor con su CRN. Adjuntar y desvincular también re-ámbito de acceso de las réplicas para que cubra exactamente los certificados actualmente adjuntos, y nada más. ### Grupo objetivo predeterminado `default_target_group` es donde va una solicitud cuando no hay ninguna regla que coincida. En un escuchador `tcp` o `udp` es el **único** destino — las reglas no se aplican en la capa 4 — así que un escuchador L4 sin uno no tiene adónde enviar tráfico. Un receptor HTTP o HTTPS sin reglas predeterminadas y sin reglas coincidentes responde **`503`** con el cuerpo `no default target group`. Establezca o desactive deliberadamente con `clear_default_target_group: true` una vez que sus reglas cubran todo lo que sirve. ## Reglas de enrutamiento Las reglas existen solo en los listeners `http` y `https`; se rechaza la creación de una en un listener L4. Cada regla tiene una prioridad, una lista de condiciones y un grupo objetivo. Abra el escuchador y elija **Add Rule**. **Evaluation order** toma la **Priority**, **Conditions** construye la coincidencia y **Forward to** elige el **Target group**. ```bash theme={null} POST /v1/load-balancers/{id}/listeners/{listener_id}/rules { "priority": 100, "conditions": [ { "field": "host", "op": "exact", "values": ["api.example.com"] }, { "field": "path", "op": "prefix", "values": ["/v1"] } ], "target_group": "b8c9d0e1-f2a3-4456-b7c8-d9e0f1a2b3c4" } ``` ```bash theme={null} basaltic loadbalancer rule create "$LOAD_BALANCER_ID" "$LISTENER_ID" --priority 100 \ --conditions '[{"field":"host","op":"exact","values":["api.example.com"]},{"field":"path","op":"prefix","values":["/v1"]}]' \ --target-group b8c9d0e1-f2a3-4456-b7c8-d9e0f1a2b3c4 ``` ```go theme={null} _, err := loadbalancer.New(cfg).CreateRule(ctx, loadBalancerID, listenerID, &loadbalancer.CreateRuleRequest{ Priority: 100, Conditions: []*loadbalancer.RuleCondition{ {Field: "host", Op: "exact", Values: []string{"api.example.com"}}, {Field: "path", Op: "prefix", Values: []string{"/v1"}}, }, TargetGroup: "b8c9d0e1-f2a3-4456-b7c8-d9e0f1a2b3c4", }) if err != nil { log.Fatal(err) } ``` Las reglas se evalúan en orden ascendente de prioridad y la **primera coincidencia gana**; `priority` es `1..50000` y único por oyente. Cada condición de una regla tiene que coincidir — la lista es un AND. | `field` | Partidos de fútbol | En la consola | | - | - | - | | `host` | La autoridad de la solicitud (su `Host`) | **Encabezado del host** | | `path` | La ruta de solicitud | **Path** | | `header` | El encabezado nombrado en `name` | **Encabezado HTTP** | | `query` | La clave de cadena de consulta nombrada en `name` | **Param de consulta** | | `method` | El método HTTP, escrito como HTTP lo escribe — `GET` | **Método HTTP** | | `op` | Comportamiento | | - | - | | `exact` | Igualdad de valor total | | `prefix` | El valor comienza con | | `glob` | Solo `*` es un comodín; todos los demás metacaracteres son literales | | `regex` | RE2 sintaxis | La consola lista los operadores como **iguales**, **prefijo**, **glob** y **expresión regular** — solo `exact` se lee de manera diferente allí. Dale a cada condición un **valor único**. `values` es un array, pero el plano de datos coincide con la primera entrada e ignora el resto. Expresar alternativas con `glob` o `regex`, o escribir una regla por valor. Una condición `header` o `query` sin `name` es rechazada, y también lo es un valor `regex` que no se compila como RE2. Ese rigor es deliberado: la configuración de un balanceador de carga se construye en una sola pasada, por lo que una sola condición no traducible detendría **todas** las réplicas cargando cualquier configuración, incluidos los reemplazos que están esperando un cambio de tamaño. Rechazar la escritura le cuesta un error en lugar de una interrupción. Actualizar una regla es un reemplazo completo: envíe `priority`, `conditions` y `target_group` juntos, la misma forma que crea. La consola hace lo mismo detrás de **Edit Rule**, titulado con la prioridad de la regla — el formulario aparece rellenado y **Save Rule** escribe la regla entera de vuelta. Eliminar una regla a través de su escuchador — `DELETE /v1/load-balancers/{id}/listeners/{listener_id}/rules/{rule_id}`. El formulario sin escucha todavía funciona para los clientes que ya están en él, pero tiene que escanear los oyentes del balanceador de carga para probar que la regla pertenece allí. ## Grupos de destinos Un grupo de destino es el conjunto de backends a los que reenvía un escuchador o una regla. Es un recurso de ámbito de cuenta por sí mismo, no un hijo de un balanceador de carga, por lo que un grupo puede respaldar varios oyentes, lo que hace que un intercambio azul/verde sea una cuestión de volver a señalar una regla. Vaya a **Compute → Target Groups** y elija **Create Target Group**. Los archivos de consola se dirigen a grupos bajo **Compute** aunque pertenezcan a la API de balanceador de carga. **Target group** toma el **Name**, el **Protocol** y el **Port**. **Backends** selecciona el **Backend mode**: **Static targets** para un conjunto que adjuntas tú mismo, **Instance pool** para realizar el seguimiento de un grupo y, para un grupo estático, el **Target type**: **IP address** o **Instance**. ```bash theme={null} POST /v1/target-groups { "name": "web-targets", "protocol": "http", "target_type": "instance", "port": 8080 } ``` ```bash theme={null} basaltic loadbalancer target-group create --name web-targets --protocol http --target-type instance --port 8080 ``` ```go theme={null} _, err := loadbalancer.New(cfg).CreateTargetGroup(ctx, &loadbalancer.CreateTargetGroupRequest{ Name: "web-targets", Protocol: "http", Port: 8080, TargetType: basaltic.String("instance"), }) if err != nil { log.Fatal(err) } ``` Debe coincidir con el protocolo del receptor que apunta a él. Qué significa `target` en cada target adjunto. `static` usa los objetivos que adjuntas. `pool` toma sus backends de un pool de instancias de computación llamado `instance_pool`, por lo que al escalar el pool se mueve el conjunto de backends con él — y adjuntar un objetivo a mano se rechaza con un `409`, porque una fila a la que no se enrutaría nada es peor que un error. Un grupo de modo de agrupación se fuerza a `target_type: instance`. El puerto predeterminado para los destinos del grupo. Un objetivo puede anularla. Eliminar un grupo mientras un escuchador predeterminado o una regla todavía hace referencia a él es un **`409`** — reapunta o elimina la referencia primero. En la consola que es **Eliminar grupo de destino**, en la pestaña del grupo **Settings**. El número de oyentes por balanceador de carga, grupos de destino por balanceador de carga y destinos por grupo son cuotas de cuenta; exceder uno se rechaza en la escritura. `target_type: function` es aceptado en un grupo, pero se rechaza adjuntar un objetivo a él: el tiempo de ejecución de la función no está disponible todavía, por lo que el grupo no tiene forma de resolver un backend. ### Adjuntar objetivos Abra el grupo de destino y seleccione **Attach Target**. El primer campo sigue al tipo de destino del grupo (**IP address** o **Instances**) y **Port** es el puerto predeterminado del grupo de destino. Un grupo de modo de grupo no tiene ningún botón **Attach Target**: la membresía hace un seguimiento del grupo de instancias, por lo que no hay nada que adjuntar manualmente. ```bash theme={null} POST /v1/target-groups/{id}/targets { "target": "web-01", "port": 8080 } ``` ```bash theme={null} basaltic loadbalancer target-group attach-target "$TARGET_GROUP_ID" --target web-01 --port 8080 ``` ```go theme={null} _, err := loadbalancer.New(cfg).AttachTarget(ctx, targetGroupID, &loadbalancer.AttachTargetRequest{Target: "web-01", Port: basaltic.Int(8080)}) if err != nil { log.Fatal(err) } ``` `target` es una dirección IP literal en un grupo `ip` y un UUID, CRN o nombre de instancia de cómputo en un grupo `instance`. Una referencia de instancia permanece sin resolver en la fila y se convierte en una dirección en el momento de la configuración, por lo que una instancia cuya dirección de NIC cambie no necesita actualizarse aquí. La instancia debe existir en tu cuenta — ver [compute](/es/compute). Las direcciones se almacenan de forma canónica, por lo que la ortografía que lee puede diferir de la que envió, y dos ortografías del mismo punto final se reconocen como duplicadas. Un destino `ip` tiene que ser una **dirección de unicast enrutable**. Las direcciones de bucle, enlace local, multidifusión y no especificadas se rechazan. Este es un límite de seguridad, no de orden: link-local lleva el punto final de metadatos de la instancia y loopback es el propio socket administrativo de la réplica. Ambos son accesibles desde una réplica, por lo que sin la comprobación un oyente los enviaría directamente a Internet. El formulario IPv6 asignado a IPv4 también se rechaza; envíe el formulario IPv4 con puntos. Al desconectar un objetivo, este se elimina inmediatamente: **Detach** en la fila del objetivo en la consola, confirmado como **Desconectar objetivo**. ### Revisión de salud El plano de datos sondea cada objetivo e informa lo que ve. Ajuste los botones por grupo, en crear o con un patch: **Create Target Group** expone exactamente uno de estos, como **Health check path** en **Health & connection**. El campo solo aparece para un grupo HTTP o HTTPS. El intervalo, tiempo de espera y umbrales son *API solamente*. La pestaña **Health check** de un grupo objetivo muestra lo que se establece, pero nada en la consola los escribe — envíe el bloque a continuación para cambiar uno. ```bash theme={null} PATCH /v1/target-groups/{id} { "health_check": { "protocol": "http", "path": "/healthz", "interval_sec": 30, "timeout_sec": 5, "healthy_threshold": 3, "unhealthy_threshold": 3 } } ``` ```bash theme={null} basaltic loadbalancer target-group update "$TARGET_GROUP_ID" \ --health-check '{"protocol":"http","path":"/healthz","interval_sec":30,"timeout_sec":5,"healthy_threshold":3,"unhealthy_threshold":3}' ``` ```go theme={null} _, err := loadbalancer.New(cfg).UpdateTargetGroup(ctx, targetGroupID, &loadbalancer.UpdateTargetGroupRequest{ HealthCheck: &loadbalancer.HealthCheck{ Protocol: "http", Path: "/healthz", IntervalSec: 30, TimeoutSec: 5, HealthyThreshold: 3, UnhealthyThreshold: 3, }, }) if err != nil { log.Fatal(err) } ``` `protocol` por defecto es el propio del grupo. La exploración a través de HTTP en un grupo `tcp` es compatible y común — un backend que habla un protocolo binario todavía puede servir una página de estado. `path` por defecto es `/` para `http` y `https`; las comprobaciones de `tcp` y `udp` son solo de conexión e ignoran esto. Los umbrales son resultados consecutivos: tres fracasos seguidos para ir malsano, tres éxitos para volver. `health_check.matcher` y `health_check.port` Se aceptan y almacenan, pero no se **No se aplica a la sonda** Una sonda golpea el propio puerto del objetivo. Dejarlos sin configurar en lugar de esperar que cambien algo. Lea el resultado en cada objetivo: | `health` | Significado de la palabra | | - | - | | `initial` | No hay prueba exitosa todavía. Un objetivo que nunca sale de este estado no se está alcanzando. | | `healthy` | Pasar y recibir tráfico. | | `unhealthy` | Fallando, y sacado de la rotación. | ### Afinidad de sesión Por defecto, cada solicitud se balancea de forma independiente. Activar la visibilidad por grupo objetivo: En la consola, este es el campo **Stickiness**, en **Create Target Group** y en la pestaña **Settings** de un grupo existente. Ofrece **None**, **Cookie** y **Source IP**, con **Cookie name** y **Duration (seconds)** que aparecen bajo **Cookie**. **Cookie** solo se muestra para un grupo HTTP o HTTPS, por la razón que se indica a continuación. ```json theme={null} { "session_affinity": { "type": "cookie", "cookie_name": "BASALTICLB", "duration_sec": 86400 } } ``` El balanceador de carga establece una cookie opaca en la primera respuesta y envía cada solicitud posterior llevándola al mismo backend. Solo los grupos `http` y `https` — no hay cookies en un flujo sin procesar. `cookie_name` es por defecto `BASALTICLB` y `duration_sec` es de un día, hasta un máximo de siete días (`604800`). La cookie es un valor aleatorio que no significa nada fuera de este balanceador de carga. No codifica qué backend fue elegido, por lo que un cliente no puede leer sus direcciones internas de él. ```json theme={null} { "session_affinity": { "type": "source_ip" } } ``` Hace un hash de la dirección del cliente. Funciona en todos los protocolos y es la única opción para `tcp` y `udp`. Tenga en cuenta que una puerta de enlace NAT delante de sus clientes hace que cada cliente detrás de ella sea una clave, lo que los concentra en un backend. ```json theme={null} { "session_affinity": { "type": "none" } } ``` El valor predeterminado. Desactivar la adhesión **off** en un grupo existente necesita este cuerpo explícito — omitir `session_affinity` de un parche deja la configuración actual sola. Ambos modos hacen hash de forma consistente, por lo que agregar o perder un backend mueve solo a los clientes que ese backend estaba sirviendo en lugar de reordenar a todos. ### Ver al cliente real Un grupo de destino `http` o `https` ya obtiene la dirección del cliente en `X-Forwarded-For`, y cualquier `X-Forwarded-For` que el cliente envíe no es de confianza — el balanceador de carga es el borde, así que nada ascendente a él cuenta. Para grupos `tcp` y `udp`, o backends que prefieren un sobre enmarcado, establece `proxy_protocol: true` y las conexiones ascendentes se envuelven en un encabezado PROXY v2 que lleva la dirección y el puerto del cliente original. El parámetro de la consola es **Protocolo PROXY (v2)**, en **Health & connection**. ## Réplicas `desired_count` es el número de réplicas deseado. `min_count` y `max_count` vinculados tanto a escala manual como automática. Una réplica es suficiente para funcionar; dos o más pueden seguir sirviendo si se pierde una. ```bash theme={null} GET /v1/load-balancers/{id}/replicas ``` Las réplicas son instancias administradas, por lo que `GET /v1/instances` no las devuelve por diseño. Este extremo es la única ventana hacia ellos. Cada entrada lleva `instance_id`, `replica_index`, el `flavor_id` en el que realmente arrancó, y una vista de liveness actualizada en cada informe de estado: | `status` | Significado de la palabra | | - | - | | `initializing` | La réplica nunca ha informado — arranque todavía en curso. `last_seen` está ausente. | | `healthy` | Informes, y su proxy está sirviendo. | | `unhealthy` | Reporting, pero su proxy está caído. Se saca del camino de tráfico hasta que se recupera. | | `draining` | Retiro después de la retirada de nuevo tráfico. Las conexiones existentes tienen un período de gracia limitado. | El balanceador de carga en sí va `active` en la primera réplica para informar de salud, y cae a `error` solo cuando **cada** La réplica ha pasado en silencio la ventana de obsolescencia — un informe perdido no es suficiente. `active` Tan pronto como se reanude cualquier réplica. ### Escala **Scale** en el balanceador de carga abre **Scale load balancer**. Muestra el **Current size** y toma **Minimum count**, **Maximum count** y **Desired count**. Habilite **Automatic scaling** para configurar la CPU o los objetivos de métrica personalizados y, a continuación, elija **Scale** para guardar. La pestaña **Scaling** muestra la política y las decisiones recientes. ```bash theme={null} PATCH /v1/load-balancers/{id} { "min_count": 2, "max_count": 6, "desired_count": 4 } ``` ```bash theme={null} basaltic loadbalancer load-balancer update "$LOAD_BALANCER_ID" --min-count 2 --max-count 6 --desired-count 4 ``` ```go theme={null} _, err := loadbalancer.New(cfg).UpdateLoadBalancer(ctx, loadBalancerID, &loadbalancer.UpdateLoadBalancerRequest{MinCount: basaltic.Int(2), MaxCount: basaltic.Int(6), DesiredCount: basaltic.Int(4)}) if err != nil { log.Fatal(err) } ``` Las llamadas CLI y Go anteriores establecen juntos los límites y la cantidad deseada. El máximo de seis permite sustituir réplicas sin reducir las cuatro deseadas. Una actualización solo de los límites ajusta la cantidad deseada al nuevo intervalo; una cantidad deseada explícita fuera de ese intervalo se rechaza. El escalado horizontal aprovisiona réplicas del grupo de instancias administradas del balanceador de carga. La escalabilidad interna retira las réplicas que se retiran del tráfico nuevo, espera a que el proxy acepte el drenaje y, a continuación, permite el período de gracia configurado antes de la eliminación. El período de gracia predeterminado es de 120 segundos. Las sesiones TCP, UDP y WebSocket de larga duración pueden terminar cuando se elimina una réplica; planifique las reconexiones. Los cambios en la membresía de reenvío de IP flotante también pueden cambiar la ubicación de la conexión durante la retirada. El campo `autoscaling` acepta las mismas [CPU y políticas de métrica personalizadas](/es/compute/instance-pools#automatic-scaling) que los grupos de instancias. Por ejemplo, el seguimiento de objetivos de CPU al 60% ajusta la capacidad deseada entre el mínimo y el máximo. Las métricas personalizadas pueden usar la profundidad de la cola, las tasas de solicitud u otra demanda publicada en Telemetry. Los balanceadores de carga siempre conservan al menos una réplica. Las muestras faltantes o obsoletas impiden la escala. Configurar la política del balanceador de carga a través de su propia API. Su grupo administrado no puede redimensionarse de forma independiente. Los grupos de instancias de backend tienen sus propios límites y políticas: cambiar la capacidad del proxy no cambia el tamaño de los trabajadores de la aplicación. La telemetría del balanceador de carga incluye `instance_id` en la serie de cada réplica. Para los contadores, calcule las tarifas por serie antes de sumar entre réplicas para que un reinicio o reemplazo no pueda enmascarar el tráfico de otra réplica. Suma el último indicador de conexión activa de cada réplica para obtener un total. Los medidores de estado de destino describen la vista de cada réplica de los mismos backends, por lo que debes mantener esas vistas separadas o usar un mínimo o máximo; al sumarlas se cuentan los backends repetidamente. Para los histogramas de latencia, calcule las tasas de contador por serie y combine los límites de depósito coincidentes entre las réplicas antes de calcular un percentil. ### Cambiar el tipo de instancia Una instancia en ejecución no puede cambiar de tamaño en el lugar, por lo que un cambio de tamaño registra el nuevo tamaño y devuelve — las réplicas ya activas se reemplazan una a la vez en segundo plano, durante los siguientes minutos. **Resize** en el balanceador de carga abre **Resize load balancer**. Elige el nuevo **Flavor** y confirma con **Resize**. El botón está desactivado mientras un cambio de tamaño ya está en ejecución — la consola no apilará dos rollos. ```bash theme={null} PATCH /v1/load-balancers/{id} { "flavor": "e5f6a7b8-c9d0-4123-e4f5-a6b7c8d9e0f1" } ``` ```bash theme={null} basaltic loadbalancer load-balancer update "$LOAD_BALANCER_ID" --flavor e5f6a7b8-c9d0-4123-e4f5-a6b7c8d9e0f1 ``` ```go theme={null} _, err := loadbalancer.New(cfg).UpdateLoadBalancer(ctx, loadBalancerID, &loadbalancer.UpdateLoadBalancerRequest{ Flavor: basaltic.String("e5f6a7b8-c9d0-4123-e4f5-a6b7c8d9e0f1"), }) if err != nil { log.Fatal(err) } ``` **La reserva crece antes de reducirse.** Una réplica extra aparece en el nuevo tipo de instancia y comienza a servir *antes* de que cualquier réplica en el viejo se retire, por lo que el rollo espera a la capacidad de reemplazo antes de retirar la capacidad antigua. La réplica extra debe caber dentro de `max_count`. Desired y minimum permanecen sin cambios; `rollout_surge` indica el miembro adicional temporal. Cuando la última réplica vieja se va, el grupo vuelve a la capacidad deseada. Vea en `GET /v1/load-balancers/{id}/replicas`. Una réplica se ha reemplazado cuando su `instance_id` cambia, y el redimensionamiento se realiza cuando cada `flavor_id` coincide con el del balanceador de carga. Ver una réplica más listada que `desired_count` a mitad de camino es el aumento que mantiene su capacidad, no una réplica que se escapa — desaparece cuando lo hace la última vieja. La consola lee lo mismo para usted: la pestaña **Replicas** marca una réplica que el rollo aún no ha alcanzado, y la página del balanceador de carga cuenta cuántas están en el nuevo tamaño. Dos cosas que vale la pena saber: * **Nada se retira hasta que todo está sano.** El rollo espera a que el grupo esté completo con cada informe de réplica y su proxy. Un reemplazo que nunca se recupera de forma segura detiene el redimensionamiento con el balanceador de carga completo, en lugar de hacerlo una réplica por pasada. * **Un balanceador de carga en su máximo no tiene espacio libre de reemplazo.** Aumentar `max_count` Un cambio de tipo de instancia se rechaza cuando no hay espacio para un reemplazo. Un rollo ya en curso espera si un cambio de límites posterior elimina ese espacio. El escalado automático se detiene durante el rollo. Un cambio de tamaño se rechaza por adelantado si tu cuenta carece de la cuota de cálculo para la réplica de reemplazo, por lo que no puede aplicarse a mitad de camino y dejar el balanceador de carga corto. ## Eliminación En la pestaña **Settings** del balanceador de carga, **Delete load balancer**. Se le pedirá que escriba el nombre del balanceador de carga para confirmar. En su lugar, se elimina un listener de la pestaña **Listeners**, y se lleva sus reglas con él. Los grupos de destino sobreviven a ambos: son recursos de ámbito de cuenta, no hijos del balanceador de carga. ```bash theme={null} DELETE /v1/load-balancers/{id} ``` ```bash theme={null} basaltic loadbalancer load-balancer delete "$LOAD_BALANCER_ID" ``` ```go theme={null} err := loadbalancer.New(cfg).DeleteLoadBalancer(ctx, loadBalancerID) if err != nil { log.Fatal(err) } ``` Respuestas **`202`**. El balanceador de carga se mueve a `deleting` y permanece legible mientras se liberan su reserva de dirección, réplicas y estado interno, con el registro eliminado por último. Sonda hasta que responda `404` en lugar de tratar el `202` como prueba de que se ha ido. Repetir la eliminación es seguro. ## Statuses ```mermaid theme={null} stateDiagram-v2 [*] --> provisioning: create provisioning --> active: a replica reports its proxy healthy provisioning --> error: an active error fault active --> error: an active error fault error --> active: every error fault resolved active --> deleting: delete error --> deleting: delete deleting --> [*]: teardown converges ``` | Estado | Significado | | - | - | | `provisioning` | Ninguna réplica ha empezado a atender tráfico. Las réplicas están arrancando e instalando su software. En este estado todavía no se registran fallos de actividad de las réplicas. | | `active` | Al menos una réplica está sirviendo, y no queda ningún fallo de error activo. Una advertencia `REPLICAS_DEGRADED` deja este estado en su lugar. | | `error` | Un error de fallo activo permanece — lee cada entrada en `faults`. Esto incluye una interrupción completa de la réplica (`REPLICAS_UNAVAILABLE`) y cualquier error de aprovisionamiento o configuración. | | `deleting` | Desmontaje en curso. Todavía legible hasta que se elimina el registro. | Un nuevo informe de actividad resuelve solo los códigos relacionados con la actividad de las réplicas (`REPLICAS_DEGRADED`, `REPLICAS_UNAVAILABLE`). Los errores de aprovisionamiento o de generación de la configuración permanecen activos. | Código | Significado y recuperación | | - | - | | `PROVISIONING_FAILED` | Las réplicas o su software no aparecieron. El balanceador de carga permanece en `error` hasta que ese trabajo tiene éxito. | | `CONFIG_RENDER_FAILED` | No se pudo procesar la configuración del proxy. | | `CONFIG_PUBLISH_FAILED` | No se pudo publicar una configuración procesada en las réplicas. | | `CONFIG_GENERATION_FAILED` | No se pudo producir una nueva generación de configuración. | | `OVN_RECONCILE_FAILED` | El programa de plano de datos no converge. | | `REPLICA_ROLL_FAILED` | Un reemplazo de réplica no se completó. | | `TEARDOWN_FAILED` | Se genera solo cuando el desmantelamiento deja de avanzar: las réplicas que se cierran durante una eliminación normal no generan ningún error. Se borra cuando el reintento converge. | | `LEGACY_OPERATION_FAILED` | Un error migrado de la cadena de error anterior. Despachado por la operación que ahora lo posee. | | `REPLICAS_DEGRADED` | Algunas réplicas están bajas y otras todavía están sirviendo. Se registra solo después de la primera observación de servicio. Esto es una `warning`; `status` permanece `active`. | | `REPLICAS_UNAVAILABLE` | No hay réplica en servicio. Se registra solo después de la primera observación de servicio: un conjunto de réplicas que nunca se ha servido es aprovisionamiento, no una interrupción. Esto es un `error`. | ## Límites y nomenclatura Comienza con una letra, luego letras, dígitos, `.`, `_` o `-`, hasta 127 caracteres. Aparece en el CRN, por lo que tiene que ser URL-safe. Los nombres de balanceador de carga y grupo de destino se fijan después de la creación porque las políticas de IAM se dirigen a sus CRN. Las actualizaciones que contienen `name` devuelven un error de validación, incluyendo valores sin cambios, vacíos o `null`. Los recursos existentes conservan sus nombres actuales. Al eliminar un recurso y reutilizar su nombre se crea un recurso diferente, incluso si su CRN es el mismo. Los oyentes y las reglas no tienen nombres separados. Sus CRN usan componentes UUID bajo el nombre inmutable del balanceador de carga: `load-balancer//listener/` y `load-balancer//listener//rule/`. Pasa un UUID o CRN codificado en URL en sus parámetros de ruta; no se aceptan nombres de escucha y reglas desnudos. El CRN de un balanceador de carga termina en `load-balancer/` y el de un grupo objetivo en `target-group/`. Debido a que el CRN lleva el nombre, una [política de IAM](/es/iam/policies) puede usar comodín una convención de nombres en lugar de listar ids. Toma la cadena exacta del campo `crn` del recurso en lugar de ensamblarla. Tanto en la creación como en un parche. Único por oyente. Los oyentes por balanceador de carga, los grupos objetivo por balanceador de carga y los objetivos por grupo objetivo son cuotas de cuentas en lugar de números fijos. Lista de operaciones de página con `limit` y `marker`; página hasta que `meta.has_more` es falso en lugar de hasta que una página se ve corta. Crea aceptar un encabezado `Idempotency-Key`, que hace que un intento devuelva el resultado original en lugar de un duplicado. ## Solución de problemas La causa más común es que ningún grupo de seguridad en las réplicas abre el puerto de escucha. `security_groups` está establecido en create y no puede ser parcheado en el balanceador de carga — cambie las reglas dentro de los grupos de seguridad que ya ha adjuntado, o recrear con el conjunto correcto. Consulte [networking](/es/networking). La segunda causa es un oyente cuya `exposure` es `private_only` cuando se esperaba public, o `public_only` en un balanceador de carga cuya IP flotante ha desaparecido — un oyente `public_only` sin dirección pública no se sirve en absoluto. La subred que eligió no tiene ninguna ruta `0.0.0.0/0` a una puerta de enlace de Internet. El tráfico de respuesta sale por esa tabla de ruta, por lo que la dirección sería inalcanzable, y todo el proceso de creación falla en lugar de dejarle un balanceador de carga sin la dirección que solicitó. Adjunta una puerta de enlace de Internet a la VPC y agrega la ruta predeterminada, luego créala de nuevo. `floating_ip` es un campo de tiempo de creación solamente, por lo que no hay una segunda oportunidad después. `initial` significa que ninguna sonda ha tenido éxito todavía. Compruebe, en orden: el backend está escuchando en el `port` del grupo (o la anulación del objetivo); el propio grupo de seguridad del backend permite la subred de las réplicas; y, para una comprobación HTTP, esa `path` devuelve un estado de éxito. Recuerde que la sonda golpea el propio puerto del objetivo — `health_check.port` no se aplica hoy. Tres cosas a revisar. Las reglas se ejecutan en orden ascendente de `priority` y la primera partida gana, por lo que una regla amplia de bajo número sombrea las específicas debajo de ella. Cada condición de una regla debe coincidir; la lista es un AND, no un OR. Y una condición coincide con la **primera** entrada de `values`; las entradas extras se ignoran, por lo que expresa alternativas con `glob` o `regex`. Si no hay ninguna regla que coincida, la solicitud va al `default_target_group` del escuchador, o recibe un `503` que dice `no default target group` si no hay ninguno. Se rechazan dos eliminaciones: el último certificado en un servidor de escucha HTTPS y el certificado actualmente marcado como `is_default`, mientras que los demás permanecen. Adjunte o promueva un reemplazo como el predeterminado primero, lo que degrada al antiguo en la misma transacción, y luego desacoplar. Si la solicitud 404s o errores en la ruta en sí, la barra del CRN se envió crudo. Codifica el porcentaje como `%2F`. El rollo avanza una réplica a la vez y no retirará nada mientras cualquier réplica no esté sana o todavía esté subiendo. Por lo tanto, un resize estancado generalmente significa un reemplazo que nunca salió sano — compruebe `GET /v1/load-balancers/{id}/replicas` para uno que se sienta en `initializing` o `unhealthy`. El balanceador de carga sigue sirviendo en las réplicas que tiene mientras esto sea cierto, que es el punto. Se espera ver una réplica más que `replica_count` a mitad de rollo. El `default_target_group` de un escucha o el `target_group` de una regla todavía apuntan a él. Vuelva a apuntar o elimine la referencia y, a continuación, elimine el grupo.