Container Service for Kubernetes:Workload FAQ

¿Cómo despliego una aplicación contenedorizada en un clúster de ACK?

El despliegue de una aplicación contenedorizada consta de cuatro fases:

1. Escriba el código de su aplicación en cualquier lenguaje.

2. Compile una imagen de contenedor mediante un Dockerfile, que es un archivo de texto que empaqueta su código y todas sus dependencias en un artefacto de entrega portable. Una imagen de contenedor es más completa que los paquetes tradicionales como archivos JAR, WAR o RPM, ya que agrupa la aplicación con todos los archivos necesarios para el entorno de ejecución del contenedor. Utilice esa imagen para iniciar un contenedor, que representa la aplicación en ejecución. Para obtener instrucciones paso a paso, consulte Build, package, and run images using a Dockerfile.

3. Envíe la imagen a un registro. Container Registry (ACR) almacena, gestiona, distribuye y sirve imágenes. ACR ofrece dos ediciones. Para obtener más información, consulte What is Container Registry ACR.

   • Personal Edition: para desarrolladores individuales.

   • Enterprise Edition: para clientes empresariales.

4. Despliegue cargas de trabajo en ACK para ejecutar su aplicación contenedorizada. ACK gestiona todo el ciclo de vida de las cargas de trabajo contenedorizadas, lo que incluye la programación de pods en nodos específicos, el escalado ante cambios de carga, entre otras funciones. Para obtener más información, consulte Workloads.

¿Por qué la descarga de imágenes tarda demasiado o falla?

Revise los siguientes puntos según el origen desde el cual descarga la imagen:

Descarga a través de la red pública

• Compruebe que su clúster tenga acceso a la red pública. Consulte Enable public network access for a cluster.

• Verifique que su registro de imágenes también permita el acceso público. Para ver un ejemplo con ACR, consulte Configure public network access control for ACR.

• Revise si el ancho de banda de la IP pública está configurado con un valor demasiado bajo.

Descarga desde ACR

• Verifique que el secret de descarga de imágenes sea correcto. Consulte How do I use imagePullSecrets?.

• Si utiliza el componente de descarga sin contraseña, compruebe que esté configurado correctamente. Consulte Pull images within the same account y Pull images across accounts.

¿Cómo soluciono problemas de aplicaciones en ACK?

Los fallos en las aplicaciones suelen originarse en pods, controladores (Deployment, StatefulSet, DaemonSet) o Services. Comience por identificar qué capa presenta el problema y siga los pasos a continuación.

kubectl get endpoints <service_name>

¿Cómo actualizo Helm manualmente?

El componente del lado del servidor Tiller de Helm v2 tiene vulnerabilidades de seguridad conocidas que permiten a atacantes instalar aplicaciones no autorizadas en los clústeres. Actualice a Helm v3. Consulte Upgrading from Helm v2 to Helm v3.

¿Cómo descargo imágenes de una instancia de Container Registry Enterprise Edition en China continental hacia un clúster de ACK fuera de China continental?

Adquiera las siguientes instancias de Container Registry Enterprise Edition:

• Instancia Standard o Premium en la región dentro de China continental.

• Instancia Basic en la región fuera de China continental.

Luego, utilice una instancia de sincronización para replicar las imágenes desde la región de China continental hacia la región fuera de China continental. Consulte Same-account sync instance. Tras la sincronización, obtenga la dirección del registro de la instancia Enterprise Edition en la región fuera de China continental y utilícela al crear aplicaciones en ACK.

ACR Personal Edition tiene velocidades de sincronización más lentas. Para repositorios autogestionados, debe adquirir Global Acceleration (GA) para acelerar la descarga de imágenes, lo cual incrementa el costo. Se recomienda utilizar Container Registry Enterprise Edition. Consulte Billing information .

¿Cómo realizo actualizaciones continuas sin interrupciones del servicio?

Al reemplazar pods durante una actualización continua, ocurre un retraso de algunos segundos antes de que los cambios en los pods se sincronicen con la instancia de Classic Load Balancer (CLB). Esto puede provocar errores 5XX temporales. Configure el apagado graceful para lograr actualizaciones continuas sin tiempo de inactividad. Consulte Implement zero-downtime rolling deployments.

¿Cómo obtengo una imagen de contenedor para una carga de trabajo?

Para conocer los requisitos previos y obtener orientación sobre cómo descargar una imagen de contenedor, consulte Pull image.

¿Cómo reinicio un contenedor?

