Planifiez un déploiement de Container Apps sur Kubernetes compatible Azure Arc

Utilisez cet article avant d’installer l’extension Conteneurs Applications sur un cluster de production. Les applications conteneurs sur Azure Arc utilisent la capacité et les services de plateforme fournis par votre cluster Kubernetes. Les décisions concernant les nœuds, l’équilibrage de charge, le DNS, la connectivité sortante, le stockage, l’identité, la journalisation et les mises à jour influencent la disponibilité des applications.

Utilisez les sections de cet article pour identifier les exigences de déploiement et valider les prérequis avant l’installation.

Champ d’action de la planification

Conteneurs Apps sur Azure Arc couvre les ressources Azure, un cluster Kubernetes existant et les applications déployées. Prévoyez les zones suivantes :

Topologie prise en charge et matrice de versions

Utilisez la dernière version du correctif Kubernetes prise en charge par un fournisseur que Kubernetes compatible Azure Arc prend également en charge. La documentation Container Apps ne publie pas de plage de versions Kubernetes séparée pour chaque distribution. Validez la distribution exacte et la version Kubernetes avec le support Microsoft avant une installation ou une mise à jour en production.

La matrice suivante enregistre le support de distribution actuellement publié. Validez-le de nouveau par rapport aux extensions disponibles pour les clusters Kubernetes compatibles avec Azure Arc et aux limitations d’Azure Container Apps sur Azure Arc avant chaque installation.

L'extension n'est pas prise en charge sur les nœuds Windows ni sur les clusters Arm64. Le cadre d’extension Arc nécessite au moins un nœud adapté linux/amd64 , mais un déploiement en production nécessite suffisamment de nœuds adaptés pour l’extension, les charges de travail, les mises à jour et les défaillances.

Une seule installation KEDA prise en charge peut fonctionner sur le cluster. Déterminez si KEDA sera installé par l’extension Container Apps ou s’il existe déjà sur le cluster. Si KEDA existe déjà, arrêtez et confirmez la configuration de coexistence prise en charge avant de continuer. Ne supprimez pas l’installation KEDA existante ni n’appliquez les paramètres d’extension non documentés car d’autres charges de travail pourraient en dépendre.

Besoins en capacité

Capacité de planification pour :

• Les composants fixes et par nœud de l’extension Conteneur Apps listés dans Ressources créées par l’extension Conteneur Applications.
• Le nombre maximal de répliques prévues pour chaque application conteneur.
• Exécutions concurrentes de tâches et rafales de retentatives.
• Sidecars Dapr et sidecars applicatifs.
• Charges de travail système Kubernetes et autres locataires de cluster.
• Mises à niveau propagée de nœud et d’extension.
• Défaillance d’au moins un nœud dans un déploiement à haute disponibilité.

Définir le nombre maximal de répliques d’une application ne réserve pas la capacité du cluster.

Capacité minimale d’installation

Il n'y a pas de minimum universel de production car le placement des extensions, les composants activés, le nombre de nœuds, les charges de travail des démons, l'installation de KEDA, Log Analytics, l'utilisation de Dapr et les demandes de charge de travail varient. Utilisez les requêtes de composants d’extension publiées comme référence et mesurez les ressources de nœud allouables, pas totales. La taille d’un groupe d’évaluation n’est pas une recommandation de taille de production.

Avant l’installation, notez :

• Processeur et mémoire allouables sur les nœuds linux/amd64 éligibles.
• Nombre de nœuds et répartition par domaine de panne.
• Capacité IP gratuite pour les pods et les services.
• Système actuel et demandes de locataires et limites.
• Capacité indisponible à cause de problèmes d'altérations, d’affinité, de quotas ou de budgets d'interruption.

Estimation de la capacité de charge de travail

Pour chaque application, calculez :

peak capacity = maximum replicas x (application requests + sidecar requests)

Ajoutez la capacité maximale de tâches simultanées, la capacité d’extension, la réserve système, la capacité supplémentaire pour la mise à niveau et la réserve en cas de défaillance. Assurez-vous que les étiquettes de nœuds, les contaminations, les règles d’affinité et la fragmentation des ressources ne rendent pas la capacité nominalement libre non planifiable.

Validez le plan en planifiant des charges de travail représentatives et en simulant un drain de nœud. Confirmez que les modules d’extension et les répliques de charge de travail requises restent prêts.

Configuration réseau requise

