Partager via

Stratégies de support pour AKS activées par Azure Arc

  • Article

S’applique à : AKS sur Azure Stack HCI 22H2, AKS sur Windows Server

Cet article fournit des détails sur les stratégies de support technique et les limitations pour AKS activés par Arc. L’article décrit également la gestion des nœuds de cluster, les composants du plan de contrôle, les composants open source tiers et la sécurité ou la gestion des correctifs.

Versions et mises à jour du service

  • Microsoft offre une fenêtre de support de 1 an pour chaque version mineure Kubernetes, à compter de la date de publication initiale. Pendant cette période, AKS Arc publie les versions mineures ou correctives suivantes pour garantir la prise en charge continue.
  • Un cluster Kubernetes qui fonctionne sur une version mineure déconseillée doit être mis à jour vers une version prise en charge pour être éligible à la prise en charge.
  • Une fois qu’une version mineure est déconseillée, tous les clusters en cours d’exécution sur cette version continueront de fonctionner. Vous pouvez toujours effectuer des opérations telles que le scale-up ou le scale-down, mais AKS Arc affiche un avertissement pendant les opérations de cluster.
  • Une fois qu’une version mineure est déconseillée, elle est supprimée des serveurs Microsoft. À ce stade, les clusters Kubernetes utilisant cette version ne peuvent pas mettre à jour Kubernetes ou les versions du système d’exploitation et doivent être mis à niveau vers la dernière version. Dans certains cas, cette mise à niveau peut également signifier un redéploiement complet si le système n’est pas dans un état sain.

Pour plus d’informations sur la publication, consultez les notes de publication d’AKS Arc. Pour plus d’informations sur les fonctionnalités en préversion, consultez les fonctionnalités d’évaluation AKS Arc.

Fonctionnalités managées dans AKS Arc

En tant qu’utilisateur AKS Arc, vous avez des options de personnalisation et de déploiement limitées. Toutefois, vous n’avez pas besoin de vous soucier ou de gérer directement le plan de contrôle et l’installation du cluster Kubernetes. Les composants cloud IaaS (Infrastructure as a Service) de base, tels que les composants de calcul ou de mise en réseau, vous permettent d’accéder aux contrôles de bas niveau et aux options de personnalisation.

En revanche, AKS Arc fournit un déploiement Kubernetes clé en main qui vous donne l’ensemble commun de configurations et de fonctionnalités dont vous avez besoin pour votre cluster. Avec AKS Arc, vous obtenez un plan de contrôle partiellement managé. Le plan de contrôle contient tous les composants et services dont vous avez besoin pour faire fonctionner et proposer des clusters Kubernetes aux utilisateurs finaux. Microsoft gère tous les composants Kubernetes.

Microsoft gère les composants suivants via le cluster de gestion et les images de base de machine virtuelle associées :

  • kubelet ou serveurs d’API Kubernetes.
  • etcd ou un magasin de clés-valeur compatible, fournissant qualité de service (QoS), scalabilité et runtime.
  • Services DNS (par exemple, kube-dns ou CoreDNS).
  • Proxy Kubernetes ou réseau.
  • Tout autre composant complémentaire ou système s’exécutant dans l’espace kube-system de noms.

AKS Arc n’est pas une solution PaaS (Platform-as-a-Service). Certains composants, tels que les clusters de charge de travail, le plan de contrôle et les nœuds Worker, ont une responsabilité partagée. Les utilisateurs doivent aider à gérer le cluster Kubernetes. Une entrée d’utilisateur est requise, par exemple, pour appliquer un correctif de sécurité du système d’exploitation ou une mise à jour vers une version plus récente de Kubernetes.

Les services sont gérés dans le sens où Microsoft et l’équipe AKS fournissent les outils qui déploient le cluster de gestion, le plan de contrôle et les nœuds d’agent pour les clusters de charge de travail. Vous ne pouvez pas modifier ces composants managés. Microsoft limite la personnalisation, afin de garantir une expérience utilisateur cohérente et évolutive. Pour obtenir une solution entièrement personnalisable dans le cloud, consultez le moteur AKS.

Stratégie de version prise en charge

Les versions de Kubernetes dans AKS Arc suivent la stratégie de version Kubernetes.

AKS Arc ne garantit aucun runtime (ou autre) pour les clusters en dehors de la liste des versions prises en charge. « En dehors du support » signifie que :

  • Votre cluster fonctionne sur une version mineure déconseillée. La version que vous exécutez n’est pas dans la liste des versions prises en charge.
  • Vous êtes invité à mettre à niveau le cluster vers une version prise en charge lors de la demande de support.

Pour plus d’informations sur les versions de Kubernetes prises en charge, consultez versions kubernetes prises en charge.

