Plan een Container Apps-implementatie op Azure Arc-enabled Kubernetes

Gebruik dit artikel voordat je de Container Apps-extensie installeert op een productiecluster. Container Apps op Azure Arc gebruikt capaciteits- en platformdiensten die door je Kubernetes-cluster worden geleverd. Beslissingen over nodes, load balancing, DNS, uitgaande connectiviteit, opslag, identiteit, logging en upgrades beïnvloeden de beschikbaarheid van applicaties.

Gebruik de secties in dit artikel om de implementatievereisten te identificeren en de vereisten vóór installatie te valideren.

Planningsomvang

Container Apps op Azure Arc omvat Azure-resources, een bestaande Kubernetes-cluster en geïmplementeerde applicaties. Plan voor de volgende gebieden:

Ondersteunde topologie en versiematrix

Gebruik de nieuwste door de leverancier ondersteunde Kubernetes-patchrelease die ook door Azure Arc-enabled Kubernetes wordt ondersteund. De documentatie van Container Apps publiceert geen aparte Kubernetes-versiereeks voor elke distributie. Verifieer de exacte distributie en Kubernetes-versie met Microsoft-ondersteuning voordat je een productie-installatie of upgrade uitvoert.

De volgende matrix registreert de momenteel gepubliceerde distributieondersteuning. Valideer het opnieuw tegen beschikbare extensies voor Azure Arc-compatibele Kubernetes-clusters en Azure Container Apps op Azure Arc-beperkingen vóór elke installatie.

De extensie wordt niet ondersteund op Windows-nodes of Arm64-clusters. Het Arc-extensieframework vereist minstens één geschikte linux/amd64 node, maar een productie-implementatie vereist genoeg geschikte nodes voor de extensie, workloads, upgrades en storingen.

Slechts één ondersteunde KEDA-installatie kan op de cluster draaien. Bepaal of KEDA wordt geïnstalleerd door de Container Apps-extensie of al op het cluster bestaat. Als KEDA al bestaat, stop dan en bevestig de ondersteunde coëxistentieconfiguratie voordat je verder gaat. Verwijder de bestaande KEDA-installatie niet en pas geen ongedocumenteerde extensies toe, want andere workloads kunnen ervan afhankelijk zijn.

Capaciteitsvereisten

Plan capaciteit voor:

• De vaste en per knooppunt beschikbare onderdelen van de Container Apps-extensie die worden vermeld in Resources die zijn gemaakt door de Container Apps-extensie.
• Het maximale verwachte aantal replica’s voor elke container-app.
• Gelijktijdige taakuitvoeringen en pieken in herhalingspogingen.
• Dapr-zijspanen en toepassingszijspanen.
• systeemworkloads van Kubernetes en andere tenants in het cluster.
• Gefaseerde upgrades van nodes en extensies.
• Uitval van ten minste één knooppunt in een implementatie met hoge beschikbaarheid.

Het instellen van het maximale aantal replica's in een applicatie reserveert geen clustercapaciteit.

Minimale installatiecapaciteit

Er is geen universeel productieminimum omdat de plaatsing van extensies, ingeschakelde componenten, aantal node's, daemon-workloads, KEDA-installatie, Log Analytics, Dapr-gebruik en workloadverzoeken variëren. Gebruik de gepubliceerde uitbreidingscomponentverzoeken als basis en meet toewijzingbare, niet totaal, noderesources. Een evaluatieclustergrootte is geen aanbeveling voor productiegrootte.

Registreer vóór de installatie:

• Toewijzingsbare CPU en geheugen op geschikte linux/amd64 nodes.
• Aantal nodes en plaatsing in foutdomeinen.
• Beschikbare pod- en service-IP-capaciteit.
• Huidige systeem- en tenantverzoeken en limieten.
• Capaciteit niet beschikbaar vanwege taints, affiniteit, quota’s of verstoringsbudgetten.

Bereken de werkbelastingcapaciteit

Bereken voor elke toepassing:

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

Voeg maximale gelijktijdige taakcapaciteit, uitbreidingscapaciteit, systeemreserve, upgradepiekcapaciteit en storingsreserve toe. Zorg ervoor dat node-labels, taints, affiniteitsregels en resource fragmentatie de nominale vrije capaciteit niet onplanbaar maken.

