Partager via

Considérations relatives à la gestion des opérations pour Azure Kubernetes Service

  • Article

Kubernetes est une technologie relativement nouvelle, qui évolue rapidement et dispose d’un écosystème impressionnant. Par conséquent, elle peut être difficile à gérer et à protéger.

Ligne de base des opérations pour AKS

En concevant correctement votre solution Azure Kubernetes Service (AKS) sans négliger la gestion et la supervision, vous pouvez travailler à l’excellence opérationnelle et la réussite des clients.

Remarques relatives à la conception

Tenez compte des facteurs suivants :

  • Tenez compte des limites d’AKS. Utilisez plusieurs instances AKS pour évoluer au-delà de ces limites.
  • Tenez compte des moyens d’isoler les charges de travail de manière logique dans un cluster et physiquement dans des clusters distincts.
  • Tenez compte des méthodes de contrôle de la consommation des ressources par charges de travail.
  • Tenez compte des moyens d’aider Kubernetes à comprendre l’intégrité de vos charges de travail.
  • Tenez compte des différentes tailles de machines virtuelles et de l’impact de l’utilisation de l’une ou de l’autre. Les machines virtuelles plus volumineuses peuvent gérer davantage de charge. Les machines virtuelles plus petites peuvent être facilement remplacées par d’autres lorsqu’elles ne sont pas disponibles pour une maintenance planifiée ou non planifiée. Sachez également qu’il existe des pools de nœuds et des machines virtuelles dans un groupe identique, ce qui permet d’avoir des machines virtuelles de différentes tailles dans le même cluster. Des machines virtuelles plus grandes sont plus avantageuses, car AKS réserve un plus petit pourcentage de ses ressources, ce qui rend une plus grande partie de ses ressources disponibles pour vos charges de travail.
  • Tenez compte des moyens de superviser et de journaliser AKS. Kubernetes comporte différents composants, et la supervision et la journalisation doivent fournir un aperçu de l’intégrité, des tendances et des problèmes potentiels.
  • En s’appuyant sur la supervision et la journalisation, de nombreux événements peuvent être générés par Kubernetes ou des applications exécutées au-dessus. Les alertes peuvent aider à faire la différence entre les entrées de journal à des fins historiques et celles qui nécessitent une action immédiate.
  • Tenez compte des mises à jour et des mises à niveau que vous devez effectuer. Kubernetes se compose de versions majeures, mineures et correctives. Le client doit appliquer ces mises à jour pour rester pris en charge en fonction de la stratégie dans Kubernetes en amont. Au niveau de l’hôte de travail, les correctifs du noyau du système d’exploitation peuvent nécessiter un redémarrage, que le client doit effectuer, ainsi que des mises à niveau vers de nouvelles versions de système d’exploitation. En plus de mettre à niveau manuellement un cluster, vous pouvez définir un canal de mise à niveau automatique sur votre cluster.
  • Tenez compte des limitations de ressources du cluster et des charges de travail individuelles.
  • Tenez compte des différences entre utilitaire de mise à l’échelle automatique horizontale des pods et utilitaire de mise à l’échelle automatique des clusters.
  • Envisagez de sécuriser le trafic entre les pods à l’aide de stratégies réseau et du plug-in de stratégies Azure.
  • Pour faciliter la résolution des problèmes de votre application et de vos services exécutés sur AKS, il se peut que vous deviez consulter les journaux générés par les composants du plan de contrôle. Pour cela, vous pouvez activer les journaux de ressources pour AKS, car la journalisation n’est pas activée par défaut.