AKS Arc suit les délais de prise en charge de la version de la plateforme pour ces produits. Autrement dit, AKS Arc n’est pas pris en charge sur les versions non prises en charge de ces produits. Pour plus d’informations, consultez leurs stratégies de support :

Responsabilité partagée

Quand un cluster est créé, vous définissez les nœuds de l’agent Kubernetes créés par AKS Arc. Vos charges de travail sont exécutées sur ces nœuds.

Étant donné que vos nœuds d’agent exécutent du code privé et stockent des données sensibles, Support Microsoft dispose d’un accès limité. Support Microsoft ne peut pas se connecter pour exécuter des commandes ou afficher les journaux de ces nœuds sans votre autorisation ou assistance rapide. Toute modification directe des nœuds de l’agent à l’aide de l’une des API IaaS restitue le cluster insupportable. Toute modification apportée aux nœuds de l’agent doit être effectuée à l’aide de mécanismes natifs Kubernetes tels que Daemon Sets.

De même, si vous pouvez ajouter des métadonnées, telles que des étiquettes et des étiquettes, au cluster et aux nœuds, la modification des métadonnées créées par le système restitue le cluster non pris en charge.

Couverture du support AKS Arc

Microsoft fournit un support technique pour les fonctionnalités et composants suivants :

  • Connectivité à tous les composants Kubernetes que le service Kubernetes fournit et prend en charge, tel que le serveur d’API.
  • Services de plan de contrôle Kubernetes (par exemple, plan de contrôle Kubernetes, serveur d’API, etcd et coreDNS).
  • Magasin de données etcd.
  • Intégration avec Azure Arc et le service Facturation Azure.
  • Questions ou problèmes relatifs à la personnalisation des composants du plan de contrôle tels que le serveur d’API Kubernetes, etcd et coreDNS.
  • Problèmes liés à la mise en réseau, à l’accès réseau et aux fonctionnalités. Les problèmes peuvent inclure la résolution DNS, la perte de paquets et le routage. Microsoft prend en charge différents scénarios de mise en réseau :
    • Support de base pour l’installation de Flannel et Calico CNI. Ces CNI sont gérés par la communauté et pris en charge. Support Microsoft fournit uniquement la prise en charge de l’installation et de la configuration de base.
    • Connectivité à d’autres services et applications Azure.
    • Contrôleurs d’entrée, configuration d’entrée ou d’équilibreur de charge.
    • Performances et latence réseau.

Remarque

Toutes les actions de cluster effectuées par les équipes de support microsoft AKS Arc sont effectuées avec le consentement et l’assistance de l’utilisateur. Support Microsoft ne se connecte pas à votre cluster, sauf si vous configurez l’accès pour l’ingénieur du support technique.

Microsoft ne fournit pas de support technique pour les domaines suivants :

  • Questions sur l’utilisation de Kubernetes. Par exemple, le Support Microsoft ne fournit pas de conseils sur la façon dont les contrôleurs d’entrée doivent être créés, sur l’utilisation des charges de travail d’application ou sur l’application d’outils ou de packages logiciels open source ou tiers.

    Remarque

    Support Microsoft pouvez conseiller sur les fonctionnalités de cluster, la personnalisation et le réglage dans AKS Arc. Par exemple, les problèmes et procédures des opérations Kubernetes.

  • Projets open source tiers qui ne sont pas fournis dans le cadre du plan de contrôle Kubernetes ou déployés lors de la création de clusters dans AKS Arc. Ces projets peuvent inclure Istio, Helm, Envoy ou d’autres.

    Remarque

    Microsoft fera de son mieux pour assurer le support des projets open source tiers tels que Helm. Lorsque l’outil open source tiers s’intègre à Kubernetes ou à d’autres bogues spécifiques à AKS Arc, Microsoft prend en charge des exemples et des applications de la documentation Microsoft.

  • Logiciels fermés tiers. Ces logiciels peuvent inclure des outils d’analyse de sécurité et des logiciels ou appareils réseau.

  • Personnalisations réseau autres que celles répertoriées dans la documentation AKS Arc.

Prise en charge d’AKS Arc pour les nœuds d’agent

Responsabilités Microsoft pour les nœuds de l’agent AKS Arc

Microsoft et les clients partagent la responsabilité relative aux nœuds d’agent Kubernetes quand :

  • L’image du système d’exploitation de base nécessite des ajouts (tels que la surveillance et les agents de mise en réseau).
  • Les nœuds d’agent reçoivent automatiquement des correctifs de système d’exploitation.
  • Les problèmes liés aux composants du plan de contrôle Kubernetes qui s’exécutent sur les nœuds d’agent sont automatiquement corrigés pendant le cycle de mise à jour ou lorsque vous redéployez un nœud d’agent. Ces composants sont les suivants :
    • kube-proxy
    • Tunnels de mise en réseau qui fournissent des chemins de communication aux composants principaux Kubernetes :
      • kubelet
      • Moby ou ContainerD

