Meilleures pratiques en matière de déploiement et de fiabilité de cluster pour AKS (Azure Kubernetes Service)

Cet article fournit les meilleures pratiques en matière de fiabilité du cluster, implémentées à la fois au niveau du déploiement et du cluster pour vos charges de travail AKS (Azure Kubernetes Service). L’article est destiné aux opérateurs de cluster et aux développeurs responsables du déploiement et de la gestion d’applications dans AKS.

Les meilleures pratiques de cet article sont organisées en plusieurs catégories :

Meilleures pratiques au niveau du déploiement

Les meilleures pratiques au niveau du déploiement suivantes permettent de garantir la haute disponibilité et la fiabilité de vos charges de travail AKS. Il s’agit de configurations locales que vous pouvez implémenter dans les fichiers YAML de vos pods et déploiements.

Budgets d’interruption de pod

Conseils sur les bonnes pratiques

Utilisez des budgets d’interruption de pod afin de veiller à ce qu’un nombre minimal de pods restent disponibles pendant les interruptions volontaires, telles que les opérations de mise à niveau, ou les suppressions accidentelles de pods.

Les budgets d’interruption de pod vous permettent de définir la façon dont les déploiements ou les jeux de réplicas répondent pendant les interruptions volontaires, telles que les opérations de mise à niveau, ou les suppressions accidentelles de pods. Grâce à eux, vous pouvez définir un nombre minimal ou maximal de ressources indisponibles. Les budgets d’interruption de pod affectent uniquement l’API Éviction pour les interruptions volontaires.

Par exemple, supposez que vous devez effectuer une mise à niveau de cluster et que vous avez déjà défini un budget d’interruption de pod. Avant d’effectuer la mise à niveau du cluster, le planificateur Kubernetes garantit que le nombre minimal de pods défini dans le budget d’interruption de pod est disponible. Si la mise à niveau doit entraîner la chute du nombre de pods disponibles au-dessous du minimum défini dans les budgets d’interruption de pod, le planificateur planifie des pods supplémentaires sur d’autres nœuds avant d’autoriser la poursuite de la mise à niveau. Si vous ne définissez pas de budget d’interruption de pod, le planificateur n’a aucune contrainte quant au nombre de pods qui peuvent être indisponibles pendant la mise à niveau, ce qui peut entraîner un manque de ressources et des pannes de cluster potentielles.

Dans l’exemple de fichier de définition de budget d’interruption de pod suivant, le champ minAvailable définit le nombre minimal de pods qui doivent rester disponibles pendant les interruptions volontaires. La valeur peut être un nombre absolu (par exemple, 3) ou un pourcentage du nombre souhaité de pods (par exemple, 10 %).

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
   name: mypdb
spec:
   minAvailable: 3 # Minimum number of pods that must remain available during voluntary disruptions
   selector:
    matchLabels:
      app: myapp

Pour plus d’informations, consultez Planifier la disponibilité à l’aide de budgets d’interruption de pod et Specifying a Disruption Budget for your Application.

Limites du processeur et de la mémoire des pods

Conseils sur les bonnes pratiques

Définissez des limites de processeur et de mémoire pour tous les pods, afin de veiller à ce qu’ils ne consomment pas toutes les ressources sur un nœud et à fournir une protection pendant les menaces de service, telles que les attaques DDoS.

Les limites de processeur et de mémoire de pod définissent la quantité maximale de processeur et de mémoire qu’un pod peut utiliser. Lorsqu’un pod dépasse ses limites définies, il est marqué pour la suppression. Pour plus d’informations, consultez CPU resource units in Kubernetes et Memory resource units in Kubernetes.

La définition de limites de processeur et de mémoire vous permet de maintenir l’intégrité des nœuds et de réduire l’impact sur les autres pods sur le nœud. É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. Si vous définissez une limite de pod supérieure à celle prise en charge par le nœud, votre application risque d’essayer de consommer trop de ressources et d’affecter négativement d’autres pods sur le nœud. Les administrateurs de clusters doivent définir des quotas de ressources sur un espace de noms, ce qui implique de définir des demandes et des limites de ressources. Pour plus d’informations, consultez Appliquer des quotas de ressources dans AKS.

Dans l’exemple de fichier de définition de pod suivant, la section resources définit les limites de processeur et de mémoire pour le pod :

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

kubectl describe node <node-name>