Les applications conteneurs sur Azure Arc nécessitent plusieurs chemins réseau distincts :

Utilisez les exigences réseau Kubernetes activées par Azure Arc comme liste canonique des points de terminaison. Ne copiez pas la liste des points de terminaison dans un ensemble de règles de pare-feu sans avoir sélectionné le bon cloud Azure et activé les fonctionnalités Arc. Testez tous les noms de domaine pleinement qualifiés (FQDN) requis du réseau du cluster. Les exigences d’Arc stipulent que les terminaux HTTPS utilisent des certificats officiellement signés et vérifiables. Confirmer le comportement d’inspection proxy et TLS dans un cluster non productif ; une interception non prise en charge ou un certificat de remplacement non fiable peut empêcher la connexion des agents et des composants d’extension.

L’implémentation sélectionnée LoadBalancer détermine le pool d’adresses, les sondes de santé, le routage et la capacité requise. Si un équilibreur de charge personnalisé nécessite une adresse réservée, réservez d’abord l’adresse et passez-la dans le paramètre d’extension loadBalancerIp lors de l’installation. Les ports de la sonde de santé et les plages source sont spécifiques à chaque implémentation ; obtenez-les auprès de l’équilibreur de charge sélectionné plutôt que d’assumer les valeurs par défaut d’Azure Load Balancer.

Le cluster Kubernetes compatible Arc sous-jacent contrôle les restrictions réseau pour l’environnement connecté. Si une dépendance d’application utilise un point de terminaison privé, vérifiez depuis un pod d’application que le cluster peut résoudre son nom DNS et acheminer vers son IP privée. Les applications nécessitant des informations IP client doivent valider les en-têtes de redirection produits par l’équilibreur de charge et la chaîne de proxy sélectionnés et définir quels proxys sont fiables.

Valider la mise en réseau

1. Déploie un service de test Kubernetes LoadBalancer et confirme qu’il reçoit une adresse accessible depuis chaque réseau client prévu.
2. Depuis un nœud de cluster ou un pod de diagnostic éligible, résoudre et se connecter à tous les points de terminaison Azure Arc et dépendances de charge de travail nécessaires.
3. Confirmez que le proxy permet le trafic HTTPS et WebSocket requis et ne remplace pas les certificats par un émetteur non fiable.
4. Confirmez que le DNS du cluster, le trafic entre pods, les services, les webhooks d’admission et les sondes de santé de l’équilibreur de charge fonctionnent avec les politiques réseau prévues.
5. Après l’installation de l’extension, confirmez que le service d’entrée reçoit l’IP prévue et est joignable avant de créer des enregistrements DNS de production.

Configuration requise du DNS

Après l’installation de l’extension, déployez une application de test et récupérez son FQDN généré. Vérifiez que le nom de domaine complet se résout et atteint l’entrée de l’extension à partir de chaque réseau client concerné. Le nom d’environnement connecté fait partie du domaine d’application généré, donc choisissez-le délibérément.

Pour les applications internes, utilisez le DNS à horizon partagé lorsque les clients internes et externes nécessitent des réponses différentes. Identifier la zone DNS autoritaire, enregistrer le temps de vie et les besoins de récupération. Déterminez si les applications utilisent le domaine généré, des domaines personnalisés ou les deux, et planifiez l’émission et le renouvellement des certificats avant le déploiement.

Validez le DNS et les entrées depuis chaque réseau client prévu :

nslookup <APPLICATION_FQDN>
curl --verbose https://<APPLICATION_FQDN>

Le nom de domaine complet de l’application doit pointer vers l’adresse IP d’entrée et renvoyer la réponse attendue de l’application. Supprimez les en-têtes d’autorisation, les cookies et les chaînes de requêtes sensibles avant de partager une sortie verbose.

Identité, secrets et registres

Les identités gérées ne sont pas prises en charge pour les applications conteneurs sur Azure Arc. Extraire des images d'Azure Container Registry en utilisant une identité managée n'est pas non plus pris en charge.

Pour accéder aux ressources Azure, utilisez un principal dédié d’enregistrement d’application et de service uniquement lorsque le service cible le supporte. Accorder uniquement les rôles requis dans le plan de données dans le cadre pratique le plus restreint. Gardez l’identifiant locataire et l’identifiant client séparés de l’identifiant, utilisez un certificat lorsque l’application et le service cible le supportent, et planifiez l’expiration et la rotation des identifiants. Ne réutilisez pas l’identité du cluster connecté Arc ni celle d’administrateur du cluster pour l’accès aux applications.