Remarque

Si un nœud d’agent n’est pas opérationnel, AKS Arc peut redémarrer des composants individuels ou l’ensemble du nœud de l’agent. Ces opérations de redémarrage automatisé fournissent une correction automatique pour les problèmes courants.

Responsabilités des clients pour les nœuds de l’agent AKS Arc

Microsoft fournit des correctifs et de nouvelles images pour vos nœuds d’image chaque mois, mais ne les applique pas automatiquement par défaut. Pour que vos composants de système d’exploitation et d’exécution du nœud agent soient corrigés, vous devez conserver une planification de mise à niveau régulière ou automatiser la mise à jour corrective.

De même, AKS Arc publie régulièrement de nouveaux correctifs Kubernetes et des versions mineures. Ces mises à jour peuvent contenir des améliorations en matière de sécurité ou de fonctionnalités pour Kubernetes. Vous êtes responsable de la mise à jour de la version Kubernetes de votre cluster en fonction de la stratégie de versions prises en charge par AKS Arc.

Personnalisation par l’utilisateur des nœuds de l’agent

Remarque

Les nœuds de l’agent AKS Arc apparaissent dans Hyper-V en tant que ressources de machine virtuelle standard. Ces machines virtuelles sont déployées avec une image de système d’exploitation personnalisée et des composants Kubernetes pris en charge et gérés. Vous ne pouvez pas modifier l’image de base du système d’exploitation ou effectuer des personnalisations directes sur ces nœuds à l’aide des API ou des ressources Hyper-V. Toutes les modifications personnalisées qui ne sont pas effectuées via l’API AKS-HCI ne sont pas conservées via une mise à niveau, une mise à l’échelle, une mise à jour ou un redémarrage, et peuvent afficher le cluster non pris en charge. Évitez d’effectuer des modifications sur les nœuds de l’agent, sauf si le Support Microsoft vous demande d’apporter ces modifications.

AKS Arc gère le cycle de vie et les opérations des images de nœud d’agent en votre nom. La modification des ressources associées aux nœuds de l’agent n’est pas prise en charge. Par exemple, la personnalisation des paramètres réseau d’une machine virtuelle en modifiant manuellement les configurations via l’API ou les outils Hyper-V n’est pas prise en charge.

Pour les configurations ou packages spécifiques à la charge de travail, vous devez utiliser des ensembles de démons Kubernetes.

Lorsque vous utilisez des conteneurs kubernetes privilégiés daemon sets et init, vous pouvez paramétrer/modifier ou installer des logiciels tiers sur des nœuds d’agent de cluster. Par exemple, vous pouvez ajouter des logiciels d’analyse de sécurité personnalisés ou des paramètres de mise à jour sysctl . Bien que ce chemin d’accès soit recommandé si les exigences précédentes s’appliquent, l’ingénierie et la prise en charge d’AKS Arc ne peuvent pas aider à résoudre ou diagnostiquer les modifications qui rendent le nœud indisponible en raison d’un déploiement daemon setpersonnalisé.

Problèmes de sécurité et application de correctifs

Si une faille de sécurité se trouve dans un ou plusieurs composants managés d’AKS Arc, l’équipe AKS Arc corrige toutes les images de système d’exploitation affectées pour atténuer le problème, et l’équipe fournit des conseils de mise à niveau aux utilisateurs.

Pour les nœuds d’agent affectés par une faille de sécurité, Microsoft vous informe avec des détails sur l’impact et les étapes à suivre pour résoudre ou atténuer le problème de sécurité. En règle générale, les étapes incluent une mise à niveau d’image de nœud ou une mise à niveau de correctif de cluster.

Accès et maintenance des nœuds

Bien que vous puissiez vous connecter et modifier des nœuds d’agent, cette opération est déconseillée, car les modifications peuvent rendre un cluster insupportable.

Ports réseau, pools IP et accès

Vous pouvez personnaliser uniquement les paramètres réseau à l’aide de sous-réseaux définis par AKS Arc. Vous ne pouvez pas personnaliser les paramètres réseau au niveau de la carte réseau des nœuds de l’agent. AKS Arc a des exigences de sortie pour des points de terminaison spécifiques, pour contrôler la sortie et garantir la connectivité nécessaire. Pour plus d’informations, consultez la configuration requise pour AKS Arc.

Clusters arrêtés ou déconnectés

Comme décrit précédemment, l’allocation manuelle de tous les nœuds de cluster via les API Hyper-V, l’interface CLI ou MMC restitue le cluster hors prise en charge.

Les clusters arrêtés pendant plus de 90 jours ne peuvent plus être mis à jour. Les plans de contrôle pour les clusters dans cet état ne sont pas pris en charge après 30 jours et ne peuvent pas être mis à jour vers la dernière version.