# Example output
Capacity:
 cpu:                8
 ephemeral-storage:  129886128Ki
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             32863116Ki
 pods:               110
Allocatable:
 cpu:                7820m
 ephemeral-storage:  119703055367
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             28362636Ki
 pods:               110

Pour plus d’informations, consultez Assign CPU Resources to Containers and Pods et Assign Memory Resources to Containers and Pods.

Crochets de pré-arrêt

Conseils sur les bonnes pratiques

Le cas échéant, utilisez des crochets de pré-arrêt afin de garantir l’arrêt normal d’un conteneur.

Un crochet PreStop est appelé juste avant l’arrêt d’un conteneur dû à une requête d’API ou à un événement de gestion, tel que la préemption, la contention de ressources ou une défaillance de probe liveness/démarrage. Un appel au crochet PreStop échoue si le conteneur est déjà à l’état Arrêté ou Terminé, et le crochet doit se terminer avant l’envoi du signal TERM destiné à arrêter le conteneur. Le compte à rebours de la période de grâce d’arrêt du pod commence avant l’exécution du crochet PreStop. Par conséquent, le conteneur s’arrête finalement dans les limites de la période de grâce d’arrêt.

L’exemple de fichier de définition de pod suivant montre comment utiliser un crochet PreStop pour garantir l’arrêt normal d’un conteneur :

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]

Pour plus d’informations, consultez Container lifecycle hooks et Termination of Pods.

maxUnavailable

Conseils sur les bonnes pratiques

Définissez le nombre maximal de pods qui peuvent être indisponibles pendant une mise à jour propagée à l’aide du champ maxUnavailable dans votre déploiement, afin de veiller à ce qu’un nombre minimal de pods restent disponibles pendant la mise à niveau.

Le champ maxUnavailable spécifie le nombre maximal de pods qui peuvent être indisponibles pendant le processus de mise à jour. La valeur peut être un nombre absolu (par exemple, 3) ou un pourcentage du nombre souhaité de pods (par exemple, 10 %). maxUnavailable se rapporte à l’API Supprimer, qui est utilisée pendant les mises à jour propagées.

L’exemple de manifeste de déploiement suivant utilise le champ maxAvailable pour définir le nombre maximal de pods qui peuvent être indisponibles pendant le processus de mise à jour :

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 3
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.14.2
       ports:
       - containerPort: 80
 strategy:
   type: RollingUpdate
   rollingUpdate:
     maxUnavailable: 1 # Maximum number of pods that can be unavailable during the upgrade

Pour plus d’informations, consultez Max Unavailable.

Contraintes de répartition de topologie de pod

Conseils sur les bonnes pratiques

Utilisez des contraintes de répartition de topologie de pod pour vous assurer que les pods sont répartis sur différents nœuds ou zones pour améliorer la disponibilité et la fiabilité.

Vous pouvez utiliser des contraintes de répartition de topologie de pod pour contrôler la façon dont les pods sont répartis sur votre cluster en fonction de la topologie des nœuds et répartir des pods sur différents nœuds ou zones pour améliorer la disponibilité et la fiabilité.

L’exemple suivant de fichier de définition de pod montre comment utiliser le champ topologySpreadConstraints pour répartir des pods sur différents nœuds :

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  # Configure a topology spread constraint
  topologySpreadConstraints:
    - maxSkew: <integer>
      minDomains: <integer> # optional
      topologyKey: <string>
      whenUnsatisfiable: <string>
      labelSelector: <object>
      matchLabelKeys: <list> # optional
      nodeAffinityPolicy: [Honor|Ignore] # optional
      nodeTaintsPolicy: [Honor|Ignore] # optional

Pour plus d’informations, consultez Contraintes de répartition de topologie de pod.

Probes readiness, liveness et de démarrage

Conseils sur les bonnes pratiques

Configurez des probes readiness, liveness et de démarrage, le cas échéant, afin d’améliorer la résilience pour les charges élevées et de réduire les redémarrages de conteneurs.

Probe readiness

Dans Kubernetes, le kubelet utilise des probes readiness pour savoir quand un conteneur est prêt à accepter le trafic. Un pod est considéré comme prêt lorsque tous ses conteneurs sont prêts. Lorsqu’un pod n’est pas prêt, il est supprimé des équilibreurs de charge de service. Pour plus d’informations, consultez Readiness Probes in Kubernetes.

