Plane eine Container-Apps-Bereitstellung auf Azure Arc-fähigem Kubernetes

Verwenden Sie diesen Artikel, bevor Sie die Container Apps-Erweiterung auf einem Produktionscluster installieren. Container Apps in Azure Arc nutzt Kapazitäten und Plattformdienste, die von Ihrem Kubernetes-Cluster bereitgestellt werden. Entscheidungen über Knoten, Lastverteilung, DNS, ausgehende Konnektivität, Speicher, Identität, Logging und Upgrades beeinflussen die Anwendungsverfügbarkeit.

Nutzen Sie die Abschnitte in diesem Artikel, um Bereitstellungsanforderungen zu identifizieren und Voraussetzungen vor der Installation zu validieren.

Planungsumfang

Container Apps auf Azure Arc umfasst Azure-Ressourcen, einen bestehenden Kubernetes-Cluster und bereitgestellte Anwendungen. Planen Sie für die folgenden Bereiche:

Unterstützte Topologie und Versionsmatrix

Verwenden Sie die aktuelle, vom Hersteller unterstützte Kubernetes-Patch-Version, die auch Azure Arc-fähiges Kubernetes unterstützt. Die Container-Apps-Dokumentation veröffentlicht für jede Distribution keinen separaten Kubernetes-Versionsbereich. Überprüfe die genaue Distribution und die Kubernetes-Version mit Microsoft-Unterstützung vor einer Produktionsinstallation oder einem Upgrade.

Die folgende Matrix dokumentiert die derzeit veröffentlichte Verteilungsunterstützung. Überprüfen Sie dies vor jeder Installation erneut anhand von Verfügbare Erweiterungen für Azure Arc aktivierte Kubernetes-Cluster und Einschränkungen von Azure Container Apps auf Azure Arc.

Die Erweiterung wird auf Windows-Knoten oder Arm64-Clustern nicht unterstützt. Das Arc-Erweiterungs-Framework benötigt mindestens einen geeigneten linux/amd64 Knoten, aber eine Produktionsbereitstellung benötigt genügend geeignete Knoten für die Erweiterung, Arbeitslasten, Upgrades und Ausfälle.

Nur eine unterstützte KEDA-Installation kann auf dem Cluster laufen. Bestimmen Sie, ob KEDA von der Container Apps-Erweiterung installiert wird oder bereits im Cluster existiert. Wenn KEDA bereits existiert, stoppen Sie und bestätigen Sie die unterstützte Koexistenzkonfiguration, bevor Sie fortfahren. Entferne nicht die bestehende KEDA-Installation und wende keine undokumentierten Erweiterungseinstellungen an, da andere Arbeitslasten davon abhängen könnten.

Kapazitätsanforderungen

Plankapazität für:

• Die festen und Pro-Knoten-Komponenten der Container Apps-Erweiterung sind unter Von der Container Apps-Erweiterung erstellte Ressourcen aufgeführt.
• Die maximal zulässige Anzahl von Replikaten für jede Container-App.
• Gleichzeitige Auftragsausführungen und Wiederholungsbursts.
• Dapr-Seitenwagen und Anwendungs-Seitenwagen.
• Kubernetes-System-Workloads und andere Cluster-Tenants.
• Fortlaufende Upgrades von Knoten und Erweiterungen.
• Mindestens ein Knotenausfall in einer hochverfügbaren Bereitstellung.

Das Setzen einer maximalen Replikanzahl einer Anwendung reserviert keine Clusterkapazität.

Mindestinstallationskapazität

Es gibt kein universelles Produktionsminimum, da die Platzierung von Erweiterungen, aktivierte Komponenten, Knotenanzahl, Daemon-Workloads, KEDA-Installation, Log Analytics, Dapr-Nutzung und Workload-Anfragen variieren. Verwenden Sie die veröffentlichten Erweiterungskomponentenanforderungen als Basislinie und messen zuteilbare, nicht vollständige, Knotenressourcen. Die Größe eines Evaluierungsclusters ist keine Empfehlung zur Dimensionierung für den Produktiveinsatz.

Vor der Installation notieren:

