Container Service for Kubernetes:FAQ sur les charges de travail

Comment déployer une application conteneurisée dans un cluster ACK ?

Le déploiement d'une application conteneurisée comprend quatre phases :

1. Rédigez le code de votre application dans le langage de votre choix.

2. Construisez une image de conteneur à l'aide d'un Dockerfile, un fichier texte qui regroupe votre code et toutes ses dépendances dans un artefact de livraison portable. Une image de conteneur est plus complète que les packages traditionnels tels que les fichiers JAR, WAR ou RPM, car elle associe l'application à tous les fichiers requis par le moteur d'exécution du conteneur. Utilisez cette image pour démarrer un conteneur, qui correspond à l'application en cours d'exécution. Pour obtenir des instructions détaillées, consultez la rubrique Créer, empaqueter et exécuter des images à l'aide d'un Dockerfile.

3. Poussez l'image vers un registre. Container Registry (ACR) stocke, gère, distribue et sert les images. ACR propose deux éditions. Pour plus d'informations, consultez la rubrique Présentation de Container Registry ACR.

   • Édition personnelle — destinée aux développeurs individuels

   • Édition Entreprise — destinée aux clients entreprise

4. Déployez les charges de travail dans ACK pour exécuter votre application conteneurisée. ACK gère le cycle de vie complet des charges de travail conteneurisées : planification des pods sur des nœuds spécifiques, mise à l'échelle en fonction des variations de charge, etc. Pour plus d'informations, consultez la rubrique Charges de travail.

Pourquoi les pulls d'images prennent-ils trop de temps ou échouent-ils ?

Vérifiez les points suivants en fonction de la source du pull :

Pull via le réseau public

• Vérifiez que votre cluster dispose d'un accès au réseau public. Consultez la rubrique Activer l'accès au réseau public pour un cluster.

• Vérifiez que votre registre d'images autorise également l'accès public. Pour un exemple avec ACR, consultez la rubrique Configurer le contrôle d'accès au réseau public pour ACR.

• Vérifiez si la bande passante de l'adresse IP publique est définie sur une valeur trop faible.

Pull depuis ACR

• Vérifiez que le secret de pull d'image est correct. Consultez la rubrique Comment utiliser imagePullSecrets ?.

• Si vous utilisez le composant de pull sans mot de passe, vérifiez qu'il est configuré correctement. Consultez les rubriques Effectuer des pulls d'images au sein du même compte et Effectuer des pulls d'images entre comptes.

Comment résoudre les problèmes d'application dans ACK ?

Les défaillances des applications proviennent généralement des pods, des contrôleurs (Deployment, StatefulSet, DaemonSet) ou des Services. Commencez par identifier la couche concernée, puis suivez les étapes ci-dessous.

kubectl get endpoints <service_name>

Comment mettre à jour Helm manuellement ?

Le composant côté serveur Tiller de Helm v2 présente des vulnérabilités de sécurité connues qui permettent aux attaquants d'installer des applications non autorisées dans les clusters. Effectuez une mise à niveau vers Helm v3. Consultez la rubrique Mise à niveau de Helm v2 vers Helm v3.

Comment effectuer des pulls d'images depuis une instance Container Registry Édition Entreprise située en Chine continentale vers un cluster ACK situé hors de Chine continentale ?

Achetez les instances Container Registry Édition Entreprise suivantes :

• Une instance Standard ou Premium dans la région située en Chine continentale

• Une instance Basic dans la région située hors de Chine continentale

Utilisez ensuite une instance de synchronisation pour répliquer les images de la région située en Chine continentale vers la région située hors de Chine continentale. Consultez la rubrique Instance de synchronisation au sein du même compte. Après la synchronisation, récupérez l'adresse du registre depuis l'instance Édition Entreprise située hors de Chine continentale et utilisez-la lors de la création d'applications dans ACK.

L'Édition personnelle d'ACR offre des vitesses de synchronisation plus lentes. Pour les référentiels autogérés, vous devez acheter Global Acceleration (GA) pour accélérer les pulls d'images, ce qui augmente les coûts. L'Édition Entreprise de Container Registry est l'option recommandée. Consultez la rubrique Informations sur la facturation .

Comment effectuer des mises à jour progressives sans interruption de service ?