Pour les registres privés, utilisez des informations d’identification propres au registre avec un accès en lecture seule, si le registre le permet. Évitez d’utiliser les identifiants du compte administrateur ACR pour les charges de travail en production. Stockez les identifiants du registre et des applications sous forme de secrets des applications conteneurs et référencez-les par leur nom depuis la configuration de l’application.

Les secrets de Container Apps sont définis au niveau de l’application, et la modification d’un secret ne met pas automatiquement à jour les révisions existantes. Considérez à la fois l’accès Azure sur le plan de contrôle et l’accès privilégié Kubernetes comme des limites de sécurité. Restreignez l’accès aux espaces d’extension et d’applications conformément aux exigences de sécurité de Kubernetes pour le déploiement.

Utilisez cette séquence de rotation :

1. Créez une seconde accréditation valide auprès du fournisseur d’identité ou du registre.
2. Mettez à jour le secret des Conteneurs Apps et déployez ou redémarrez la version concernée selon les besoins.
3. Vérifiez les extractions d’images et l’authentification de l’application avec les nouvelles informations d'identification.
4. Retirez l’ancien diplôme.
5. Confirmez qu’aucune révision ou poste actif ne fait encore référence à l’ancienne valeur.

Ne jamais placer de valeurs secrètes dans l’historique des commandes, le contrôle de version, les packs de diagnostic, les descriptions de pods ou les journaux d’application. Limitez qui peut lire les paramètres protégés par extension et les secrets Kubernetes.

Storage

Planifiez le stockage selon la persistance requise par la charge de travail :

Les limitations des applications conteneurisées sur Azure Arc mentionnent actuellement Azure Files SMB et nécessitent le pilote CSI SMB. Ne supposez pas qu'un type de volume pris en charge par les Conteneurs Apps hébergés sur Azure est pris en charge sur Arc. Utilisez les commandes d'installation SMB liées depuis Azure Container Apps sur Azure Arc au lieu de maintenir une autre copie ici.

Considérez les informations d’identification du compte de stockage utilisées pour un montage comme des secrets. Les identités gérées ne sont pas prises en charge pour les applications conteneurs sur Arc. Testez les options de montage sélectionnées, les permissions des fichiers, l’accès simultané, le comportement de défaillance et la rotation des identifiants avec les versions exactes du pilote CSI et du service de stockage utilisées en production.

Planifiez la sauvegarde persistante des données, les tests de restauration, la rétention et la reprise après sinistre. Testez comment les révisions et les jobs signalent les échecs de montage, et incluez les événements du pod et les journaux du pilote CSI dans la procédure de diagnostic. Linux est le seul système d’exploitation nœud supporté pour l’extension.

Observabilité du plan

L’intégration de Log Analytics est optionnelle. Si vous comptez l’utiliser, configurez-la lors de l’installation de l’extension car vous ne pourrez pas l’ajouter à cette instance plus tard.

Lorsque vous configurez Log Analytics, vous pouvez consulter les journaux d’application dans ContainerAppConsoleLogs_CL. Le tutoriel Créer une application conteneur sur Azure Arc démontre TimeGenerated, ContainerAppName_s, et Log_s; inspectez la table en direct avant de créer des requêtes ou des alertes. Prévoyez 10 à 15 minutes lors de la validation de l’ingestion initiale.

Planifiez l’accès à l’espace de travail, la rétention, les alertes, l’exportation et les coûts d’ingestion. Vérifiez la journalisation des applications pour les identifiants, les données personnelles et les URL sensibles avant d’activer la collecte.

Si vous ne configurez pas Log Analytics, ou lors d'un incident d'ingestion, utilisez les logs Kubernetes :

kubectl get pods -n <APPS_NAMESPACE> -o wide
kubectl logs -n <APPS_NAMESPACE> <POD_NAME> --all-containers=true --tail=200
kubectl get events -n <APPS_NAMESPACE> --sort-by=.lastTimestamp

Les composants système écrivent des logs sur la sortie standard. Par défaut, la télémétrie des composants système est envoyée à Microsoft tandis que les journaux d'application ne sont pas envoyés à moins que vous ne configuriez Log Analytics. Le fait de définir logProcessor.enabled=false désactive le traitement des journaux et leur transfert vers l’espace de travail, et peut augmenter les informations de diagnostic que le support vous demande de recueillir manuellement.