• Zuweisbare CPU-Leistung und zuweisbarer Speicher auf geeigneten linux/amd64 Knoten.
• Anzahl der Knoten und Platzierung der Fehlerdomäne.
• Kostenlose Pod- und Service-IP-Kapazität.
• Aktuelle System- und Mieteranforderungen und -limits.
• Kapazität ist wegen Verunreinigungen, Affinität, Quoten oder Störungsbudgets nicht verfügbar.

Schätzung der Arbeitslastkapazität

Für jede Anwendung berechnen Sie:

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

Fügen Sie Spitzenkapazität für gleichzeitig ausgeführte Aufträge, Erweiterungskapazität, Systemreserven, Upgrade-Spitzenlast und Ausfallreserven hinzu. Stellen Sie sicher, dass Knoten-Labels, Taints, Affinitätsregeln und Ressourcenfragmentierung nicht dazu führen, dass die nominell freie Kapazität nicht eingeplant werden kann.

Validieren Sie den Plan, indem Sie repräsentative Workloads einplanen und das Leeren eines Knotens simulieren. Bestätigen Sie, dass Erweiterungskapseln und die erforderlichen Workload-Repliken weiterhin einsatzbereit sind.

Netzwerkanforderungen

Container Apps in Azure Arc benötigen mehrere unterschiedliche Netzwerkpfade:

Verwenden Sie Azure Arc-fähige Kubernetes-Netzwerkanforderungen als kanonische Endpunktliste. Kopiere die Endpunktliste nicht in ein Firewall-Regelset, ohne die richtige Azure Cloud auszuwählen und Arc-Funktionen aktiviert zu haben. Teste jeden erforderlichen vollständig qualifizierten Domainnamen (FQDN) aus dem Clusternetzwerk. Die Arc-Anforderungen besagen, dass HTTPS-Endpunkte offiziell signierte und verifizierbare Zertifikate verwenden. Bestätigen Sie das Verhalten von Proxy- und TLS-Inspektionen in einem nicht-produktiven Cluster; Nicht unterstützte Abhörung oder ein nicht vertrauenswürdiges Ersatzzertifikat können verhindern, dass Agenten und Erweiterungskomponenten sich verbinden.

Die ausgewählte LoadBalancer Implementierung bestimmt den Adresspool, die Gesundheitsproben, das Routing und die erforderliche Kapazität. Wenn ein benutzerdefinierter Load Balancer eine reservierte Adresse benötigt, reservieren Sie zuerst die Adresse und leiten Sie sie während der Installation durch die Erweiterungseinstellung loadBalancerIp . Health-Probe-Ports und Quellbereiche sind implementierungsspezifisch; beziehen Sie sie vom ausgewählten Load Balancer, anstatt von Azure Load Balancer-Standardeinstellungen auszugehen.

Der zugrundeliegende, Arc-fähige Kubernetes-Cluster steuert Netzwerkbeschränkungen für die verbundene Umgebung. Wenn eine Anwendungsabhängigkeit einen privaten Endpunkt verwendet, verifizieren Sie in einem Anwendungspod, ob der Cluster seinen DNS-Namen auflösen und zu seiner privaten IP routen kann. Anwendungen, die Client-IP-Informationen benötigen, sollten die von der gewählten Lastbalancer- und Proxy-Kette erzeugten Weiterleitungsheader validieren und definieren, welche Proxys vertrauenswürdig sind.

Überprüfen des Netzwerks

1. Stellen Sie einen Kubernetes-Testdienst LoadBalancer bereit und bestätigen, dass er eine Adresse erhält, die von jedem vorgesehenen Client-Netzwerk erreichbar ist.
2. Von einem zugelassenen Cluster-Node oder Diagnosepod aus lösen und verbinden Sie sich mit jedem erforderlichen Azure Arc-Endpunkt und jeder Workload-Abhängigkeit.
3. Bestätigen Sie, dass der Proxy den erforderlichen HTTPS- und WebSocket-Verkehr zulässt und keine Zertifikate durch einen nicht vertrauenswürdigen Herausgeber ersetzt.
4. Bestätigen Sie, dass Cluster-DNS, Pod-to-Pod-Verkehr, Dienste, Admission-Webhooks und Load-Balancer-Gesundheitsprüfungen mit den beabsichtigten Netzwerkrichtlinien funktionieren.
5. Nach der Installation der Erweiterung sollte vor der Erstellung von Produktions-DNS-Einträgen sichergestellt werden, dass der Ingress-Dienst die geplante IP erhält und erreichbar ist.