Lors du remplacement des pods pendant une mise à jour progressive, un délai de quelques secondes survient avant que les modifications des pods ne soient synchronisées avec l'instance Classic Load Balancer (CLB). Cela peut provoquer des erreurs 5XX temporaires. Configurez l'arrêt gracieux pour réaliser des mises à jour progressives sans temps d'arrêt. Consultez la rubrique Implémenter des déploiements progressifs sans temps d'arrêt.

Comment obtenir une image de conteneur pour une charge de travail ?

Pour connaître les prérequis et obtenir des conseils sur le pull d'une image de conteneur, consultez la rubrique Pull d'image.

Comment redémarrer un conteneur ?

Kubernetes ne prend pas en charge le redémarrage direct de conteneurs individuels. Supprimez plutôt le pod : le contrôleur (Deployment, DaemonSet, etc.) créera automatiquement un remplacement.

1. Listez les pods pour trouver celui à redémarrer :

   kubectl get pods

2. Supprimez le pod :

   kubectl delete pod <pod-name>

3. Vérifiez que le nouveau pod est en cours d'exécution :

   kubectl get pods

   Confirmez que l'état du pod est Running.

En production, gérez les conteneurs via des objets de niveau supérieur tels que les ReplicaSets et les Deployments plutôt qu'en manipulant directement les pods. Cela permet de préserver la cohérence de l'état du cluster.

Comment modifier le namespace d'un Deployment ?

Le déplacement d'un Deployment vers un autre namespace nécessite également la mise à jour manuelle des ressources dépendantes — persistent volume claims (PVC), ConfigMaps et Secrets — vers le nouveau namespace.

1. Exportez la configuration du Deployment :

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

2. Modifiez le fichier deployment.yaml et remplacez la valeur namespace :

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

3. Appliquez la configuration mise à jour :

   kubectl apply -f deployment.yaml

4. Vérifiez que le Deployment s'exécute dans le nouveau namespace :

   kubectl get deploy -n new-namespace

Comment exposer les informations du pod aux conteneurs en cours d'exécution ?

ACK suit les spécifications natives de la communauté Kubernetes. Deux méthodes sont prises en charge :

• Variables d'environnement — transmettez les informations du pod à un conteneur via des variables d'environnement. Consultez la page Exposer les informations du pod aux conteneurs via des variables d'environnement.

• Fichiers — montez les informations du pod sous forme de fichiers à l'intérieur du conteneur à l'aide du volume Downward API. Consultez la page Exposer les informations du pod aux conteneurs via des fichiers.

Comment utiliser imagePullSecrets ?

Les instances ACR Édition personnelle créées le 9 septembre 2024 ou après cette date ne prennent pas en charge aliyun-acr-credential-helper. Stockez vos identifiants dans un Secret Kubernetes et référencez-le via imagePullSecrets.

Étape 1 : Créer le Secret

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

Étape 2 : Référencer le Secret

Choisissez l'une des méthodes suivantes :

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

Vérification

Après avoir appliqué la configuration, confirmez que le pod est en cours d'exécution :

kubectl get pods

Pourquoi les pulls échouent-ils toujours après la configuration du composant sans mot de passe ?

Le composant de pull sans mot de passe peut être mal configuré. Vérifiez ces deux causes courantes :

• Les informations de l'instance dans le composant ne correspondent pas à l'instance ACR.

• L'adresse de l'image utilisée pour le pull ne correspond pas au nom de domaine configuré dans le composant.

Suivez les instructions de la rubrique Effectuer des pulls d'images au sein du même compte pour vérifier la configuration.

Si le pull échoue toujours alors que la configuration est correcte, il est possible qu'un champ imagePullSecrets spécifié manuellement dans le YAML de la charge de travail entre en conflit avec le composant sans mot de passe. Supprimez le champ imagePullSecrets, puis supprimez et recréez le pod.

Pourquoi les conteneurs ne démarrent-ils pas sur les nouveaux nœuds après l'activation de l'accélération d'images du pool de nœuds ?

Après avoir activé Container Image Acceleration pour un pool de nœuds, vous pouvez rencontrer l'erreur suivante :

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

Cette erreur se produit car Container Image Acceleration nécessite l'installation du composant aliyun-acr-acceleration-suite et la configuration des identifiants de pull pour les images privées. Consultez la rubrique Configurer les identifiants de pull d'images de conteneur.