Stratégies de support pour Azure Kubernetes Service

Cet article décrit les politiques et les limites du support technique pour Azure Kubernetes Service (AKS). Il détaille également la gestion des nœuds d'agents, les composants gérés du plan de contrôle, les composants open-source tiers et la gestion de la sécurité ou des correctifs.

Versions et mises à jour du service

• Pour des informations sur les versions, consultez les notes de publication relatives à AKS.
• Pour plus d'informations sur les fonctionnalités d’évaluation, voir la feuille de route AKS .

Fonctionnalités gérées dans AKS

Les composants cloud infrastructure as a service (IaaS) de base, tels que les composants réseau ou de calcul, vous permettent d’accéder à des contrôles de niveau inférieur et à des options de personnalisation. En revanche, AKS fournit un déploiement clé en main de Kubernetes qui vous offre l’ensemble courant de configurations et fonctionnalités dont vous avez besoin pour votre cluster. En tant qu’utilisateur AKS, vous disposez d’options de personnalisation et de déploiement limitées. En contrepartie, vous n’avez pas à vous soucier des clusters Kubernetes, ni à les gérer directement.

Avec AKS, vous bénéficiez d’un plan de contrôle entièrement géré. 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 et exploite tous les composants Kubernetes.

Microsoft gère et surveille les composants suivants via le panneau de contrôle :

• Kubelet ou serveurs d’API Kubernetes
• Etcd ou un stockage clé-valeur compatible assurant la Qualité de service (QoS), l’extensibilité et le runtime
• Services DNS (par exemple, kube-dns ou CoreDNS)
• Proxy ou mise en réseau Kubernetes (sauf lorsque BYOCNI est utilisé)
• Tout module complémentaire ou composant système en cours d’exécution dans l’espace de noms system

AKS n’est pas une solution PaaS (Platform-as-a-Service). Certains composants, tels que des nœuds d’agent ont la responsabilité partagée, où les utilisateurs doivent participer à la gestion du cluster AKS. L’entrée utilisateur est nécessaire, par exemple, pour appliquer un correctif de sécurité du système d’exploitation de nœud d’agent.

Les services sont gérés de façon que Microsoft et l’équipe AKS déploient, gèrent et soient responsables de l’opérationnalité et de la disponibilité du service. Les clients ne peuvent pas modifier ces composants gérés. Microsoft limite la personnalisation, afin de garantir une expérience utilisateur cohérente et évolutive.

Responsabilité partagée

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

Étant donné que les nœuds de votre agent exécutent du code privé et stockent des données sensibles, le Support Microsoft peut y accéder de manière limitée uniquement. Le Support Microsoft ne peut pas se connecter, exécuter des commandes ou afficher les journaux de ces nœuds sans votre autorisation expresse ou assistance.

Toute modification apportée directement aux nœuds de l'agent à l'aide de l'une des API IaaS rend la grappe non supportable. Toute modification appliquée aux nœuds d'agents doit être effectuée à l'aide de mécanismes natifs de tels queDaemon Sets .

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

Couverture du support AKS

Scénarios pris en charge

Microsoft fournit un support technique pour les exemples suivants :

• Connectivité à tous les composants Kubernetes que le service Kubernetes fournit et prend en charge, tel que le serveur d’API.
• Gestion, durée de fonctionnement, QoS et opérations des services de plan de contrôle Kubernetes (plan de contrôle Kubernetes, serveur d’API, et DNS, par exemple).
• Magasin de données etcd. Le support inclut des sauvegardes automatisées et transparentes de l’ensemble des données etcd toutes les 30 minutes pour la planification de la récupération d’urgence et la restauration de l’état du cluster. Ces sauvegardes ne sont pas directement accessibles à vous ou à quelqu'un d'autre. Elles garantissent la cohérence et la fiabilité des données. La restauration à la demande ou la restauration ne sont pas prises en charge en tant que fonctionnalité.
• Points d’intégration dans le pilote du fournisseur cloud Azure pour Kubernetes. Ceux-ci incluent des intégrations à d’autres services Azure tels que les équilibreurs de charge, les volumes persistants ou la mise en réseau (Kubernetes et Azure CNI, sauf lorsque BYOCNI est utilisé).
• 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 relatifs à la mise en réseau, tels qu’Azure CNI, kubenet ou d’autres problèmes d’accès réseau et de fonctionnalité, sauf lorsque BYOCNI est utilisé. Les problèmes peuvent inclure la résolution DNS, la perte de paquets, le routage, etc. Microsoft prend en charge différents scénarios de mise en réseau :
  • Kubenet et Azure CNI avec des réseaux virtuels gérés ou des sous-réseaux personnalisés (« Apporter votre propre »).
  • Connectivité à d’autres services et applications Azure
  • Contrôleurs d’entrée gérés par Microsoft ou configurations d’équilibreur de charge
  • Performances et latence réseau
  • Composants et fonctionnalités des stratégies réseau gérés par Microsoft