DNS-Anforderungen

Installieren Sie nach der Installation einer Erweiterung eine Testanwendung, und rufen Sie deren generierte FQDN ab. Überprüfen Sie, dass das FQDN den Erweiterungseingang von jedem vorgesehenen Client-Netzwerk auflöst und erreicht. Der Connected-Environment-Name ist Teil der generierten Anwendungsdomäne, daher wählen Sie ihn bewusst aus.

Für interne Anwendungen verwenden Sie Split-Horizon-DNS, wenn interne und externe Clients unterschiedliche Antworten benötigen. Identifizieren Sie die autoritative DNS-Zone, zeichnen Sie die Time to Live und die Wiederherstellungsanforderungen auf. Bestimmen Sie, ob Anwendungen die generierte Domäne, benutzerdefinierte Domains oder beides verwenden, und planen Sie die Ausstellung und Erneuerung von Zertifikaten vor der Bereitstellung.

DNS und Ingress aus jedem vorgesehenen Client-Netzwerk validieren:

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

Das Anwendungs-FQDN muss auf die Ingress-IP aufgelöst werden und die erwartete Anwendungsantwort zurückgeben. Entferne Autorisierungsheader, Cookies und sensible Abfragezeichen, bevor du ausführliche Ausgaben teilst.

Identität, Geheimnisse und Register

Verwaltete Identitäten werden für Container-Anwendungen in Azure Arc nicht unterstützt. Das Herunterziehen von Images aus der Azure Container Registry mit verwalteter Identität wird ebenfalls nicht unterstützt.

Für den Zugriff auf Azure-Ressourcen verwenden Sie eine dedizierte Anwendungsregistrierung und Service Principal nur, wenn der Zieldienst dies unterstützt. Gewähren Sie nur die erforderlichen Rollen auf der Datenebene im kleinstmöglichen praktikablen Umfang. Halte die Tenant-ID und die Client-ID von der Zugangsberechtigung getrennt, verwende ein Zertifikat, wenn die Anwendung und der Zieldienst dies unterstützen, und plane das Ablauf- und Rotationsdatum der Zugangsdaten. Verwenden Sie nicht die Arc-Connected-Cluster-Identität oder eine Cluster-Administrator-Identität für den Anwendungszugriff.

Für private Registrys verwenden Sie registryspezifische Anmeldeinformationen mit ausschließlichem Pull-Zugriff, sofern die Registry dies unterstützt. Vermeide ACR-Administratorzugangsdaten für Produktionsworkloads. Speichere Registry- und Anwendungszugangsdaten als Container-Apps-Geheimnisse und referenziere sie anhand des Namens in der Anwendungskonfiguration.

Die Geheimnisse von Container-Apps sind applikationsbezogen, und das Ändern eines Geheimnisses aktualisiert bestehende Versionen nicht automatisch. Behandle sowohl den Zugriff auf Azure-Kontrollebenen als auch den privilegierten Kubernetes-Zugriff als Sicherheitsgrenzen. Beschränken Sie den Zugriff auf die Erweiterungen und Anwendungsnamensräume gemäß den Kubernetes-Sicherheitsanforderungen für die Bereitstellung.

Verwenden Sie diese Rotationssequenz:

1. Erstelle eine zweite gültige Zugangsdaten beim Identitätsanbieter oder Registry.
2. Aktualisieren Sie das Container-Apps-Geheimnis und deployen oder starten Sie die betroffene Version bei Bedarf neu aus.
3. Überprüfen Sie die Bildabrufe und die Anwendungsauthentifizierung mit der neuen Zugangsberechtigung.
4. Entziehe die alte Zulassung.
5. Bestätigen Sie, dass keine aktive Version oder Job noch auf den alten Wert verweist.

Platzieren Sie niemals geheime Werte in Befehlsverlauf, Quellcode, Diagnosebündel, Pod-Beschreibungen oder Anwendungsprotokollen. Begrenze, wer Erweiterungsgeschützte Einstellungen und Kubernetes-Geheimnisse lesen kann.

