Configure a fault handling policy for a pod - Elastic Container Instance

De forma predeterminada, el sistema reintenta automáticamente la creación de un pod basado en Elastic Container Instance cuando este falla. Si necesita conocer rápidamente el resultado de la creación y atender el error lo antes posible, modifique la política de manejo de errores del pod.

Descripción de la configuración

La creación de un pod en un nodo virtual puede fallar por falta de recursos. De forma predeterminada, el sistema reprograma los recursos automáticamente e intenta volver a crear el pod. Para configurar la política de manejo de errores y especificar si se debe recrear el pod tras un fallo, agregue la anotación k8s.aliyun.com/eci-fail-strategy.

Importante

Las anotaciones deben agregarse en los metadatos (metadata) del archivo de configuración del pod. Por ejemplo, al crear un Deployment, agréguelas en la sección spec.template.metadata.
Las anotaciones relacionadas con Elastic Container Instance solo se aplican durante la creación del pod. Agregar o modificar estas anotaciones en un pod existente no surte efecto.

A continuación se describen los valores válidos de la anotación k8s.aliyun.com/eci-fail-strategy.

Valor	Descripción	Escenario
fail-back	Cuando la creación del pod falla, el sistema intenta recrearlo automáticamente. El pod permanece en estado Pending hasta que se crea correctamente. Una vez recreado, su estado cambia a Running.	Requiere una alta tasa de éxito y acepta demoras en la entrega de los pods.
fail-over	Produce el mismo efecto que fail-back.
fail-fast	Si la creación del pod falla, el sistema reporta un error de inmediato y el pod queda en estado ProviderFailed. La capa superior de orquestación determina si se reintenta la creación o si se programa el pod en un nodo real.	Necesita alta eficiencia y desea entregar los pods rápidamente. El sistema proporciona una lógica optimizada para el manejo de errores.

Nota

Si agrega la anotación k8s.aliyun.com/eci-fail-strategy: "fail-fast" en los metadatos del archivo de configuración de un pod basado en Elastic Container Instance, el aprovisionador no es compatible con StorageClass WaitForFirstConsumer al montar un volumen de disco aprovisionado dinámicamente en el pod.
Se recomienda no usar la anotación k8s.aliyun.com/eci-reschedule-enable para configurar la reprogramación.

Ejemplo de configuración

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test
  labels:
    app: test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx-test
      labels:
        app: nginx
        alibabacloud.com/eci: "true" 
      annotations:
        k8s.aliyun.com/eci-fail-strategy: "fail-fast" # If a pod fails to be created, the system directly reports an error without attempting to recreate the pod.
        k8s.aliyun.com/eci-use-specs: "ecs.c6.large"
    spec:
      containers:
      - name: nginx
        image: registry.cn-shanghai.aliyuncs.com/eci_open/nginx:1.14.2
        ports:
        - containerPort: 80

En el archivo YAML anterior, la política de manejo de errores del pod es fail-fast. Si el pod permanece mucho tiempo en estado Pending, consulte el valor de status.reason del pod.

Si el valor de status.reason es ContainerInstanceScheduleFailed, la programación del pod falló. En este caso, revise la condición ContainerInstanceCreated e identifique la causa mediante los campos reason y message. Después, tome las medidas correspondientes, como modificar las especificaciones del pod o configurar varias zonas para su creación. Para obtener más información, consulte ContainerInstanceCreated.
Si el valor de status.reason está vacío, revise la condición ContainerInstanceCreated y compruebe el estado de programación según su valor. En la mayoría de los casos, cuando la política es fail-fast, el campo status.reason no está vacío.
- Si el valor de ContainerInstanceCreated es True, el pod se programó correctamente y ocurrió una excepción durante la creación del sandbox.
- Si el valor de ContainerInstanceCreated es False y el valor de reason no es Creating, la programación del pod falló y debe esperar a que se programe.

Por ejemplo, suponga que la creación de un pod falla por falta de recursos. A continuación se muestra la condición ContainerInstanceCreated cuando la política de manejo de errores del pod es fail-fast.

Nota

Si la política de manejo de errores es fail-back, el sistema reprograma el pod automáticamente después de que falla su creación. En este caso, el valor de status.reason no es ContainerInstanceScheduleFailed. Consulte la condición ContainerInstanceCreated e identifique la causa del fallo de programación del ciclo actual mediante los campos reason y message.

{
    "conditions": [
        {
            "lastProbeTime": "2023-03-30T18:11:31Z",
            "lastTransitionTime": "2023-03-30T18:11:31Z",
            "message": "Create ECI failed because the specified instance is out of stock. %s",
            "reason": "ContainerGroup.NoStock",
            "status": "False",
            "type": "ContainerInstanceCreated"
        }
    ],
    "Reason":"ContainerInstanceScheduleFailed",
    "phase": "Pending"
}