L’exemple de fichier de définition de pod suivant présente une configuration de probe readiness :

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

Pour plus d’informations, consultez Configurer des probes readiness.

Probe liveness

Dans Kubernetes, le kubelet utilise des probes liveness pour savoir quand redémarrer un conteneur. Si la probe liveness d’un conteneur échoue, le conteneur est redémarré. Pour plus d’informations, consultez Liveness Probes in Kubernetes.

L’exemple de fichier de définition de pod suivant présente une configuration de probe liveness :

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy

Un autre genre de probe liveness utilise une requête HTTP GET. L’exemple de fichier de définition de pod suivant présente une configuration de probe liveness avec requête HTTP GET :

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

Pour plus d’informations, consultez Configurer des probes liveness et Define a liveness HTTP request.

Sondes de démarrage

Dans Kubernetes, le kubelet utilise des probes de démarrage pour savoir quand une application conteneur a démarré. Lorsque vous configurez une probe de démarrage, les probes readiness et liveness ne démarrent pas tant que la probe de démarrage n’a pas réussi, ce qui garantit que les probes readiness et liveness n’interfèrent pas avec le démarrage de l’application. Pour plus d’informations, consultez Startup Probes in Kubernetes.

L’exemple de fichier de définition de pod suivant présente une configuration de probe de démarrage :

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

Applications multiréplicas

Conseils sur les bonnes pratiques

Déployez au moins deux réplicas de votre application afin de garantir la haute disponibilité et la résilience dans les scénarios de défaillance de nœud.

Dans Kubernetes, vous pouvez utiliser le champ replicas dans votre déploiement pour spécifier le nombre de pods que vous souhaitez exécuter. L’exécution de plusieurs instances de votre application permet de garantir la haute disponibilité et la résilience dans les scénarios de défaillance de nœud. Si vous avez activé les zones de disponibilité, vous pouvez utiliser le champ replicas pour spécifier le nombre de pods que vous souhaitez exécuter sur plusieurs zones de disponibilité.

L’exemple de fichier de définition de pod suivant montre comment utiliser le champ replicas pour spécifier le nombre de pods que vous souhaitez exécuter :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Pour plus d’informations, consultez Vue d’ensemble de la solution haute disponibilité actif-actif recommandée pour AKS et Replicas in Deployment Specs.

Meilleures pratiques au niveau du cluster et du pool de nœuds

Les meilleures pratiques au niveau du cluster et du pool de nœuds suivantes permettent de garantir la haute disponibilité et la fiabilité de vos clusters AKS. Vous pouvez implémenter ces meilleures pratiques lors de la création ou de la mise à jour de vos clusters AKS.

Zones de disponibilité

Conseils sur les bonnes pratiques

Utilisez plusieurs zones de disponibilité lors de la création d’un cluster AKS pour garantir la haute disponibilité dans les scénarios de défaillance de zone. N’oubliez pas que vous ne pouvez pas modifier la configuration des zones de disponibilité après avoir créé le cluster.

Les zones de disponibilité sont des groupes de centres de données distincts au sein d’une région. Ces zones sont suffisamment proches pour avoir des connexions à faible latence entre elles, mais suffisamment éloignées pour réduire la probabilité que plusieurs zones soient affectées par des pannes locales ou des conditions météorologiques. L’utilisation de zones de disponibilité permet de garantir la synchronisation et l’accessibilité de vos données dans les scénarios de défaillance de zone. Pour plus d’informations, consultez Running in multiple zones.

Mise à l’échelle automatique du cluster

Conseils sur les bonnes pratiques

Utilisez la mise à l’échelle automatique du cluster pour veiller à ce que votre cluster puisse gérer une charge accrue et pour réduire les coûts pendant les périodes de faible charge.

Pour suivre le rythme des demandes applicatives dans AKS, vous devrez peut-être ajuster le nombre de nœuds qui exécutent vos charges de travail. Le composant de mise à l’échelle automatique de cluster peut surveiller les pods de votre cluster qui ne peuvent pas être planifiés en raison de contraintes de ressources. Lorsque la mise à l’échelle automatique détecte des problèmes, elle augmente le nombre de nœuds dans le pool de nœuds pour répondre à la demande de l’application. Les nœuds sont également régulièrement vérifiés. En l’absence de pods exécutés, le nombre de nœuds est réduit au besoin. Pour plus d’informations, consultez Mise à l’échelle automatique du cluster dans AKS.

