Stratégies de support pour Azure Kubernetes Service

Cet article décrit les stratégies et limitations de support technique pour Azure Kubernetes Service (AKS). Il détaille également la gestion des nœuds de l’agent, les composants du plan de contrôle managé, les composants non Microsoft open source et la sécurité ou la gestion 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 en préversion, consultez la feuille de route AKS.

Fonctionnalités gérées dans AKS

AKS est un mélange d’Infrastructure as a Service (IaaS) et de Plateforme as a Service (PaaS). Les composants cloud IaaS de base, tels que les composants de calcul ou de mise en réseau, permettent d’accéder aux contrôles de bas niveau et aux 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 et ne gérez pas directement les clusters Kubernetes.

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 plan de contrôle :

• Serveur d’API Kubernetes et kubelet.
• etcd ou un stockage clé-valeur compatible assurant la Qualité de service (QoS), l’extensibilité et le runtime.
• Services DNS tels que CoreDNS.
• kube-proxy et la mise en réseau de cluster, sauf quand BYOCNI est utilisé.
• Tout module complémentaire ou composant système en cours d’exécution dans l’espace de noms system

Certains composants, comme les nœuds d’agent, ont une responsabilité partagée, où vous devez aider à gérer le 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 dans le sens où Microsoft et l’équipe AKS déploient, exploitent et sont responsables de la disponibilité et de la fonctionnalité du service. Les clients ne peuvent pas modifier ces composants gérés. Microsoft limite la personnalisation pour garantir une expérience utilisateur cohérente et évolutive.

Responsabilité partagée

Lorsque vous créez un cluster, vous définissez les nœuds de l’agent Kubernetes créés par AKS. Vos charges de travail s’exécutent sur ces nœuds. Gardez à l’esprit les contraintes de nœud d’agent suivantes :

• Support Microsoft a un accès limité. Étant donné que vos nœuds d'agent exécutent du code privé et stockent des données sensibles, Support Microsoft ne peuvent pas se connecter, exécuter des commandes ou afficher des journaux pour ces nœuds sans votre autorisation ou assistance express.
• Utilisez des mécanismes natifs Kubernetes pour les modifications. Toute modification apportée directement aux nœuds d’agent via les API IaaS fait que le cluster n’est plus pris en charge. Appliquez des modifications à l’aide de mécanismes natifs Kubernetes comme un DaemonSet.
• Ne modifiez pas les métadonnées créées par le système. Vous pouvez ajouter des métadonnées telles que des tags et des libellés, mais modifier toute métadonnée créée par le système rend le cluster non pris en charge.

Répartition des responsabilités

La matrice suivante résume les responsabilités en matière de support au sein d’un cluster AKS et compare AKS à Kubernetes autogéré que vous exécutez sur site. Dans AKS, Microsoft gère le plan de contrôle et la plateforme principale. Vous gérez votre configuration de nœud, vos charges de travail, votre configuration réseau et vos données. Les zones partagées sont l’endroit où Microsoft fournit et gère une fonctionnalité et que vous activez, configurez ou planifiez-la. Utilisez la matrice en tant que guide en un clin d’œil, puis consultez les sections détaillées qui suivent pour connaître les spécificités du support.

Utilisez la clé suivante pour lire la matrice :

Pour les domaines partagés dans la matrice suivante, le tableau indique ce que Microsoft fournit et ce dont vous êtes responsable :

Couverture du support AKS

Les sections suivantes décrivent les scénarios pris en charge et non pris en charge pour le support technique AKS.

Scénarios pris en charge

Microsoft fournit un support technique pour les exemples suivants :

Toutes les actions de cluster effectuées par Microsoft ou AKS sont effectuées avec votre consentement sous un rôle aks-service Kubernetes intégré et une liaison aks-service-rolebindingde rôle intégrée, qui lie le rôle à l’identité de aks-support service Support Microsoft. Ce rôle permet à AKS de résoudre et de diagnostiquer les problèmes de cluster, mais il ne peut pas modifier les autorisations ni créer des rôles ou des liaisons de rôle, ni effectuer d’autres actions à privilège élevé. 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 de support technique pour les scénarios suivants.

Certains de ces scénarios ont plus de nuances sur ce que Microsoft peuvent encore aider. Pour plus d’informations, consultez Détails sur les scénarios non pris en charge.

Détails sur les scénarios non pris en charge

Plusieurs scénarios non pris en charge ont ajouté des nuances sur ce que Microsoft peuvent toujours aider à :

