Container Service for Kubernetes:Best practices for configuring AI model inference services in Knative

Aceleración del despliegue de modelos

Los archivos de los modelos de IA son muy grandes. Empaquetarlos dentro de imágenes de contenedor genera dos problemas: las imágenes se vuelven demasiado pesadas para descargarse con rapidez y las versiones del modelo quedan ligadas a las versiones de la imagen. En su lugar, almacene los archivos del modelo en Object Storage Service (OSS) o File Storage NAS (NAS). Después, monte el almacenamiento en los pods de su Knative Service mediante una persistent volume claim (PVC).

Para acelerar aún más la carga del modelo, utilice Fluid. Se trata de un motor distribuido de orquestación y aceleración de conjuntos de datos que carga modelos de lenguaje grandes en segundos gracias al almacenamiento de datos en caché sobre discos SSD locales.

apiVersion: v1
kind: Secret
metadata:
  name: access-key
stringData:
  fs.oss.accessKeyId: your_ak_id          # Replace with your AccessKey ID.
  fs.oss.accessKeySecret: your_ak_skrt    # Replace with your AccessKey secret.
---
apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: oss-data
spec:
  mounts:
  - mountPoint: "oss://{Bucket}/{path-to-model}"  # Replace with your OSS bucket and model path.
    name: xxx
    path: "{path-to-model}"                        # Replace with the model path to load.
    options:
      fs.oss.endpoint: "oss-cn-beijing.aliyuncs.com"  # Replace with your OSS bucket endpoint.
    encryptOptions:
      - name: fs.oss.accessKeyId
        valueFrom:
          secretKeyRef:
            name: access-key
            key: fs.oss.accessKeyId
      - name: fs.oss.accessKeySecret
        valueFrom:
          secretKeyRef:
            name: access-key
            key: fs.oss.accessKeySecret
  accessModes:
    - ReadOnlyMany
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: oss-data
spec:
  replicas: 2
  tieredstore:
    levels:
      - mediumtype: SSD
        volumeType: emptyDir
        path: /mnt/ssd0/cache
        quota: 100Gi
        high: "0.95"
        low: "0.7"
  fuse:
    properties:
      fs.jindofsx.data.cache.enable: "true"
    args:
      - -okernel_cache
      - -oro
      - -oattr_timeout=7200
      - -oentry_timeout=7200
      - -ometrics_port=9089
    cleanPolicy: OnDemand

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: sd-backend
spec:
  template:
    spec:
      containers:
        - image: <YOUR-IMAGE>    # Replace with your container image name.
          name: image-name
          ports:
            - containerPort: xxx
              protocol: TCP
          volumeMounts:
            - mountPath: /data/models  # The path where the model is loaded inside the container.
              name: data-volume
      volumes:
        - name: data-volume
          persistentVolumeClaim:
            claimName: oss-data    # Must match the Dataset name.

apiVersion: eci.alibabacloud.com/v1
kind: ImageCache
metadata:
  name: imagecache-ai-model
  annotations:
    k8s.aliyun.com/eci-image-cache: "true"  # Enable cache reuse.
spec:
  images:
  - <YOUR-IMAGE>
  imageCacheSize:
    25    # Cache size in GiB.
  retentionDays:
    7     # Number of days to retain the cache.

Apagado controlado de pods

Si una aplicación utiliza HTTP probing, sus pods entran en estado Not Ready tras recibir la señal SIGTERM. De este modo, ninguna solicitud nueva se enruta hacia ellos. Sin embargo, el queue-proxy de Knative puede seguir reenviando solicitudes en curso durante un breve periodo después de la señal SIGTERM. Establezca timeoutSeconds en 1.2 veces el tiempo máximo de espera de sus solicitudes para darles oportunidad de completarse.

Por ejemplo, si la solicitud más larga tarda 10 segundos, establezca timeoutSeconds en 12:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    spec:
      timeoutSeconds: 12

Configuración de la concurrencia

Los parámetros de concurrencia determinan cuántas solicitudes procesa un pod de manera simultánea. Un ajuste correcto mejora el rendimiento y evita la sobrecarga.

Límite estricto de concurrencia (containerConcurrency): impone un tope obligatorio. Las solicitudes que superan este límite se colocan en una cola y esperan capacidad disponible.

Límite flexible de concurrencia (autoscaling.knative.dev/target): define un objetivo no estricto. Los picos de tráfico pueden superarlo temporalmente. Es la opción predeterminada más segura para la mayoría de las cargas de trabajo de inference.

Uso objetivo (autoscaling.knative.dev/target-utilization-percentage): controla qué tan cerca del límite intenta mantenerse Knative. Establézcalo próximo al 100 % para aprovechar al máximo los pods antes de activar el escalado vertical.