Vous pouvez utiliser le paramètre --enable-cluster-autoscaler lors de la création d’un cluster AKS pour activer l’autoscaler de cluster, comme illustré dans l’exemple suivant :

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 2 \
    --vm-set-type VirtualMachineScaleSets \
    --load-balancer-sku standard \
    --enable-cluster-autoscaler  \
    --min-count 1 \
    --max-count 3 \
    --generate-ssh-keys

Vous pouvez également activer l’autoscaler de cluster sur un pool de nœuds existant et configurer une plus grande précision dans les détails de l’autoscaler de cluster en changeant les valeurs par défaut dans le profil d’autoscaler à l’échelle du cluster.

Pour plus d’informations, consultez Utiliser l’autoscaler de cluster dans AKS.

Standard Load Balancer

Conseils sur les bonnes pratiques

Utilisez Standard Load Balancer pour fournir une fiabilité et des ressources accrues, une prise en charge de plusieurs zones de disponibilité, des sondes HTTP et des fonctionnalités parmi plusieurs centres de données.

Dans Azure, la référence SKU Standard Load Balancer est conçue pour être équipée pour l’équilibrage de charge du trafic de couche réseau lorsque des performances élevées et une faible latence sont nécessaires. Standard Load Balancer route le trafic dans et entre les régions et vers les zones de disponibilité pour une résilience élevée. La référence SKU Standard est la référence SKU recommandée et par défaut à utiliser lors de la création d’un cluster AKS.

L’exemple suivant montre un manifeste de service LoadBalancer qui utilise Standard Load Balancer :

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-ipv4 # Service annotation for an IPv4 address
  name: azure-load-balancer
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-load-balancer

Pour plus d’informations, consultez Utiliser un équilibreur de charge standard dans AKS.

Pools de nœuds système

Utiliser des pools de nœuds système dédiés

Conseils sur les bonnes pratiques

Utilisez des pools de nœuds système pour veiller à ce qu’aucune autre application utilisateur ne s’exécute sur les mêmes nœuds, ce qui peut entraîner une pénurie de ressources et avoir un impact sur les pods système.

Utilisez des pools de nœuds système dédiés pour garantir qu’aucune autre application utilisateur ne s’exécute sur les mêmes nœuds, ce qui peut entraîner une pénurie de ressources et des pannes de cluster potentielles dues à des conditions de concurrence. Pour utiliser un pool de nœuds système dédié, vous pouvez utiliser la teinte CriticalAddonsOnly sur le pool de nœuds système. Pour plus d’informations, consultez Utiliser des pools de nœuds système dans AKS.

Mise à l’échelle automatique pour les pools de nœuds système

Conseils sur les bonnes pratiques

Configurez l’autoscaler pour les pools de nœuds système afin de définir des limites d’échelle minimales et maximales pour le pool de nœuds.

Utilisez l’autoscaler sur les pools de nœuds pour configurer les limites minimales et maximales d’échelle pour le pool de nœuds. Le pool de nœuds système doit toujours être en mesure de se mettre à l’échelle pour répondre aux demandes des pods système. Si le pool de nœuds système ne peut pas être mis à l’échelle, le cluster manque de ressources pour aider à gérer la planification, la mise à l’échelle et l’équilibrage de charge, et il risque de ne plus répondre.

Pour plus d’informations, consultez Utiliser l’autoscaler de cluster sur des pools de nœuds.

Au moins trois nœuds par pool de nœuds système

Conseils sur les bonnes pratiques

Veillez à ce que les pools de nœuds système aient au moins trois nœuds, afin de garantir la résilience dans les scénarios de blocage/mise à niveau, qui peuvent entraîner le redémarrage ou l’arrêt des nœuds.

Les pools de nœuds système sont utilisés pour exécuter des pods système, tels que kube-proxy, coredns et le plug-in Azure CNI. Nous vous recommandons de veiller à ce que les pools de nœuds système aient au moins trois nœuds, afin de garantir la résilience dans les scénarios de blocage/mise à niveau, qui peuvent entraîner le redémarrage ou l’arrêt des nœuds. Pour plus d’informations, consultez Gérer des pools de nœuds système dans AKS.

Accélération réseau

Conseils sur les bonnes pratiques

Utilisez les performances réseau accélérées pour fournir une latence plus faible, une diminution de l’instabilité et une réduction de l’utilisation du processeur sur vos machines virtuelles.