Kubernetes no admite el reinicio directo de contenedores individuales. En su lugar, elimine el pod; el controlador (Deployment, DaemonSet, etc.) creará automáticamente un reemplazo.

1. Liste los pods para encontrar el que desea reiniciar:

   kubectl get pods

2. Elimine el pod:

   kubectl delete pod <pod-name>

3. Verifique que el nuevo pod esté en ejecución:

   kubectl get pods

   Confirme que el estado del pod sea Running.

En producción, gestione los contenedores a través de objetos de nivel superior como ReplicaSets y Deployments en lugar de manipular los pods directamente. Esto preserva la consistencia del estado del clúster.

¿Cómo cambio el namespace de un Deployment?

Mover un Deployment a un namespace diferente también requiere actualizar manualmente los recursos dependientes —persistent volume claims (PVCs), ConfigMaps y Secrets— al nuevo namespace.

1. Exporte la configuración del Deployment:

   kubectl get deploy <deployment-name> -n <old-namespace> -o yaml > deployment.yaml

2. Edite deployment.yaml y reemplace el valor de namespace:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     annotations:
     generation: 1
     labels:
       app: nginx
     name: nginx-deployment
     namespace: new-namespace # Specify the new namespace.
     ... ...

3. Aplique la configuración actualizada:

   kubectl apply -f deployment.yaml

4. Verifique que el Deployment se esté ejecutando en el nuevo namespace:

   kubectl get deploy -n new-namespace

¿Cómo expongo información del pod a los contenedores en ejecución?

ACK sigue las especificaciones nativas de la comunidad de Kubernetes. Se admiten dos métodos:

• Variables de entorno: pase información del pod a un contenedor mediante variables de entorno. Consulte Exponer información del pod a los contenedores mediante variables de entorno.

• Archivos: monte la información del pod como archivos dentro del contenedor utilizando el volumen Downward API. Consulte Exponer información del pod a los contenedores mediante archivos.

¿Cómo uso imagePullSecrets?

Las instancias de ACR Personal Edition creadas a partir del 9 de septiembre de 2024 no admiten aliyun-acr-credential-helper. Almacene sus credenciales en un Secret de Kubernetes y refiriéralas mediante imagePullSecrets.

Paso 1: Cree el Secret

kubectl create secret docker-registry image-secret \
  --docker-server=<ACR-registry> \
  --docker-username=<username> \
  --docker-password=<password> \
  --docker-email=<email@example.com>

Paso 2: Referencie el Secret

Elija uno de los siguientes métodos:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: default
imagePullSecrets:
- name: image-secret # Enter the ACR Secret

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
  namespace: default
  labels:
    app: nginx
spec:
  serviceAccountName: default # If using the default ServiceAccount for the namespace, you do not need to specify it.
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: <acrID>.cr.aliyuncs.com/<repo>/nginx:latest  # Replace with the ACR instance link

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
  namespace: default
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      imagePullSecrets:
      - name: image-secret  # Use the Secret created in the previous step
      containers:
      - name: nginx
        image: <acrID>.cr.aliyuncs.com/<repo>/nginx:latest  # Replace with the Registry Address of the ACR repository

Verificación

Después de aplicar la configuración, confirme que el pod esté en ejecución:

kubectl get pods

¿Por qué siguen fallando las descargas después de configurar el componente sin contraseña?

Es posible que el componente de descarga sin contraseña esté mal configurado. Revise estas dos causas comunes:

• La información de la instancia en el componente no coincide con la instancia de ACR.

• La dirección de imagen utilizada para la descarga no coincide con el nombre de dominio configurado en el componente.

Siga Pull images within the same account para verificar la configuración.

Si la descarga sigue fallando después de confirmar que la configuración es correcta, es posible que un campo imagePullSecrets especificado manualmente en el YAML de la carga de trabajo esté entrando en conflicto con el componente sin contraseña. Elimine el campo imagePullSecrets, elimine el pod y vuelva a crearlo.

¿Por qué los contenedores no se inician en nuevos nodos tras habilitar la aceleración de imágenes del node pool?

Después de habilitar Container Image Acceleration para un node pool, podría aparecer el siguiente error:

failed to create containerd container: failed to attach and mount for snapshot 46: failed to enable target for /sys/kernel/config/target/core/user_99999/dev_46, failed:failed to open remote file as tar file xxxx

Este error ocurre porque Container Image Acceleration requiere que el componente aliyun-acr-acceleration-suite esté instalado y que se hayan configurado las credenciales de descarga para imágenes privadas. Consulte Configure container image pull credentials.