Lagerung

Plane die Speicherung entsprechend der von der Arbeitslast benötigten Persistenz:

Die Einschränkungen für Container Apps auf Arc beziehen sich derzeit auf Azure Files SMB und erfordern den SMB-CSI-Treiber. Gehen Sie nicht davon aus, dass ein Volumetyp, der von in Azure gehosteten Container Apps unterstützt wird, auch auf Arc unterstützt wird. Verwenden Sie stattdessen die SMB-Installationsbefehle, auf die in Azure Container Apps on Azure Arc verwiesen wird, anstatt hier eine weitere Kopie zu pflegen.

Behandle Speicherkonto-Zugangsdaten, die für ein Mount verwendet werden, als Geheimnisse. Verwaltete Identitäten werden für Container Apps on Arc nicht unterstützt. Teste die ausgewählten Mount-Optionen, Dateiberechtigungen, gleichzeitigen Zugriff, Fehlerverhalten und Credential-Rotation mit genau den CSI-Treiber- und Storage Service-Versionen, die in der Produktion verwendet werden.

Planen Sie persistente Datensicherungen, Wiederherstellungstests, Aufbewahrung und Notfallwiederherstellung. Testen Sie, wie Revisionen und Jobs Mount-Fehler melden, und beziehen Sie Pod-Events und CSI-Treiberprotokolle in das Diagnoseverfahren ein. Linux ist das einzige unterstützte Node-Betriebssystem für die Erweiterung.

Beobachtbarkeit des Plans

Die Integration von Log Analytics ist optional. Wenn du sie verwenden willst, konfiguriere sie bei der Installation der Erweiterung, da du sie später nicht mehr zu dieser Erweiterungsinstanz hinzufügen kannst.

Wenn Sie Log Analytics konfigurieren, finden Sie Anwendungsprotokolle in ContainerAppConsoleLogs_CL. Im Tutorial „Create a container app on Azure Arc“ wird TimeGenerated, ContainerAppName_s und Log_s gezeigt; prüfen Sie die Live-Tabelle, bevor Sie Abfragen oder Warnungen erstellen. Planen Sie 10 bis 15 Minuten ein, um die Erstaufnahme zu validieren.

Planen Sie die Kosten für Arbeitsbereichszugriff, Datenaufbewahrung, Warnungen, Export und Erfassung. Überprüfen Sie die Anwendungsprotokollierung auf Zugangsdaten, persönliche Daten und sensible URLs, bevor Sie die Sammlung aktivieren.

Wenn Sie Log Analytics nicht konfigurieren oder wenn ein Erfassungsproblem auftritt, verwenden Sie Kubernetes-Protokolle:

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

Systemkomponenten schreiben Protokolle in die Standardausgabe. Standardmäßig wird die Telemetrie der Systemkomponenten an Microsoft gesendet, während Anwendungsprotokolle nicht gesendet werden, es sei denn, Sie konfigurieren Log Analytics. Die Einstellung logProcessor.enabled=false deaktiviert die Protokollverarbeitung und die Weiterleitung an den Arbeitsbereich und kann die Menge der Diagnosedaten erhöhen, deren manuelle Erfassung vom Support angefordert wird.

Teste vor der Produktion eine eindeutige Anwendungslog-Nachricht von Anfang bis Ende, erstelle Warnungen für Erweiterungsgesundheit und Anwendungsfehler und prüfe, dass sowohl Azure- als auch Kubernetes-Diagnosen zugänglich sind.

Upgrade, Backup und Wiederherstellung

Wählen Sie einen Release-Zyklus für Erweiterungen und eine Upgrade-Richtlinie aus und dokumentieren Sie diese. Das Container-Apps-Setup-Tutorial verwendet den Release-Zug stable mit automatischen Upgrades für kleinere Versionen. Azure Arc-Cluster-Erweiterungen können einem Release-Zug mit automatischen Upgrades folgen oder manuell gepinnt und aktualisiert werden. Überprüfen Sie die Veröffentlichungsnotizen der Container Apps-Erweiterungen , bevor Sie die Version wechseln, und stellen Sie freie Kapazität, kompatible Kubernetes-Versionen, Wartungsfenster und Anwendungsvalidierungen bereit.