Les Performances réseau accélérées activent la virtualisation SR-IOV (Single Root I/O Virtualization) sur les types de machines virtuelles pris en charge, ce qui améliore considérablement les performances réseau.

Le diagramme suivant illustre la façon dont deux machines virtuelles communiquent avec et sans Performances réseau accélérées :

Pour plus d’informations, consultez Vue d’ensemble des performances réseau accélérées.

Versions d’images

Conseils sur les bonnes pratiques

Les images ne doivent pas utiliser la balise latest.

Étiquettes des images conteneur

L’utilisation de la balise latest pour les images conteneur peut entraîner un comportement imprévisible, et rend difficile le suivi de la version de l’image en cours d’exécution dans votre cluster. Réduisez ces risques en intégrant et en exécutant des outils d’analyse et de correction dans vos conteneurs au moment de la génération et du runtime. Pour plus d’informations, consultez Meilleures pratiques en matière de gestion des images conteneur dans AKS.

Mises à niveau d’images de nœud

AKS fournit plusieurs canaux de mise à niveau automatique pour les mises à niveau d’images de système d’exploitation de nœud. Vous pouvez utiliser ces canaux pour contrôler le calendrier des mises à niveau. Nous vous recommandons de rejoindre ces canaux de mise à niveau automatique afin de vous assurer que vos nœuds exécutent les derniers correctifs et mises à jour de sécurité. Pour plus d’informations, consultez Mettre automatiquement à niveau des images de système d’exploitation de nœud dans AKS.

Niveau Standard pour les charges de travail de production

Conseils sur les bonnes pratiques

Utilisez le niveau Standard pour les charges de travail de production afin d’accroître la fiabilité et les ressources du cluster, et de disposer d’une prise en charge allant jusqu’à 5000 nœuds dans un cluster et d’un contrat SLA de durée de bon fonctionnement activé par défaut. Si vous avez besoin de LTS, envisagez d’utiliser le niveau Premium.

Le niveau Standard pour AKS (Azure Kubernetes Service) fournit un contrat de niveau de service (SLA) de 99,9 % soutenu financièrement pour vos charges de travail de production. Le niveau Standard fournit également une fiabilité et des ressources de cluster accrues, une prise en charge allant jusqu’à 5000 nœuds dans un cluster, et un contrat SLA de durée de bon fonctionnement activé par défaut. Pour plus d’informations, consultez Niveaux tarifaires pour la gestion des clusters AKS.

Azure CNI pour l’allocation dynamique d’adresses IP

Conseils sur les bonnes pratiques

Configurez Azure CNI pour l’allocation dynamique d’adresses IP, afin de bénéficier d’une meilleure utilisation des adresses IP et de prévenir l’épuisement des adresses IP pour les clusters AKS.

La capacité d’allocation dynamique d’adresses IP dans Azure CNI alloue des adresses IP de pod à partir d’un sous-réseau distinct du sous-réseau hébergeant le cluster AKS, et offre les avantages suivants :

• Meilleure utilisation des adresses IP : les adresses IP sont allouées de façon dynamique aux pods du cluster à partir du sous-réseau de pod. Cela permet d’améliorer l’utilisation des adresses IP dans le cluster par rapport à la solution de CNI traditionnelle, qui effectue une allocation statique des adresses IP pour chaque nœud.
• Scalabilité et flexibilité : les sous-réseaux de nœud et de pod peuvent être mis à l’échelle indépendamment. Un seul sous-réseau de pod peut être partagé entre plusieurs pools de nœuds d’un cluster ou plusieurs clusters AKS déployés dans le même réseau virtuel. Vous pouvez également configurer un sous-réseau de pod distinct pour un pool de nœuds.
• Hautes performances : Les adresses IP du réseau virtuel étant affectées aux pods, ces derniers disposent d’une connectivité directe vers d’autres pods du cluster et des ressources dans le réseau virtuel. La solution prend en charge des clusters très volumineux sans dégradation des performances.
• Stratégies de réseau virtuel distinctes pour les pods : étant donné que les pods ont un sous-réseau distinct, vous pouvez configurer ceux-ci des stratégies de réseau virtuel distinctes, qui diffèrent des stratégies de nœud. Cela permet de nombreux scénarii utiles, tels que l’autorisation de la connectivité Internet uniquement pour les pods et pas pour les nœuds, la correction de l’adresse IP source pour un pod dans un pool de nœuds à l’aide d’Azure NAT Gateway, ainsi que l’utilisation de groupes de sécurité réseau pour filtrer le trafic entre les pools de nœuds.
• Stratégies réseau Kubernetes : les stratégies réseau Azure et Calico fonctionnent avec cette nouvelle solution.