Recommandations

  • Comprenez les limites d’AKS :

  • Utilisez l’isolement logique au niveau de l’espace de noms pour séparer les applications, les équipes, les environnements et les divisions. Multilocation et isolation de cluster. Les pools de nœuds peuvent également aider les nœuds ayant des spécifications différentes, et la maintenance comme Kubernetes met à niveau plusieurs pools de nœuds

  • Planifiez et appliquez des quotas de ressources au niveau de l’espace de noms. Si les pods ne définissent pas de demandes ni de limites de ressources, refusez le déploiement à l’aide de stratégies, et ainsi de suite. Cela ne s’applique pas aux pods kube-system, car tous les pods kube-system n’ont pas de demandes ou de limites. Supervisez l’utilisation des ressources et ajustez les quotas en fonction des besoins. Fonctionnalités de base du planificateur

  • Ajoutez des sondes d’intégrité à vos pods. Assurez-vous que les pods contiennent les sondes d’intégrité AKS livenessProbe, readinessProbe et startupProbe.

  • Utilisez des tailles de machines virtuelles suffisamment grandes pour contenir plusieurs instances de conteneurs afin de bénéficier des avantages d’une densité accrue, mais pas trop grande, car votre cluster ne pourra pas gérer la charge de travail d’un nœud défaillant.

  • Supprimez une solution de supervision. Azure Monitor pour Container Insights est configuré par défaut et fournit un accès facile à de nombreux insights. Vous pouvez utiliser l’intégration de Prometheus si vous souhaitez approfondir ou vous familiariser avec Prometheus. Si vous souhaitez également exécuter une application de supervision sur AKS, vous devez également utiliser Azure Monitor pour superviser cette application.

  • Utilisez les alertes de métrique Azure Monitor Container Insights pour fournir des notifications lorsque des choses nécessitent une action directe.

  • Utilisez la fonctionnalité de mise à l’échelle automatique des pools de nœuds avec l’autoscaler de pods horizontaux pour répondre aux demandes des applications et réduire les charges de pointe.

  • Utilisez Azure Advisor pour obtenir les meilleures pratiques en matière de coûts, de sécurité, de fiabilité, d’excellence opérationnelle et de performances. Utilisez également Microsoft Defender pour le cloud pour empêcher et détecter les menaces telles que les vulnérabilités d’image.

  • Utilisez Kubernetes avec Azure Arc pour gérer les clusters Kubernetes non AKS dans Azure avec Azure Policy, Defender pour le cloud, GitOps, et ainsi de suite.

  • Utilisez des demandes et des 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.

Continuité d’activité/récupération d’urgence pour protéger et récupérer AKS

Votre organisation doit concevoir des fonctionnalités de niveau plateforme Azure Kubernetes service (AKS) appropriées pour répondre à ses besoins spécifiques. Ces services d’application ont des exigences relatives à l’objectif de délai de récupération (RTO) et à l’objectif de point de récupération (RPO). Il y a de nombreux aspects à prendre en compte pour la récupération d’urgence AKS. La première étape consiste à définir un contrat de niveau de service (SLA) pour votre infrastructure et votre application. En savoir plus sur le contrat de niveau de service pour Azure Kubernetes Service (AKS). Consultez la section Détails du contrat de niveau de service pour plus d’informations sur les calculs de temps d’activité mensuels.

Remarques relatives à la conception