Avant la production, testez un message unique du journal d’application de bout en bout, créez des alertes pour la santé des extensions et les défaillances d’applications, et confirmez que les diagnostics Azure et Kubernetes sont accessibles.

Mise à niveau, sauvegarde et récupération

Sélectionnez et documentez un cycle de publication des extensions et une politique de mise à niveau. Le tutoriel de configuration de Container Apps utilise le canal de publication stable avec des mises à niveau mineures automatiques. Les extensions de cluster Azure Arc peuvent suivre un cycle de publication avec des mises à niveau automatiques, ou être figées sur une version et mises à niveau manuellement. Consultez les notes de version de l’extension Conteneur Apps avant de changer de version, et fournissez la capacité disponible, des versions Kubernetes compatibles, des fenêtres de maintenance et une validation des applications.

Avant une extension ou une mise à jour Kubernetes :

1. Confirmez que les états d’approvisionnement du cluster connecté et de l’extension sont Succeeded.
2. Confirmez que la combinaison Kubernetes cible et extension est prise en charge.
3. Consultez les notes de version et la configuration actuelle, y compris le train de version, le réglage de mise à jour automatique, l’installation KEDA, les espaces de noms, Log Analytics, et loadBalancerIp.
4. Vérifiez la capacité disponible pour un remplacement progressif et confirmez que les budgets d’indisponibilité permettent de poursuivre l’opération.
5. Vérifiez la connectivité du registre d’images et les politiques d’admission pour les images cibles.
6. Sauvegardez la configuration des sources d’application et toutes les données persistantes.
7. Effectuez des tests de fumée applicatifs, d’entrée, de mise à l’échelle, de travail, de stockage et de consignation avant et après le changement.

Ne considérez pas la sauvegarde de l'espace de noms Kubernetes comme une sauvegarde des ressources Azure. Le cluster connecté, l’extension, la localisation personnalisée, l’environnement connecté, les applications conteneurs et les jobs sont représentés dans Azure Resource Manager et dépendent des ressources intégrées au cluster. Sauvegardez séparément la configuration déclarative de l’application. Ne restaurez pas manuellement les déploiements gérés par extensions, les ressources personnalisées ou les secrets sur une extension nouvellement installée à moins que le support Microsoft ne fournisse cette procédure de récupération.

La rétrogradation de l’extension ou le retour à une version antérieure ne constituent pas un mécanisme général de récupération documenté pour Container Apps sur Arc. Ne modifiez pas le canal de publication, ne figez pas une version antérieure et ne modifiez pas les charges de travail gérées par l’extension comme mesure de réponse à un incident sans avoir confirmé auprès du support Microsoft qu’une telle procédure est prise en charge.

Développez et testez un runbook de récupération qui prend en compte l’infrastructure Kubernetes, le réseau, le DNS, l’équilibrage de charge, le stockage, les agents Azure Arc, l’extension Container Apps, la localisation personnalisée, l’environnement connecté, la configuration des applications, les identifiants et les données persistantes de l’application. Validez les entrées, les révisions, la mise à l’échelle, les tâches, le stockage et les journaux après récupération. Utilisez les procédures de récupération prises en charge par la topologie Kubernetes et les produits de sauvegarde dans le déploiement.

Prévoyez la déconnexion Azure. Les agents Arc ont besoin d’une connectivité pour détecter les modifications apportées aux extensions et propager l’état souhaité. Les paramètres protégés pour une ressource d’extension nouvellement créée sont conservés jusqu’à 48 heures ; si le cluster reste déconnecté pendant cette période, l’extension peut passer de Pending à Failed. Tester le comportement de la charge de travail lors de la perte de connectivité Azure plutôt que de supposer une garantie de continuité.

Contenu connexe

• Azure Container Apps sur Azure Arc
• Configurez un cluster Kubernetes compatible avec Azure Arc pour exécuter Azure Container Apps
• Créer une application de conteneur sur Azure Arc
• Résoudre les problèmes liés à Azure Container Apps sur Kubernetes avec Azure Arc
• Configuration réseau Kubernetes compatible avec Azure Arc
• Emplacements personnalisés sur Kubernetes avec Azure Arc
• Extensions cluster dans Kubernetes compatible avec Azure Arc