Pour plus d’informations, consultez Configurer la mise en réseau Azure CNI pour l’allocation dynamique des adresses IP et la prise en charge améliorée des sous-réseaux.

Machines virtuelles de référence SKU v5

Conseils sur les bonnes pratiques

Utilisez des références SKU de machine virtuelle v5 pour améliorer les performances pendant et après les mises à jour, réduire l’impact global, et accroître la fiabilité de la connexion pour vos applications.

Pour les pools de nœuds dans AKS, utilisez des machines virtuelles de référence SKU v5 avec des disques de système d’exploitation éphémères afin de fournir des ressources de calcul suffisantes pour les pods kube-system. Pour plus d’informations, consultez Meilleures pratiques pour les performances et la mise à l’échelle de charges de travail volumineuses dans AKS.

Ne pas utiliser de machines virtuelles de série B

Conseils sur les bonnes pratiques

N’utilisez pas de machines virtuelles de série B pour les clusters AKS, car elles présentent des performances faibles et ne fonctionnent pas correctement avec AKS.

Les machines virtuelles de série B offrent de faibles performances et ne fonctionnent pas correctement avec AKS. Nous vous recommandons plutôt d’utiliser des machines virtuelles de référence SKU v5.

Disques Premium

Conseils sur les bonnes pratiques

Utilisez des disques Premium pour obtenir une disponibilité de 99,9 % dans une machine virtuelle.

Les disques Premium Azure offrent une latence de disque d’une taille inférieure à la milliseconde, ainsi qu’un débit et des IOPS élevés. Les disques Premium sont conçus pour fournir des performances de disque à faible latence, hautes performances et cohérentes pour les machines virtuelles.

L’exemple de manifeste YAML suivant montre une définition de classe de stockage pour un disque Premium :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: premium2-disk-sc
parameters:
   cachingMode: None
   skuName: PremiumV2_LRS
   DiskIOPSReadWrite: "4000"
   DiskMBpsReadWrite: "1000"
provisioner: disk.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true

Pour plus d’informations, consultez Utiliser des disques Azure SSD Premium v2 sur AKS.

Container Insights

Conseils sur les bonnes pratiques

Activez Container Insights pour superviser et diagnostiquer les performances de vos applications conteneurisées.

Container Insights est une fonctionnalité d’Azure Monitor qui collecte et analyse les journaux de conteneur à partir d’AKS. Vous pouvez analyser les données collectées avec une collection de vues et de classeurs prédéfinis.

Vous pouvez activer le monitoring Container Insights sur votre cluster AKS à l’aide de différentes méthodes. L’exemple suivant montre comment activer le monitoring Container Insights sur un cluster existant à l’aide d’Azure CLI :

az aks enable-addons -a monitoring --name myAKSCluster --resource-group myResourceGroup

Pour plus d’informations, consultez Activer le monitoring pour des clusters Kubernetes.

Azure Policy

Conseils sur les bonnes pratiques

Imposez le respect des exigences de sécurité et de conformité pour vos clusters AKS à l’aide d’Azure Policy.

Vous pouvez appliquer des stratégies de sécurité intégrées sur vos clusters AKS à l’aide d’Azure Policy. Azure Policy aide à appliquer les normes organisationnelles et à évaluer la conformité à grande échelle. Une fois que vous avez installé le module complémentaire Azure Policy pour AKS, vous pouvez appliquer des définitions de stratégie spécifiques ou des groupes de définitions de stratégie appelés initiatives à vos clusters.

Pour plus d’informations, consultez Sécuriser vos clusters AKS avec Azure Policy.

Étapes suivantes

Cet article s’est concentré sur les meilleures pratiques pour le déploiement et la fiabilité des clusters AKS (Azure Kubernetes Service). Pour découvrir davantage de meilleures pratiques, consultez les articles suivants :

• Vue d’ensemble de la haute disponibilité et récupération d’urgence pour AKS
• Exécuter des clusters AKS à grande échelle
• Architecture de référence pour un cluster AKS