Bonnes pratiques relatives à la gestion des ressources dans Azure Kubernetes Services (AKS) pour le développeur d’applications

Quand vous développez et exécutez des applications dans Azure Kubernetes Service (AKS), vous devez tenir compte de quelques points clés. La façon dont vous gérez vos déploiements d’application peut impacter négativement l’expérience des utilisateurs finaux. Pour réussir, gardez à l’esprit ces quelques meilleures pratiques relatives au développement et à l’exécution d’applications dans AKS.

Cet article se concentre sur l’exécution de votre cluster et de vos charges de travail du point de vue d’un développeur d’applications. Pour accéder aux bonnes pratiques en matière d’administration, consultez les bonnes pratiques de l’opérateur de cluster relatives à l’isolation et à la gestion de ressources dans Azure Kubernetes Service (AKS). Dans cet article, vous apprenez :

  • Les demandes et les limites des ressources de pod.
  • Les moyens de développer et de déployer des applications avec Bridge to Kubernetes et Visual Studio Code.

À définir les demandes et limites de ressources de pod

Conseils sur les bonnes pratiques

Définissez des demandes et des limites de pods sur tous les pods dans vos manifestes YAML. Si le cluster AKS utilise des quotas de ressources et que vous ne définissez pas ces valeurs, votre déploiement peut être rejeté.

Utilisez les demandes et les limites de pods pour gérer les ressources de calcul au sein d’un cluster AKS. Les demandes et les limites de pods informent le planificateur Kubernetes des ressources de calcul à attribuer à un pod.

Demandes d’UC/de mémoire de pods

Les demandes de pods définissent une quantité fixe d’UC et de mémoire dont le pod a besoin régulièrement.

Dans les spécifications de votre pod, il est recommandé et essentiel de définir ces requêtes et limites en fonction des informations ci-dessus. Si vous n’incluez pas ces valeurs, le planificateur Kubernetes ne peut pas prendre en compte les ressources dont vos applications ont besoin pour faciliter la planification des décisions.

Surveillez les performances de votre application pour ajuster les demandes de pods.

  • Si vous sous-estimez les demandes de pods, votre application peut voir ses performances se dégrader en raison de la surplanification d’un nœud.
  • Si les demandes sont surestimées, votre application peut avoir des difficultés à être planifiées.

Limites d’UC/de mémoire de pods**

Les limites de pods définissent la quantité maximale d’UC et de mémoire qu’un pod peut utiliser.

  • Les limites de mémoire définissent quels pods doivent être tués lorsque les nœuds sont instables en raison de ressources insuffisantes. Sans les limites appropriées, les pods seront tués jusqu’à ce que la pression sur les ressources diminue.
  • Bien qu’un pod puisse dépasser périodiquement la limite d’UC, le pod ne sera pas tué pour l’avoir dépassée.

Les limites de pods définissent le moment où un pod perd le contrôle de la consommation des ressources. Lorsque la limite est dépassée, le pod est destiné à être tué. Ce comportement maintient l’intégrité du nœud et réduit l’impact sur les pods partageant le nœud. Si vous ne définissez pas de limite de pod, elle est définie par défaut sur la valeur disponible la plus élevée sur un nœud donné.

Évitez de définir une limite de pods supérieure à ce que vos nœuds peuvent prendre en charge. Chaque nœud AKS réserve une quantité fixe d’UC et de mémoire pour les principaux composants de Kubernetes. Votre application peut tenter de consommer trop de ressources sur le nœud pour que les autres pods s’exécutent correctement.

Supervisez les performances de votre application à différents moments de la journée ou de la semaine. Déterminez les pics de demande et alignez les limites de pods sur les ressources requises pour répondre au maximum de besoins.

Important

Dans les spécifications de votre pod, définissez ces demandes et ces limites en fonction des informations ci-dessus. Le fait de ne pas inclure ces valeurs empêche le planificateur Kubernetes de comptabiliser les ressources dont vos applications ont besoin pour faciliter la planification des décisions.

Si le planificateur place un pod sur un nœud dont les ressources sont insuffisantes, cela entraîne la dégradation des performances de l’application. Les administrateurs de clusters doivent définir des quotas de ressources sur un espace de noms qui vous oblige à définir des demandes et des limites de ressources. Pour plus d’informations, consultez Quotas de ressources sur des clusters AKS.

Quand vous définissez une demande ou une limite d’UC, la valeur est mesurée en unités d’UC.

  • Une UC de 1.0 équivaut à un cœur de processeur virtuel sous-jacent sur le nœud.
    • La même mesure est utilisée pour les GPU.
  • Vous pouvez définir des fractions mesurées en millicœurs. Par exemple, 100 m correspond à 0,1 pour un cœur de processeur virtuel sous-jacent.

Dans l’exemple de base suivant pour un pod NGINX, le pod demande 100m de temps UC et 128Mi de mémoire. Les limites de ressources pour le pod sont définies avec 250m comme UC et 256Mi comme mémoire :

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 250m
        memory: 256Mi

Pour plus d’informations sur les mesures et affectations de ressources, consultez Gestion des ressources de calcul pour les conteneurs.

Développer et déboguer des applications sur un cluster AKS

Conseils sur les bonnes pratiques

Les équipes de développement doivent déployer et déboguer leurs applications sur un cluster AKS à l’aide de Bridge to Kubernetes.

Avec Bridge to Kubernetes, vous pouvez développer, déboguer et tester les applications directement sur un cluster AKS. Les développeurs d’une même équipe collaborent pour générer et tester l’application tout au long de son cycle de vie. Vous pouvez continuer à utiliser les outils existants tels que Visual Studio ou Visual Studio Code avec l’extension Bridge to Kubernetes.

L’utilisation du processus de développement et de test intégré à Bridge to Kubernetes évite de recourir à des environnements de test locaux tels que minikube. Au lieu de cela, vous développez et testez sur un cluster AKS, même les clusters sécurisés et isolés.

Notes

Bridge to Kubernetes est destiné à être utilisé avec les applications qui s’exécutent sur les nœuds et pods Linux.

Utiliser l’extension Visual Studio Code (VS Code) pour Kubernetes

Conseils sur les bonnes pratiques

Installez et utilisez l’extension VS Code pour Kubernetes quand vous écrivez des manifestes YAML. Vous pouvez également utiliser l’extension en tant que solution de déploiement intégrée, ce qui peut être utile pour les propriétaires d’applications qui interagissent rarement avec le cluster AKS.

L’extension Visual Studio Code pour Kubernetes vous permet de développer et déployer des applications sur AKS. L’extension fournit :

  • IntelliSense pour les ressources Kubernetes, les charts Helm et les modèles.

  • Des capacités de navigation, de déploiement et de modification pour les ressources Kubernetes à partir de VS Code.

  • Une vérification IntelliSense pour les demandes ou limites de ressources définies dans les spécifications de pod :

    Avertissement de l’extension VS Code pour Kubernetes concernant des limites de mémoire manquantes

Étapes suivantes

Dans cet article, nous avons traité de la façon d’exécuter votre cluster et vos charges de travail du point de vue d’un opérateur de cluster. Pour accéder aux bonnes pratiques en matière d’administration, consultez les bonnes pratiques de l’opérateur de cluster relatives à l’isolation et à la gestion de ressources dans Azure Kubernetes Service (AKS).

Pour implémenter quelques-unes de ces bonnes pratiques, consultez les articles suivants :