Remarque

Toute mesure relative au cluster prise par Microsoft/AKS est effectuée avec le consentement de l’utilisateur sous un rôle Kubernetes intégré aks-service et une liaison de rôle intégrée aks-service-rolebinding. Ce rôle permet à AKS de dépanner et de diagnostiquer les problèmes de cluster, mais ne peut pas modifier les autorisations, ni créer des rôles ou des liaisons de rôle, ni d’autres actions à privilèges élevés. L’accès aux rôles est activé uniquement sous les tickets de support actifs avec l’accès juste-à-temps (JIT).

Scénarios non pris en charge

Microsoft ne fournit pas d'assistance technique pour les scénarios 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

  Le Support Microsoft peut vous conseiller sur la fonctionnalité de cluster AKS, la personnalisation et le paramétrage (par exemple, les procédures et problèmes relatifs aux opérations Kubernetes).

• Les projets open source tiers qui ne sont pas fournis dans le cadre du plan de contrôle Kubernetes ou déployés avec des clusters AKS. Ces projets peuvent inclure Istio, Helm, Envoy, etc.

  Remarque

  Microsoft fera de son mieux pour assurer le support des projets open source tiers tels que Helm. Quand l’outil open source tiers est associé au fournisseur cloud Azure Kubernetes ou à d’autres bogues spécifiques à AKS, Microsoft fournit des exemples et applications issus de sa documentation.

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

• Configuration ou résolution des problèmes de code ou de comportement propres à l’application des applications ou outils tiers s’exécutant dans le cluster AKS. Cela inclut les problèmes de déploiement d’applications qui ne sont pas liés à la plateforme AKS elle-même.

• Émission, renouvellement ou gestion de certificats pour les applications s’exécutant sur AKS.

• Personnalisations réseau autres que celles répertoriées dans la documentation AKS. Par exemple, le support Microsoft ne peut pas configurer des appareils ou des appliances virtuelles destinées à fournir le trafic sortant pour le cluster AKS, comme les VPN ou les pare-feu.

  Remarque

  Sur une base optimale, le support Microsoft peut conseiller sur la configuration nécessaire pour le pare-feu Azure, mais pas pour d’autres appareils tiers.

• Plugins CNI personnalisés ou tiers utilisés en mode BYOCNI.

• Configuration ou résolution des problèmes liés aux stratégies réseau non gérées par Microsoft. Bien que l’utilisation de stratégies réseau soit prise en charge, le support Microsoft ne peut pas examiner les problèmes liés aux configurations de stratégie réseau personnalisées.

• Configuration ou résolution des problèmes des contrôleurs d’entrée non gérés par Microsoft, tels que nginx, kong, traefik, etc. Cela inclut la résolution des problèmes de fonctionnalité qui surviennent après les opérations spécifiques à AKS, comme un contrôleur d’entrée qui cesse de fonctionner à la suite d’une mise à niveau de version Kubernetes. Ces problèmes peuvent provenir d’incompatibilités entre la version du contrôleur d’entrée et la nouvelle version de Kubernetes. Pour une option entièrement prise en charge, envisagez d’utiliser une option de contrôleur d’entrée gérée par Microsoft.

• Configuration ou résolution des problèmes de DaemonSets (y compris les scripts) utilisés pour personnaliser les configurations de nœud. Bien que l’utilisation de DaemonSets soit l’approche recommandée pour régler, modifier ou installer des logiciels tiers sur des nœuds d’agent de cluster lorsque les paramètres du fichier de configuration sont insuffisants, le support Microsoft ne peut pas résoudre les problèmes liés aux scripts personnalisés utilisés dans DaemonSets en raison de leur nature personnalisée.

• Scénarios en mode stand-by et proactifs. Le Support Microsoft fournit un support réactif pour vous aider à résoudre les problèmes actifs de manière opportune et professionnelle. Toutefois, le support de secours ou proactif pour vous aider à éliminer les risques opérationnels, à augmenter la disponibilité, puis à optimiser les performances n’est pas couvert. Les clients éligibles peuvent contacter leur équipe de compte pour être nommés pour le service Gestion des événements Azure. Ce service payant fourni par les ingénieurs du support Microsoft inclut une évaluation proactive des risques de la solution et une couverture pendant l’événement.