Valideer het plan door representatieve workloads te plannen en door een node-drain te simuleren. Controleer of de extensiepods en de benodigde workloadreplica's gereed blijven.

Netwerkvereisten

Container Apps op Azure Arc vereist verschillende verschillende netwerkpaden:

Gebruik Azure Arc-enabled Kubernetes-netwerkvereisten als de canonieke eindpuntlijst. Kopieer de endpointlijst niet naar een firewallregelset zonder de juiste Azure Cloud te selecteren en Arc-functies aan te zetten. Test elke vereiste volledig gekwalificeerde domeinnaam (FQDN) uit het clusternetwerk. De Arc-vereisten stellen dat HTTPS-eindpunten officieel ondertekende en verifieerbare certificaten gebruiken. Bevestig het gedrag van proxy- en TLS-inspectie in een niet-productiecluster; niet-ondersteunde interceptie of een onbetrouwbaar vervangingscertificaat kan voorkomen dat agenten en extensiecomponenten verbinding maken.

De geselecteerde LoadBalancer implementatie bepaalt de adrespool, health probes, routering en vereiste capaciteit. Als een aangepaste load balancer een gereserveerd adres vereist, reserveer het adres dan eerst en geef het tijdens de installatie mee via de instelling loadBalancerIp van de extensie. Health-probepoorten en bronbereiken zijn implementatieafhankelijk; leid deze af uit de geselecteerde load balancer in plaats van uit te gaan van de standaardwaarden van Azure Load Balancer.

De onderliggende, Arc-enabled Kubernetes-cluster beheert netwerkbeperkingen voor de verbonden omgeving. Als een applicatieafhankelijkheid een privé-endpoint gebruikt, verifieer dan via een applicatiepod dat de cluster zijn DNS-naam kan oplossen en naar zijn privé-IP kan routeren. Applicaties die client-IP-informatie nodig hebben, moeten de forwardingheaders die door de geselecteerde load balancer en proxyketen worden geproduceerd valideren en definiëren welke proxies worden vertrouwd.

Netwerken valideren

1. Deploy een Kubernetes-testdienst LoadBalancer en bevestig dat deze een adres ontvangt dat bereikbaar is vanaf elk beoogd clientnetwerk.
2. Vanuit een geschikte clusternode of diagnostische pod, los op en verbind je met elke vereiste Azure Arc-endpoint- en workloadafhankelijkheid.
3. Bevestig dat de proxy het vereiste HTTPS- en WebSocket-verkeer toestaat en certificaten niet vervangt door een niet-vertrouwde uitgever.
4. Controleer of cluster-DNS, pod-naar-pod-verkeer, services, admissionwebhooks en statuscontroles van load balancers werken met het beoogde netwerkbeleid.
5. Na de installatie van de extensie moet u controleren of de ingress-service het beoogde IP-adres ontvangt en bereikbaar is voordat u productie-DNS-records aanmaakt.

DNS-vereisten

Na installatie van extensies deploy je een testapplicatie en haal je de gegenereerde FQDN op. Controleer of de FQDN de extensie-ingang van elk beoogd clientnetwerk oplost en bereikt. De naam van de verbonden omgeving maakt deel uit van het gegenereerde applicatiedomein, dus kies deze bewust.

Voor interne applicaties gebruik split-horizon DNS wanneer interne en externe clients verschillende antwoorden vereisen. Identificeer de gezaghebbende DNS-zone, registreer de tijd tot leven en herstelvereisten. Bepaal of applicaties het gegenereerde domein, aangepaste domeinen of beide gebruiken, en plan certificaatuitgifte en verlenging vóór de uitrol.

Valideer DNS en ingress van elk beoogd clientnetwerk:

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

De FQDN van de applicatie moet verwijzen naar het ingress-IP en de verwachte respons van de applicatie retourneren. Verwijder autorisatie-headers, cookies en gevoelige queryparameters voordat je gedetailleerde uitvoer deelt.

Identiteit, geheimen en registers

Beheerde identiteiten worden niet ondersteund voor container-apps op Azure Arc. Het ophalen van images uit Azure Container Registry met managed identity wordt ook niet ondersteund.

