Copy page

Unidades que controla tu código

Unidades que controla tu código

Un Workload normalmente escala solo: fijas un número, o unos objetivos de CPU y memoria, y la plataforma decide cuántas unidades corren. Algunos programas necesitan decidirlo ellos mismos: una red de Minecraft que abre un servidor por partida, una granja de render que ejecuta una unidad por trabajo, un hub que despierta un mundo privado cuando su dueño entra. Para esos casos, pon la política en modo code y deja que tu programa diga qué unidades existen.

Las piezas

Concepto	Una frase	Dónde
Clave	El nombre que das a una unidad; nunca cambia y es su nombre de red privado	Crear por clave
Etiquetas	Hasta 16 marcas consultables, modificables en cualquier momento	Etiquetas y user data
user_data	Hasta 64 KiB de JSON que la unidad lee al arrancar: la partida, el trabajo, el mundo	Etiquetas y user data
Origen	Quién creó la unidad: policy, code o warm
Buffer caliente	Unidades iniciadas e inactivas que la plataforma te mantiene listas	Buffer caliente y allocate
Allocate	Entregar atómicamente una unidad caliente a quien llama, con datos de entrada	Buffer caliente y allocate
Señales	Lo que una unidad le dice a la plataforma: ready, accepting, idle, busy, shutdown	Señales
Reglas de despliegue	Cómo una imagen nueva reemplaza unidades en marcha sin cortar una partida	Reglas de despliegue
Eventos y webhooks	Un registro continuo de todo lo que pasa con tus unidades	Eventos
Principal de servicio	La identidad propia del Workload para llamar a la API desde dentro	Principales de servicio
Contrato de unidad	Los archivos, el entorno y los sockets en los que puede confiar el proceso de una unidad	El contrato

La vida de una unidad

Code
creada (detenida) --start--> arrancando --ready--> en marcha --stop--> drenando --> detenida
                                  \                    |                              |
                                   \--failed           |--salida: restart / stop / destroy
                                                       \--destroy--> destruida <-----/

• Asignada no es un estado aparte: es un hecho sobre una unidad en marcha (allocation está definido). Una asignación nunca se deshace.
• Una unidad detenida no tiene pod y no cuesta nada. Su clave, etiquetas y user_data se conservan.
• Cuando el proceso de la unidad termina, decide on_exit: restart (mismo pod, proceso nuevo), stop o destroy.
• Antes de detener, destruir o reemplazar una unidad, se drena: recibe un aviso (/zaroz/state.json), deja de aceptar trabajo nuevo y tiene tiempo para terminar antes de que se señale el proceso.

Cuánto cuesta

No hay un contador nuevo. Una unidad creada por código, caliente o asignada es un pod de unidad normal, facturado como cualquier unidad extra: por hora mientras corre, con un mínimo de 5 minutos por arranque. Las unidades calientes se facturan porque ocupan CPU y memoria. Las detenidas son gratis. Eventos, webhooks y principales de servicio están incluidos sin coste. Tu tope de gasto, tu límite de unidades (50 por organización por defecto) y tu tasa de arranques (600 por hora por defecto) se aplican a toda llamada que arranque un pod.

Garantías

Son promesas de la plataforma. Cada una la comprueba la suite de conformidad contra el emulador local y contra una unidad real.

1. Ready significa ready. Con readiness: signal, una unidad recibe tráfico y puede asignarse solo después de haber señalado ready.
2. Allocate es atómico. Dos llamadas nunca reciben la misma unidad, y una unidad asignada nunca la elige una reducción de escala ni la retirada de exceso de calientes.
3. Drenar antes de matar. Una unidad que se detiene, destruye o reemplaza ve draining: true antes de que se señale su proceso.
4. Detenida no cuesta nada. Sin pod, sin objeto de clúster, sin intervalo facturado.
5. Rechazo rápido. Una llamada que supera un límite se rechaza al instante con un código estable y nunca deja una unidad a medias.
6. Fuera del balanceo en aproximadamente un segundo. accepting false saca la unidad del servicio y de la asignación dentro de su región, sin esperar al plano de control de la plataforma.
7. Los eventos nunca se saltan. Un cursor nunca se pierde un evento que se confirma tarde.