• Vulnérabilités/CVE avec un correctif de fournisseur datant de moins de 30 jours. Tant que vous exécutez le disque dur virtuel mis à jour, vous ne devez pas exécuter de vulnérabilités/CVE d’image conteneur avec un correctif fournisseur datant de plus de 30 jours. Il est de la responsabilité du client de mettre à jour le disque dur virtuel et de fournir des listes filtrées au support Microsoft. Une fois que vous avez mis à jour votre disque dur virtuel, il est de la responsabilité du client de filtrer le rapport de vulnérabilités /CVE et de fournir une liste uniquement avec les vulnérabilités/CVE qui ont un correctif de fournisseur datant de plus de 30 jours. Si c’est le cas, le support Microsoft veille à travailler en interne et à traiter les composants avec un correctif fournisseur publié il y a plus de 30 jours. De plus, Microsoft fournit une prise en charge des vulnérabilités/CVE uniquement pour les composants gérés par Microsoft (par exemple, les images de nœud AKS, les images conteneur managées pour les applications qui sont déployées lors de la création du cluster ou via l’installation d’un module complémentaire managé). Pour plus d’informations sur la gestion des vulnérabilités pour AKS, consultez cette page.

• Exemples de code personnalisé ou scripts. Bien que le Support Microsoft puisse fournir de petits exemples de code et des révisions de petits exemples de code dans un cas de support pour montrer comment utiliser certaines fonctionnalités d’un produit Microsoft, le Support Microsoft ne peut pas fournir des exemples de code personnalisé spécifiques à votre environnement ou application.

Couverture du support AKS pour les nœuds d’agent

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

Microsoft et vous partagez la responsabilité des nœuds d'agent Kubernetes où :

• L’image du système d’exploitation de base a requis des ajouts (par exemple, des agents réseau et de surveillance).
• Les nœuds d’agent reçoivent automatiquement des correctifs de système d’exploitation.
• Des problèmes en lien avec les composants du plan de contrôle Kubernetes qui s’exécutent sur les nœuds d’agent sont automatiquement corrigés. Ces composants comprennent les suivants :
  • Kube-proxy
  • Tunnels de mise en réseau qui fournissent des chemins d’accès de communication vers les composants master Kubernetes
  • Kubelet
  • containerd

Notes

Si un nœud d’agent n’est pas opérationnel, AKS peut redémarrer des composants individuels ou l’intégralité du nœud de l’agent. Ces opérations de redémarrage sont automatisées et assurent une résolution automatique des problèmes courants. Si vous souhaitez en savoir plus sur les mécanismes de correction automatique, consultez Réparation automatique des nœuds

Responsabilités du client pour les nœuds d’agent AKS

Microsoft fournit chaque semaine des patchs et de nouvelles images pour vos nœuds d’images. Pour maintenir à jour le système d’exploitation et les composants d’exécution de votre nœud agent, vous devez appliquer ces correctifs et mises à jour régulièrement manuellement ou automatiquement. Pour plus d’informations, consultez l’article suivant :

• Mettre à niveau manuellement des images de nœud AKS
• Mettre à niveau automatiquement les images de nœud AKS

De même, AKS publie régulièrement de nouveaux correctifs et de nouvelles versions mineures de Kubernetes. 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 de Kubernetes des clusters conformément à la Stratégie de gestion des versions prises en charge d’AKS Kubernetes.

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

Remarque

Les nœuds de l'agent AKS apparaissent dans le Azure portal - portail Microsoft Azure comme des ressources Azure IaaS standard. Cependant, ces machines virtuelles sont déployées dans un groupe de ressources Azure personnalisé (préfixé par MC_*). 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 IaaS. Les modifications personnalisées qui ne sont pas effectuées via l’API AKS ne sont pas conservées lors d’une mise à niveau, d’une mise à l’échelle, d’une mise à jour ou d’un redémarrage. En outre, toute modification apportée aux extensions des nœuds, comme CustomScriptExtension, peut entraîner un comportement inattendu et doit être interdite. Évitez d’effectuer des modifications sur les nœuds de l’agent, sauf si le Support Microsoft vous demande d’apporter ces modifications.

AKS gère le cycle de vie et les opérations des nœuds d’agent pour votre compte ; la modification des ressources IaaS associées aux nœuds d’agent n’est pas prise en charge. Un exemple d'opération non prise en charge est la personnalisation d'un ensemble d'échelles de machines virtuelles de pool de nœuds en modifiant manuellement les configurations dans le Azure portail - portail Microsoft Azure ou à partir de l'API.

Pour les configurations ou packages spécifiques à la charge de travail, AKS recommande l’utilisation de ressources Kubernetes daemon sets.

L’utilisation de ressources Kubernetes daemon sets privilégiées et de conteneurs init permet aux clients de paramétrer/modifier ou d’installer des logiciels tiers sur des nœuds d’agent de cluster. Parmi ces personnalisations, citons l’ajout d’un logiciel d’analyse de sécurité personnalisé ou la mise à jour des paramètres sysctl.