Vor einer Erweiterung oder einem Kubernetes-Upgrade:

1. Bestätigen Sie, dass die Bereitstellungszustände des verbundenen Clusters und der Erweiterung Succeeded sind.
2. Bestätigen Sie, dass die Kombination aus Ziel-Kubernetes-Version und Erweiterung unterstützt wird.
3. Überprüfen Sie die Versionshinweise und die aktuelle Konfiguration, einschließlich Release Train, der Einstellung für automatische Upgrades, der KEDA-Installation, der Namensräume, von Log Analytics und loadBalancerIp.
4. Überprüfen Sie, ob für eine schrittweise Ersetzung genügend freie Kapazität vorhanden ist, und bestätigen Sie, dass die Disruption-Budgets den Vorgang zulassen.
5. Verifizieren Sie die Konnektivität des Bildregisters und die Zulassungsrichtlinien für die Zielbilder.
6. Sichern Sie die Quellkonfiguration der Anwendung und alle persistenten Anwendungsdaten.
7. Führen Sie Anwendungs-, Ingress-, Skalierungs-, Auftrags-, Speicher- und Protokolltests vor und nach der Änderung durch.

Behandle das Kubernetes-Namespace-Backup nicht als Backup der Azure-Ressourcen. Der verbundene Cluster, die Erweiterung, der benutzerdefinierte Standort, die verbundene Umgebung, Container-Apps und Jobs werden im Azure Resource Manager dargestellt und haben Abhängigkeiten von In-Cluster-Ressourcen. Sichern Sie die deklarative Anwendungskonfiguration separat. Stellen Sie keine manuell verwalteten Erweiterungs-Deployments, benutzerdefinierten Ressourcen oder Geheimnisse über eine neu installierte Erweiterung wieder her, es sei denn, der Microsoft-Support bietet dieses Wiederherstellungsverfahren an.

Ein Downgrade oder Rollback der Erweiterung ist kein allgemeiner Wiederherstellungsmechanismus, der für Container Apps auf Arc dokumentiert ist. Ändere nicht den Release-Zug, pin keine ältere Version oder ändere keine von Erweiterungen verwalteten Workloads als Incident Response, ohne einen unterstützten Pfad mit Microsoft-Unterstützung zu bestätigen.

Entwickeln und testen Sie ein Recovery-Runbook, das Kubernetes-Infrastruktur, Netzwerke, DNS, Lastverteilung, Speicher, Azure Arc-Agenten, die Container Apps-Erweiterung, benutzerdefinierten Standort, verbundene Umgebung, Anwendungskonfiguration, Zugangsdaten und persistente Anwendungsdaten berücksichtigt. Überprüfen Sie Ingress, Revisionen, Skalierung, Jobs, Speicher und Protokolle nach der Wiederherstellung. Verwenden Sie Wiederherstellungsverfahren, die von der Kubernetes-Topologie und Backup-Produkten in der Bereitstellung unterstützt werden.

Planen Sie eine Azure-Trennung. Arc-Agenten benötigen Konnektivität, um Erweiterungsänderungen zu erkennen und den gewünschten Zustand weiterzugeben. Geschützte Einstellungen für eine neu erstellte Erweiterungsressource werden bis zu 48 Stunden aufbewahrt; bleibt der Cluster während dieses Zeitraums getrennt, kann die Erweiterung von Pending zu Failedwechseln. Teste das Workload-Verhalten während des Ausfalls der Azure-Konnektivität, anstatt eine Continuity-Garantie anzunehmen.

Verwandte Inhalte

• Azure Container Apps in Azure Arc
• Richte einen Azure Arc-fähigen Kubernetes-Cluster ein, um Azure Container Apps auszuführen
• Erstellen einer Container-App in Azure Arc
• Problembehandlung für Azure Container Apps in Azure Arc-fähigem Kubernetes
• Azure Arc-fähige Kubernetes-Netzwerkanforderungen
• Benutzerdefinierte Standorte auf Azure Arc-fähigem Kubernetes
• Cluster-Erweiterungen in Azure Arc-enabled Kubernetes