Tenez compte des facteurs suivants :

  • Le cluster AKS doit utiliser plusieurs nœuds dans un pool de nœuds pour fournir le niveau de disponibilité minimal pour votre application.

  • Définissez des requêtes et limites de ressources. La définition de ces limites permet à Kubernetes de :

    • Fournir efficacement des ressources de processeur et de mémoire aux pods.
    • Avoir une densité de conteneurs supérieure sur un nœud.

    Les limites permettent également d’accroître la fiabilité en réduisant les coûts moyennant une meilleure utilisation du matériel.

  • Adéquation d’AKS pour les Zones de disponibilité Azure ou les groupes à haute disponibilité.

    • Choisissez une région qui prend en charge les zones de disponibilité.
    • Les Zones de disponibilité Azure peuvent être définies uniquement lors de la création du pool de nœuds et ne sont ensuite pas modifiables. La prise en charge multizone s’applique uniquement aux pools de nœuds.
    • Pour bénéficier d’une offre zonale complète, toutes les dépendances de service doivent également prendre en charge les zones. Si un service dépendant ne prend pas en charge les zones, une défaillance de zone entraîne un échec du service.
    • Pour une disponibilité au-delà supérieure à celle des Zones de disponibilité Azure, il faut gérer plusieurs groupes AKS dans des régions jumelées différentes. Si une ressource Azure prend en charge la géoredondance, indiquez l’emplacement de la région secondaire du service redondant.

  • Vous devez connaître les recommandations relatives à la reprise d’activité dans AKS. Déterminez si elles s’appliquent aux clusters AKS que vous utilisez pour Azure Dev Spaces.

  • Créez systématiquement des sauvegardes pour les applications et les données.

    • Un service sans état peut être répliqué efficacement.
    • S’il vous faut stocker l’état dans le cluster, sauvegardez fréquemment les données dans la région jumelée. L’un des points à prendre en compte est qu’il peut être compliqué de stocker correctement l’état dans le cluster.

  • Mise à jour et maintenance du cluster.

    • Conservez toujours votre cluster à jour.
    • Tenez compte du processus de mise en version et d’obsolescence.
    • Planifiez les mises à jour et la maintenance.

  • Connectivité réseau en cas de basculement.

    • Selon vos besoins, optez pour un routeur de trafic capable de répartir le trafic entre les zones ou régions. Cette architecture déploie Azure Load Balancer, car celui-ci permet de distribuer le trafic non web entre les zones.
    • S’il vous faut répartir le trafic entre les régions, envisagez d’utiliser Azure Front Door.

  • Basculements planifiés et non planifiés.

    • Lors de la configuration de chaque service Azure, choisissez des fonctionnalités qui prennent en charge la récupération d’urgence. Par exemple, dans cette architecture, activez Azure Container Registry à des fins de géoréplication. En cas de défaillance d’une région, vous pouvez toujours extraire des images depuis la région répliquée.

  • Tenez à jour les fonctionnalités d’ingénierie DevOps pour atteindre les objectifs de niveau de service.

  • Déterminez si vous avez besoin d’un contrat de niveau de service soutenu financièrement pour le point de terminaison de votre serveur d’API Kubernetes.

Recommandations de conception