Le cluster de gestion dans AKS Arc doit être en mesure de se connecter à Azure via le trafic sortant HTTPS vers des points de terminaison Azure connus au moins tous les 30 jours pour gérer les 2 opérations quotidiennes telles que la mise à niveau et la mise à l’échelle du pool de nœuds. Si le cluster de gestion est déconnecté au cours de la période de 30 jours, les charges de travail continuent à s’exécuter et à fonctionner comme prévu jusqu’à ce que le cluster de gestion et ou Azure Local se reconnecte et se synchronisent avec Azure. Une fois connectées, toutes les opérations de jour 2 doivent se récupérer et continuer comme prévu. Pour plus d’informations, consultez les exigences de connectivité Azure Local Azure. Après 30 jours, Azure Local empêche la création de nouvelles machines virtuelles.

Si le cluster s’exécute sur Windows Server 2019 ou Windows Server 2022, la plateforme hôte sous-jacente n’a pas les exigences de connexion périodiques de 30 jours.

Remarque

Le début/la fin de la période de 30 jours peut être différent de la période de validité sur AKS Arc et Azure Local. L’arrêt ou la désaffectation manuelle de tous les nœuds de cluster via les API Hyper-V/CLI/MMC pendant des périodes prolongées supérieures à 30 jours et en dehors des procédures de maintenance régulières rend le cluster hors support.

Abonnement supprimé ou suspendu

Si votre abonnement Azure est suspendu ou supprimé, vos clusters AKS ne sont plus pris en charge après 60 jours, sauf si l’abonnement est rétabli avant que la limite de 60 jours soit atteinte. Toutes les autres limitations décrites précédemment s’appliquent également. Une fois l’abonnement supprimé, la connexion au cluster à Azure ne peut pas être récupérée et Azure Local et AKS Arc doivent être redéployés pour pouvoir se reconnecter à Azure.

Fonctionnalités Kubernetes non prises en charge en préversion et bêta

AKS Arc prend uniquement en charge les fonctionnalités stables et bêta dans le projet Kubernetes en amont. Sauf indication contraire, AKS Arc ne prend pas en charge la préversion disponible dans le projet Kubernetes en amont.

Fonctionnalités d’évaluation ou indicateurs de fonctionnalités

Pour les fonctionnalités et fonctions qui requièrent des tests étendus et des commentaires des utilisateurs, Microsoft publie de nouvelles fonctionnalités d’évaluation ou des fonctionnalités appartenant à un indicateur de fonctionnalité. Tenez compte de ces fonctionnalités préliminaires ou bêta. Les fonctionnalités d’évaluation ou fonctionnalités avec indicateur de fonctionnalité ne sont pas destinées aux environnements de production. Les modifications continues apportées aux API et aux comportements, corrections de bogues et autres types de modifications peuvent entraîner des temps d’arrêt et un manque de stabilité des clusters.

Les fonctionnalités de la préversion publique reçoivent la prise en charge de « meilleur effort », car ces fonctionnalités sont en préversion et ne sont pas destinées à la production. Ces fonctionnalités sont prises en charge par les équipes de support technique AKS Arc uniquement pendant les heures d’ouverture. Pour plus d’informations, consultez le forum aux questions support Azure.

Problèmes et bogues en amont

Étant donné la vitesse de développement dans le projet Kubernetes en amont, des bogues surviennent invariablement. Certains de ces bogues ne peuvent pas être corrigés ou travaillés dans le système AKS Arc. Au lieu de cela, des corrections de bogues exigent des correctifs plus importants pour les projets en amont (comme Kubernetes, systèmes d’exploitation d’agent ou de nœud et noyau). Pour les composants que Microsoft possède (tels que les fournisseurs d’API de cluster pour Azure Local), AKS Arc et le personnel Azure s’engagent à résoudre les problèmes en amont dans la communauté.

Lorsqu’un problème de support technique est racine provoqué par un ou plusieurs bogues en amont, les équipes de support et d’ingénierie AKS Arc effectuent les opérations suivantes :

  • Ils identifient et associent les bogues en amont aux détails de support afin d’expliquer pourquoi ce problème affecte votre cluster ou charge de travail. Les clients reçoivent des liens vers les référentiels nécessaires afin de pouvoir étudier les problèmes et voir quand une nouvelle version fournira des correctifs.
  • Ils proposent des atténuations ou solutions alternatives éventuelles. Si le problème peut être atténué, un problème connu est déposé dans le référentiel AKS local et Windows Server. Le dépôt de problèmes connus explique :
    • Le problème, avec des liens vers des bogues en amont.
    • Solution de contournement et détails sur une mise à niveau ou une autre option pour la solution.
    • Des chronologies approximatives pour l’inclusion du problème, en fonction de la cadence des versions en amont.

Étapes suivantes