Bien que cette voie soit recommandée si les exigences ci-dessus s'appliquent, l'ingénierie et le support AKS ne peuvent pas aider à dépanner ou à diagnostiquer les modifications qui rendent le nœud indisponible en raison d'un déploiement personnalisédaemon set.

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

Si une faille de sécurité se trouve dans un ou plusieurs composants gérés AKS, l’équipe AKS appliquera des correctifs à tous les clusters affectés pour atténuer le problème. L’équipe AKS vous fournit également des conseils de mise à niveau.

Pour les nœuds d'agent affectés par une faille de sécurité, Microsoft vous informe des détails de l'impact et des mesures à prendre pour corriger ou atténuer le problème de sécurité.

Accès et maintenance des nœuds

Même si vous pouvez vous connecter aux nœuds d’agent et les modifier, ces opérations sont déconseillées, car ces modifications peuvent affecter le support du cluster.

Ports réseau, accès et groupes de sécurité réseau

Vous pouvez uniquement personnaliser les groupes de sécurité réseau sur des sous-réseaux personnalisés. Vous ne pouvez pas personnaliser les groupes de sécurité réseau sur des sous-réseaux gérés ou au niveau de la carte réseau des nœuds de l’agent. AKS a des exigences de sortie sur des points de terminaison spécifiques. Pour contrôler la sortie et garantir la connectivité nécessaire, consultez Limiter le trafic sortant. Pour l’entrée, les spécifications sont basées sur les applications que vous avez déployées sur le cluster.

Nœuds arrêtés, désalloués et non prêts

Si vous n’avez pas besoin que vos charges de travail AKS s’exécutent en continu, vous pouvez arrêter le cluster AKS, qui interrompt tous les pools de nœuds et le plan de contrôle, puis le redémarrer quand cela est nécessaire. Vous pouvez le relancer en cas de besoin. Lorsque vous arrêtez une grappe à l'aide de la commande,az aks stop l'état de la grappe est préservé pendant 12 mois maximum. Après 12 mois, l'état du cluster et toutes ses ressources sont supprimés.

La désallocation manuelle de tous les nœuds de cluster à partir des API IaaS, de la CLI Azure ou du portail Azure n'est pas prise en charge pour arrêter un cluster AKS. Le cluster sera considéré comme hors support et arrêté par AKS après 30 jours. Les grappes sont alors soumises à la même politique de conservation de 12 mois qu'une grappe correctement arrêtée.

Les clusters avec 30 nœuds « Prêt » (ou tous les nœuds « Non prêts ») et 0 machines virtuelles en cours d’exécution seront arrêtées au bout de 30 jours.

AKS se réserve le droit d’archiver les plans de contrôle qui ont été configurés sans respecter les instructions de prise en charge pendant des périodes prolongées supérieures ou égales à 30 jours. AKS tient à jour les sauvegardes des métadonnées etcd du cluster et peut facilement réallouer le cluster. Cette réaffectation est initiée par toute opération PUT qui remet le cluster en état de fonctionnement, telle qu'une mise à niveau ou une mise à l'échelle des nœuds d'agents actifs.

Tous les clusters d’un abonnement suspendu seront immédiatement arrêtés et supprimés au bout de 90 jours. Tout les groupes dans un abonnement supprimé seront immédiatement supprimés.

Fonctionnalités Kubernetes alpha et bêta non supportées

AKS prend uniquement en charge les fonctionnalités stables et bêta au sein du projet Kubernetes en amont. Sauf mention contraire, AKS ne supporte pas les fonctionnalités alpha qui sont disponibles dans le projet Kubernetes en amont.

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

Pour les fonctionnalités et fonctions qui exigent 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é. Considérez ces fonctionnalités comme des fonctionnalités bêta ou en version préliminaire.

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 font l’objet d’une prise en charge optimale, car ces fonctionnalités sont en préversion et ne sont pas destinées à la production. L'équipe d'assistance technique AKS fournit une assistance pendant les heures de bureau uniquement. Pour plus d’informations, consultez les Questions fréquentes sur le 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 ni contournés au sein du système AKS. 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 appartenant à Microsoft (par exemple, le fournisseur cloud Azure), AKS et le personnel Azure s’engagent à corriger les problèmes en amont dans la communauté.

Lorsque la cause première d'un problème d'assistance technique est due à un ou plusieurs bogues en amont, les équipes d'assistance et d'ingénierie AKS s'en chargent :

• 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 consigné dans le référentiel AKS. La consignation du problème connu décrit :

  • Le problème, avec des liens vers des bogues en amont.
  • La solution alternative et des informations sur une mise à jour ou une autre persistance de la solution.
  • Des chronologies approximatives pour l’inclusion du problème, en fonction de la cadence des versions en amont.