Voor toegang tot Azure-bronnen gebruik je een speciale applicatieregistratie en service principal alleen wanneer de doelservice dit ondersteunt. Wijs alleen de vereiste dataplane-rollen toe binnen het kleinst mogelijke bereik. Houd de tenant-ID en client ID gescheiden van het credential, gebruik een certificaat wanneer de applicatie en de target service dit ondersteunen, en plan de vervaldatum en rotatie van de credentials. Gebruik de Arc connected-cluster identiteit of cluster-beheerder identiteit niet opnieuw voor applicatietoegang.

Gebruik voor privé-registers registergebonden inloggegevens met alleen-pulltoegang als het register dit ondersteunt. Vermijd ACR-beheerdersgegevens voor productieworkloads. Sla register- en applicatiegegevens op als Container Apps geheimen en verwijs ze bij naam vanuit applicatieconfiguratie.

Geheimen van Container Apps gelden op toepassingsniveau en als u een geheim wijzigt, worden bestaande revisies niet automatisch bijgewerkt. Behandel zowel Azure-controlplane-toegang als privileged Kubernetes-toegang als beveiligingsgrenzen. Beperk de toegang tot de extensie en applicatienaamruimtes volgens de Kubernetes-beveiligingseisen voor de implementatie.

Gebruik deze rotatievolgorde:

1. Maak een tweede geldig inloggegevens aan bij de identiteitsprovider of het register.
2. Werk het Container Apps-geheim bij en deploy of herstart de getroffen versie indien nodig.
3. Controleer de afbeeldingsoptrekkingen en applicatieauthenticatie met het nieuwe inloggegevens.
4. Trek de oude legitimatie in.
5. Controleer dat er geen actieve revisie of taak nog verwijst naar de oude waarde.

Plaats nooit geheime waarden in commandogeschiedenis, broncode, diagnostische bundels, podbeschrijvingen of applicatielogs. Beperk wie extensie-beschermde instellingen en Kubernetes-geheimen kan lezen.

Storage

Plan de opslag afhankelijk van de persistentie die de werklast vereist:

De beperkingen van Container Apps on Arc documenteren momenteel Azure Files SMB en vereisen de SMB CSI-driver. Ga er niet van uit dat een volumetype dat wordt ondersteund door in Azure gehoste Container Apps, ook wordt ondersteund door Arc. Gebruik in plaats van hier nog een kopie bij te houden de SMB-installatieopdrachten waarnaar wordt gelinkt vanuit Azure Container Apps op Azure Arc.

Behandel opslagaccountgegevens die voor een mount worden gebruikt als geheimen. Beheerde identiteiten worden niet ondersteund voor Container Apps op Arc. Test de geselecteerde mountopties, bestandsrechten, gelijktijdige toegang, foutgedrag en credentialrotatie met exact de CSI-driver- en opslagserviceversies die in productie worden gebruikt.

Plan back-up van persistente gegevens, hersteltesten, bewaartermijnen en noodherstel. Test hoe revisies en jobs fouten bij het koppelen melden, en neem pod-events en CSI-driverlogs op in de diagnostische procedure. Linux is het enige ondersteunde node-besturingssysteem voor de extensie.

Planobserveerbaarheid

Log Analytics-integratie is optioneel. Als je het wilt gebruiken, configureer het dan bij het installeren van de extensie, want je kunt het later niet aan die extensie-instantie toevoegen.

Wanneer je Log Analytics configureert, kun je applicatielogs vinden in ContainerAppConsoleLogs_CL. De zelfstudie Een container-app maken in Azure Arc laat TimeGenerated, ContainerAppName_s en Log_s zien; controleer de live-tabel voordat je query’s of waarschuwingen opstelt. Reken 10 tot 15 minuten in bij het valideren van de eerste inname.

Plan de kosten voor toegang tot werkruimten, retentie, waarschuwingen, export en gegevensinname. Bekijk de applicatielogging op inloggegevens, persoonlijke gegevens en gevoelige URL's voordat je verzameling inschakelt.

Als je Log Analytics niet configureert, of tijdens een invoerincident, gebruik dan Kubernetes-logs:

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

Systeemcomponenten schrijven logs naar standaarduitvoer. Standaard wordt systeemcomponent-telemetrie naar Microsoft gestuurd, terwijl applicatielogs niet worden verzonden tenzij je Log Analytics configureert. Als u logProcessor.enabled=false instelt, worden logboeken niet meer verwerkt en niet meer doorgestuurd naar de werkruimte, en kan dit de hoeveelheid diagnostische gegevens vergroten die de ondersteuning u vraagt handmatig te verzamelen.