• Comment utiliser Kubernetes. Support Microsoft ne fournit pas de conseils sur la création de contrôleurs d'entrée personnalisés, l'utilisation de charges de travail d'application ou l'application de packages logiciels ou d'outils non Microsoft ou open source. Le support Microsoft peut conseiller sur les fonctionnalités de cluster AKS, la personnalisation et le réglage (par exemple, les procédures et les problèmes liés aux opérations Kubernetes).
• Projets open source non Microsoft. Ces projets ne sont pas fournis dans le cadre du plan de contrôle Kubernetes ou déployés avec des clusters AKS, et peuvent inclure Istio, Helm, Envoy ou d’autres. Microsoft pouvez fournir un support optimal pour les projets comme Helm. Lorsque l’outil s’intègre au fournisseur de cloud Azure pour Kubernetes ou en cas d’autres bogues propres à AKS, Microsoft assure le support des exemples et des applications issus de la documentation Microsoft.
• Customisations du réseau. Pour les personnalisations autres que celles répertoriées dans la documentation AKS, Support Microsoft ne pouvez pas configurer d'appareils ou d'appliances virtuelles destinées à fournir le trafic sortant pour le cluster, comme les VPN ou les pare-feu. Sur une base optimale, Support Microsoft peut conseiller sur la configuration nécessaire pour Pare-feu Azure, mais pas pour d’autres appareils non Microsoft.
• Contrôleurs d’entrée non Microsoft. Pour les contrôleurs tels que nginx, kongou traefik, cela inclut 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, qui peut provenir d’incompatibilités entre la version du contrôleur d’entrée et la nouvelle version de Kubernetes. Pour une option pleinement prise en charge, envisagez une option de contrôleur d’entrée géré par Microsoft.
• Scripts de DaemonSet personnalisés. Bien que l'utilisation DaemonSet soit l'approche recommandée pour régler, modifier ou installer des logiciels non Microsoft sur des nœuds d'agent lorsque les paramètres du fichier de configuration sont insuffisants, Support Microsoft ne peut pas résoudre les problèmes liés aux scripts personnalisés en raison de leur nature personnalisée.
• Assistance en veille et proactive. Support Microsoft fournit une prise en charge réactive pour résoudre les problèmes actifs. La prise en charge de secours ou proactive pour éliminer les risques opérationnels, augmenter la disponibilité et optimiser les performances n’est pas couverte. Les clients éligibles peuvent contacter leur équipe de compte pour obtenir une nomination pour Azure service Gestion des événements, un service payant qui inclut une évaluation proactive des risques de solution et une couverture pendant l’événement.
• CVEs datant de moins de 30 jours. Tant que vous utilisez le VHD mis à jour, vous ne devriez avoir aucune CVE sur les images de conteneur pour laquelle un correctif fourni par l’éditeur date de plus de 30 jours. Il est de votre responsabilité de mettre à jour le disque dur virtuel, puis de filtrer le rapport CVE et de fournir Support Microsoft une liste uniquement des CVE avec un correctif de fournisseur de plus de 30 jours. Microsoft fonctionne ensuite en interne pour traiter les composants avec un correctif de fournisseur publié il y a plus de 30 jours. Microsoft fournit une prise en charge de CVE uniquement pour les composants gérés par Microsoft, tels que les images de nœud AKS et les images de conteneur managées déployées lors de la création du cluster ou via un module complémentaire géré. Pour plus d’informations, consultez Gestion des vulnérabilités pour Azure Kubernetes Service (AKS).
• Exemples de code personnalisés. Support Microsoft pouvez fournir et passer en revue de petits exemples de code dans un cas de support pour montrer comment utiliser des fonctionnalités d'un produit Microsoft, mais ne peut pas fournir d'exemples de code personnalisés spécifiques à votre environnement ou à votre application.
• Logique Azure Policy personnalisée. Support Microsoft pouvez fournir des conseils généraux sur la façon dont les définitions de Azure Policy personnalisées sont appliquées et évaluées dans AKS. La résolution détaillée des problèmes liés à la logique de stratégie créée par le client (y compris les stratégies basées sur rego), comme la raison pour laquelle une stratégie spécifique autorise ou refuse une charge de travail, est généralement en dehors de l’étendue du support.

Apportez vos propres limites de prise en charge CNI

Lorsque vous déployez un cluster avec votre propre CNI (BYOCNI) en utilisant --network-plugin none, Support Microsoft ne peut pas vous aider pour les problèmes liés au CNI. Vous êtes responsable du cycle de vie du plug-in CNI et vous devez demander la prise en charge du fournisseur de plug-in CNI. Microsoft prend toujours en charge les problèmes qui ne sont pas liés à la CNI.

Pour plus d’informations, consultez Utiliser votre propre CNI (BYOCNI).

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

Les sections suivantes décrivent les responsabilités de Microsoft et des clients pour les nœuds d'agents AKS.

Le tableau suivant résume d’un coup d’œil les responsabilités de chaque nœud agent. Les sections qui suivent fournissent les détails.

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

Microsoft et vous partagez la responsabilité des nœuds de l’agent Kubernetes où :