Voici les meilleures pratiques pour votre conception :

  • Utilisez trois nœuds pour le pool de nœuds système. Pour le pool de nœuds utilisateur, commencez avec au moins deux nœuds. Pour plus de disponibilité, configurez davantage de nœuds.

  • Isolez votre application des services système en la plaçant dans un pool de nœuds distinct. Ainsi, les services Kubernetes s’exécutent sur des nœuds dédiés et ne sont pas en concurrence avec d’autres services. Utilisez des balises, étiquettes et teintes pour identifier le pool de nœuds afin de planifier votre charge de travail.

  • La maintenance régulière de votre cluster, par exemple en effectuant des mises à jour en temps voulu, est cruciale pour la fiabilité. Tenez compte de la fenêtre de prise en charge des versions de Kubernetes sur AKS et planifiez vos mises à jour. Il est recommandé de surveiller également l’intégrité des pods par le biais de sondes d’intégrité.

  • Dans la mesure du possible, supprimez l’état du service dans les conteneurs. Au lieu de cela, utilisez une plateforme Azure en tant que service (PaaS) qui prend en charge la réplication multirégion.

  • Vérifier les ressources de pod. En matière de déploiements, il est vivement recommandé de spécifier les besoins en ressources de pod. Le planificateur peut ensuite planifier comme il se doit le pod. La fiabilité est amoindrie lorsque les pods ne sont pas planifiés.

  • Au sein du déploiement, configurez plusieurs réplicas afin de gérer les interruptions, telles que les défaillances matérielles. Pour les événements planifiés tels que les mises à jour et les mises à niveau, un budget d’interruption permet de s’assurer de la présence du nombre de réplicas de pods requis pour gérer la charge d’application attendue.

  • Vos applications peuvent utiliser Stockage Azure pour leurs données. Parce que vos applications sont réparties sur plusieurs clusters AKS de régions différentes, le stockage doit rester synchronisé. Voici deux méthodes courantes pour répliquer le stockage :

    • Réplication asynchrone basée sur l’infrastructure
    • Réplication asynchrone basée sur l’application

  • Estimez les limites de pod. Testez et établissez une ligne de base. Dans un premier temps, utilisez des valeurs similaires pour les demandes et les limites. Ajustez ensuite progressivement ces valeurs jusqu’à établir un seuil susceptible de provoquer une instabilité dans le cluster. Les limites de pod peuvent être spécifiées dans vos manifestes de déploiement.

    Les fonctionnalités intégrées offrent une solution à la tâche complexe de gestion des défaillances et des interruptions dans l’architecture de service. Ces configurations permettent de simplifier la conception et l’automatisation du déploiement. Lorsqu’une organisation a défini une norme pour le contrat de niveau de service, le RTO et le RPO, elle peut utiliser des services intégrés à Kubernetes et Azure pour atteindre ses objectifs commerciaux.

  • Définissez des budgets d’interruption de pod. Ce paramètre vérifie le nombre de réplicas d’un déploiement que vous pouvez retirer lors d’un événement de mise à jour ou de mise à niveau.

  • Appliquez des quotas de ressources sur les espaces de noms de service. Le quota de ressources sur un espace de noms permet de s’assurer que les requêtes et les limites de pod sont correctement définies sur un déploiement.

    • La définition de quotas de ressources au niveau du cluster peut provoquer un problème lors du déploiement de services partenaires ne disposant pas de demandes ou limites appropriées.

  • Stockez vos images conteneur dans Azure Container Registry et géorépliquez le registre dans chaque région AKS.

  • Utilisez le contrat SLA de durée de fonctionnement pour activer un contrat SLA financé supérieur pour tous les clusters hébergeant des charges de travail de production. Le contrat SLA de durée de fonctionnement garantit une disponibilité de 99,95 % du point de terminaison de serveur de l’API Kubernetes pour les clusters qui utilisent des Zones de disponibilité et 99,9 % de disponibilité pour les clusters qui n’utilisent pas de Zones de disponibilité. Vos nœuds, pools de nœuds et autres ressources sont couverts par leur contrat SLA. AKS offre un niveau gratuit avec un objectif de niveau de service (SLO) de 99,5 % pour ses composants de plan de contrôle. Les clusters sans contrat SLA de durée de fonctionnement activé ne doivent pas être utilisés pour les charges de travail de production.

  • Utilisez plusieurs régions et emplacements de Peering pour la connectivité Azure ExpressRoute.

    Si une panne affectant une région Azure ou un emplacement de fournisseur de peering se produit, une architecture réseau hybride redondante peut contribuer à garantir la continuité de la connectivité intersite.

  • Interconnecter des régions avec l’appairage de réseaux virtuels mondiaux. Si les clusters doivent communiquer entre eux, il est possible de connecter les deux réseaux virtuels entre eux via l’appairage de réseau virtuel. Cette technologie interconnecte les réseaux virtuels entre eux pour fournir une bande passante élevée à travers le réseau principal de Microsoft, même entre différentes régions géographiques.

  • Grâce au protocole anycast basé sur Split TCP, Front Door garantit la connexion rapide des utilisateurs finaux au point de présence Front Door le plus proche. Les autres fonctionnalités d’Azure Front Door sont les suivantes :

    • Arrêt TLS
    • Domaine personnalisé
    • Pare-feu d’applications web
    • Réécrire URL
    • Affinité de session

    Passez en revue les besoins de trafic de votre application pour comprendre quelle solution est la plus adaptée.