Para obtener más información, consulte Configure the soft concurrency limit.

Auto scaling

Antes de ajustar el auto scaling, mida el tiempo de inicio de sus pods. Este valor determina qué parámetros son más relevantes.

Para consultar la referencia completa de parámetros, visite Enable auto scaling to withstand traffic fluctuations.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/window: "40s"

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/panic-window-percentage: "20.0"

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/panic-threshold-percentage: "150.0"

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  max-scale-up-rate: "500.0"

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  max-scale-down-rate: "4.0"

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/scale-down-delay: "2m"  # Keep pods for 2 minutes after scale-down decision.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/min-scale: "0"

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/max-scale: "3"

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/initial-scale: "3"

Uso compartido de GPU

Container Service for Kubernetes (ACK) admite el uso compartido de GPU mediante cGPU, tecnología que proporciona aislamiento de memoria de GPU entre contenedores. Para habilitar esta función en un Knative Service, configure aliyun.com/gpu-mem dentro de resources.limits.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    spec:
      containerConcurrency: 1
      containers:
      - image: registry-vpc.cn-hangzhou.aliyuncs.com/demo-test/test:helloworld-go
        name: user-container
        ports:
        - containerPort: 6666
          name: http1
          protocol: TCP
        resources:
          limits:
            aliyun.com/gpu-mem: "3"  # GPU memory in GiB allocated to this container.

Probes

Knative ejecuta probes sobre los servicios con mayor frecuencia que Kubernetes estándar para minimizar la latencia de los arranques en frío. Configure probes de liveness y de readiness en sus contenedores de inference.

• Probe de liveness: supervisa el estado del contenedor. Si falla, Kubernetes reinicia el contenedor.

• Probe de readiness: controla el enrutamiento del tráfico. Solo los pods que superan esta prueba reciben solicitudes.

TCP frente a HTTP:

• Probe TCP: no abre el puerto de escucha hasta que todos los componentes se cargan y los contenedores están listos.

• Probe HTTP: se supera únicamente cuando el endpoint devuelve una respuesta exitosa. Resulta más precisa para servicios de inference que requieren una fase de calentamiento.

Establezca periodSeconds en un valor menor que los 10 segundos predeterminados. Así reducirá el tiempo entre la disponibilidad del pod y el momento en que recibe tráfico.

Para obtener más información, consulte Configure port probing in Knative.

Escalado a cero

Cuando un Knative Service no recibe tráfico, Knative puede reducir sus pods a cero. Esto elimina los costos de recursos de los modelos inactivos.

En cargas de trabajo con muchos modelos, cree un Knative Service independiente para cada uno. Esta práctica simplifica la lógica de negocio de cada servicio y permite que cada modelo escale de forma autónoma.

Cuando un cliente accede por primera vez a un modelo inactivo, Knative escala desde cero. Para mitigar el impacto del arranque en frío, configure una reserved instance y garantice que siempre haya como mínimo un pod listo.

Para obtener más información, consulte Configure a reserved instance.

Despliegues canary

Knative mantiene en ejecución la revisión anterior hasta que la nueva está lista. De este modo garantiza la continuidad durante los despliegues.

Controle la división del tráfico mediante el campo percent, cuyo rango válido va del 10 % al 100 %. Establézcalo en 100 % para migrar por completo a la nueva revisión y retirar la anterior de inmediato.

Cuando los recursos sean limitados —por ejemplo, 500 pods en ejecución con solo 300 adicionales disponibles—, utilice un porcentaje de tráfico bajo para controlar la velocidad a la que se reduce la revisión anterior. Un porcentaje demasiado alto en esta situación puede hacer que la revisión antigua disminuya más rápido de lo que crece la nueva, lo que dejaría capacidad insuficiente.

Para obtener más información, consulte Perform a canary release based on traffic splitting for a Knative Service.

Ubicación conjunta de instancias ECS e instancias de contenedor elásticas

Configure ResourcePolicies para combinar instancias de Elastic Compute Service (ECS) con instancias de contenedor elásticas. Las instancias ECS operan durante el tráfico normal, mientras que las instancias de contenedor elásticas absorben los picos.

• Escalado ascendente: Knative programa los pods primero en instancias ECS. Cuando los pods superan el límite predefinido o se agota la capacidad de ECS, los nuevos pods se asignan a instancias de contenedor elásticas.

• Escalado descendente: se eliminan primero los pods alojados en instancias de contenedor elásticas.

Para obtener más información, consulte Colocate ECS instances and elastic container instances in Knative.