• L’image du système d’exploitation de base a besoin d’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.
• Le système corrige automatiquement les problèmes liés aux composants du plan de contrôle Kubernetes qui s’exécutent sur les nœuds de l’agent. Ces composants incluent les éléments suivants :
  • kube-proxy
  • Tunnels de mise en réseau qui fournissent des chemins de communication vers le plan de contrôle Kubernetes
  • kubelet
  • containerd

Si un nœud d’agent n’est pas opérationnel, AKS peut redémarrer des composants individuels ou l’ensemble du nœud de l’agent. Ces opérations de redémarrage sont automatisées et fournissent une autorémédiation pour les problèmes courants. Pour en savoir plus sur les mécanismes de rémédiation automatique, consultez Node Auto-Repair.

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

Microsoft fournit des correctifs et de nouvelles images pour vos nœuds d’image toutes les semaines. 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. Microsoft ne prend pas en charge les images de nœud antérieures à 90 jours. Pour plus d'informations, consultez les pages suivantes :

• Mettez manuellement à niveau les images de nœud AKS.
• Mettez automatiquement à niveau 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

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 consiste à personnaliser un ensemble de machines virtuelles d'un pool de nœuds en changeant manuellement les configurations dans le portail Azure ou à partir de l’API.

Pour les configurations ou packages spécifiques à la charge de travail, AKS recommande d’utiliser un Kubernetes DaemonSet.

L’utilisation de conteneurs privilégiés Kubernetes DaemonSet et init vous permet de régler/modifier ou d’installer des logiciels non-Microsoft sur les nœuds agents du 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 ce chemin d’accès soit recommandé si les exigences ci-dessus s’appliquent, l’ingénierie et le support AKS ne peuvent pas aider à résoudre ou diagnostiquer les modifications qui rendent le nœud indisponible en raison d’un déploiement DaemonSetpersonnalisé.

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 avec des détails sur l’impact et les étapes à suivre pour résoudre ou atténuer le problème de sécurité.

Accès et maintenance des nœuds

Bien que vous puissiez vous connecter aux nœuds de l’agent et les modifier, n’effectuez pas cette opération. Les modifications peuvent rendre un cluster non pris en charge.

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

Vous pouvez personnaliser des groupes de sécurité réseau (NSG) uniquement sur des sous-réseaux personnalisés. Le tableau suivant indique où vous pouvez personnaliser les groupes de sécurité réseau :

AKS a des exigences de sortie pour des points de terminaison spécifiques. Pour contrôler la sortie et garantir la connectivité nécessaire, consultez limiter le trafic de sortie. Pour l’entrée, les exigences sont basées sur les applications que vous déployez sur le cluster.

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

Le tableau suivant récapitule ce qui se passe pour un cluster AKS dans chaque état de cycle de vie et la chronologie associée :

Si vous n’avez pas besoin de vos charges de travail AKS pour s’exécuter en continu, arrêtez le cluster AKS, ce qui arrête tous les pools de nœuds et le plan de contrôle, puis recommencez-le si nécessaire. L'allocation manuelle de nœuds à l'aide des API IaaS, de l'Azure CLI ou du portail Azure n'est pas un moyen pris en charge d'arrêter un cluster.

AKS se réserve le droit d’archiver les plans de contrôle configurés en dehors des directives de prise en charge pendant des périodes de 30 jours ou plus. AKS gère les sauvegardes des métadonnées du cluster etcd et peut réallouer le cluster sur n’importe quelle opération PUT qui la ramène à la prise en charge, comme une mise à niveau ou une mise à l’échelle vers des nœuds d’agent actifs.

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

AKS prend en charge les fonctionnalités stables et bêta dans le projet Kubernetes en amont, mais pas les fonctionnalités alpha, sauf indication contraire. Le tableau suivant résume la prise en charge par type de fonctionnalité :

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é. 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. Les équipes de support technique AKS fournissent un support uniquement pendant les heures d’ouverture. Pour plus d’informations, consultez Azure FAQ sur le support technique.

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, les correctifs de bogues nécessitent des correctifs plus volumineux pour les projets en amont (comme Kubernetes, les systèmes d’exploitation de nœud ou d’agent et le noyau). Pour les composants qui Microsoft possède (comme le fournisseur de cloud Azure), AKS et le personnel Azure sont engagés à résoudre 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 requis afin qu’ils puissent observer les problèmes et voir quand une nouvelle version fournit 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. 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.

Contenu connexe

• Niveaux tarifaires AKS
• Versions de Kubernetes prises en charge dans AKS
• Prise en charge à long terme d’AKS
• Mettre à niveau automatiquement un cluster AKS
• Mettre automatiquement à niveau les images du système d’exploitation du nœud AKS
• Gestion des vulnérabilités pour AKS
• Réparation automatique des nœuds AKS
• Apportez votre propre CNI (BYOCNI)