Test vóór productie een uniek applicatielogbericht van begin tot eind, maak waarschuwingen voor extensiegezondheid en applicatiefouten, en bevestig dat zowel Azure- als Kubernetes-diagnostiek toegankelijk zijn.

Upgrade, back-up en herstel

Selecteer en documenteer een releaseplanning voor extensies en een upgradebeleid. De Container Apps setup tutorial gebruikt de stable release-trein met automatische upgrades van kleinere versies. Azure Arc clusterextensies kunnen een release-reeks volgen met automatische upgrades of handmatig worden vastgezet en geüpgraden. Bekijk de release notes van de Container Apps-extensie voordat je van versie wisselt, en bied extra capaciteit, compatibele Kubernetes-versies, onderhoudsvensters en applicatievalidatie aan.

Voor een extensie of Kubernetes-upgrade:

1. Bevestig dat de inrichtingsstatus van het verbonden cluster en die van de extensie Succeeded zijn.
2. Bevestig dat de beoogde combinatie van Kubernetes en de extensie wordt ondersteund.
3. Bekijk release notes en huidige configuratie, waaronder release train, automatische upgrade-instelling, KEDA-installatie, namespaces, Log Analytics, enzovoortloadBalancerIp.
4. Controleer of er voldoende reservecapaciteit is voor gefaseerde vervanging en bevestig dat de disruptiebudgetten voortgang mogelijk maken.
5. Controleer de connectiviteit van het beeldregister en het toelatingsbeleid voor de doelbeelden.
6. Maak een back-up van de bronconfiguratie van de applicatie en alle persistente applicatiegegevens.
7. Voer applicatie-, ingress-, schaalbaarheids-, job-, opslag- en loggingsmoketests uit voor en na de wijziging.

Behandel de Kubernetes-namespace-back-up niet als een back-up van de Azure-resources. De verbonden cluster, extensie, aangepaste locatie, verbonden omgeving, container-apps en taken worden weergegeven in Azure Resource Manager en hebben afhankelijkheden van in-cluster resources. Maak aparte back-ups van declaratieve applicatieconfiguratie. Herstel niet handmatig implementaties, aangepaste resources of geheimen die door een extensie worden beheerd na de installatie van een nieuwe extensie, tenzij Microsoft-ondersteuning die herstelprocedure verstrekt.

Een extensie-downgrade of rollback is geen algemeen herstelmechanisme dat is gedocumenteerd voor Container Apps op Arc. Verander de release-lijn niet, pin geen oudere versie, en pas geen door extensies beheerde workloads aan als incidentrespons zonder een ondersteund pad met Microsoft-ondersteuning te bevestigen.

Ontwikkel en test een recovery runbook die rekening houdt met Kubernetes-infrastructuur, netwerken, DNS, load balancing, opslag, Azure Arc-agenten, de Container Apps-extensie, aangepaste locatie, verbonden omgeving, applicatieconfiguratie, inloggegevens en persistente applicatiegegevens. Valideer ingang, revisies, schaalverwerking, taken, opslag en logs na herstel. Gebruik herstelprocedures die worden ondersteund door de Kubernetes-topologie en back-upproducten in de deployment.

Plan voor Azure-disconnectie. Arc-agenten hebben connectiviteit nodig om extensiewijzigingen te ontdekken en de gewenste toestand te verspreiden. Beschermde instellingen voor een nieuw aangemaakte extensieresource worden tot 48 uur behouden; als de cluster gedurende die periode losgekoppeld blijft, kan de extensie van Pending naar Failedverplaatsen. Test het werklastgedrag tijdens het verlies van Azure-connectiviteit in plaats van een continuïteitsgarantie aan te nemen.

Verwante onderwerpen

• Azure Container Apps in Azure Arc
• Stel een Kubernetes-cluster op met Azure Arc om Azure Container Apps uit te voeren
• Een container-app maken in Azure Arc
• Problemen oplossen met Azure Container Apps op Azure Arc-ondersteunde Kubernetes
• Kubernetes-netwerkvereisten met Azure Arc
• Aangepaste locaties op Azure Arc-enabled Kubernetes
• Clusterextensies in Azure Arc-ingeschakelde Kubernetes