Planera en Container Apps-distribution på Azure Arc-aktiverade Kubernetes

Använd denna artikel innan du installerar Container Apps-tillägget på ett produktionskluster. Container Apps på Azure Arc använder kapacitet och plattformstjänster som tillhandahålls av ditt Kubernetes-kluster. Beslut om noder, lastbalansering, DNS, utgående anslutning, lagring, identitet, loggning och uppgraderingar påverkar applikationens tillgänglighet.

Använd avsnitten i denna artikel för att identifiera utrullningskrav och validera förutsättningar innan installation.

Planeringens omfattning

Container Apps på Azure Arc täcker Azure-resurser, ett befintligt Kubernetes-kluster och distribuerade applikationer. Planera för följande områden:

Stödd topologi och versionsmatris

Använd den senaste leverantörsstödda Kubernetes-patchen som även Azure Arc-aktiverade Kubernetes stödjer. Container Apps-dokumentationen publicerar inte ett separat Kubernetes-versionsintervall för varje distribution. Verifiera exakt distribution och Kubernetes-version med Microsoft-stöd innan en produktionsinstallation eller uppgradering.

Följande matris registrerar det för närvarande publicerade distributionsstödet. Validera den igen mot tillgängliga tillägg för Azure Arc-aktiverade Kubernetes-kluster och Azure Container Apps på Azure Arc-begränsningar före varje installation.

Tillägget stöds inte på Windows-noder eller Arm64-kluster. Arc-tilläggsramverket kräver minst en lämplig linux/amd64-nod, men en produktionsdistribution kräver tillräckligt många lämpliga noder för tillägget, arbetsbelastningar, uppgraderingar och felhantering.

Endast en stödd KEDA-installation kan köras på klustret. Avgör om KEDA kommer att installeras av Container Apps-tillägget eller redan finns på klustret. Om KEDA redan existerar, stoppa och bekräfta den stödda samexistenskonfigurationen innan du fortsätter. Ta inte bort den befintliga KEDA-installationen eller applicera odokumenterade tilläggsinställningar eftersom andra arbetsbelastningar kan vara beroende av det.

Kapacitetskrav

Planera kapacitet för:

• De fasta komponenterna och komponenterna per nod för tillägget Container Apps anges i Resurser som skapas av tillägget Container Apps.
• Det högsta förväntade antalet repliker för varje containerapp.
• Samtidiga jobbutföranden och omprovningsburstar.
• Dapr-sidovagnar och applikationssidovagnar.
• Kubernetes-systemarbetslaster och andra klusterinnehavare.
• Stegvisa nod- och tilläggsuppgraderingar.
• Fel på minst en nod i en distribution med hög tillgänglighet.

Att sätta ett programs maximala antal repliker reserverar inte klusterkapaciteten.

Minsta installationskapacitet

Det finns inget universellt produktionsminimum eftersom placering av tillägg, aktiverade komponenter, antal noder, daemon-arbetsbelastningar, KEDA-installation, Log Analytics, användning av Dapr och arbetsbelastningsförfrågningar varierar. Använd de publicerade tilläggskomponentförfrågningarna som baslinje och mät allokerbara, inte totala, nodresurser. Storleken på ett utvärderingskluster är inte en storleksrekommendation för produktion.

Före installationen, notera:

• Allokerbar CPU och minne på berättigade linux/amd64 noder.
• Nodräkning och placering av feldomän.
• Ledig pod- och service-IP-kapacitet.
• Nuvarande system och hyresgästförfrågningar och begränsningar.
• Kapacitet otillgänglig på grund av föroreningar, affinitet, kvoter eller störningsbudgetar.

Uppskatta arbetsbelastningskapacitet

För varje applikation, beräkna:

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

Lägg till maximal samtidiga jobbkapacitet, förlängningskapacitet, systemreserv, uppgraderingsöverbelastning och felreserv. Se till att nodetiketter, taints, affinitetsregler och resursfragmentering inte gör att kapacitet som nominellt är ledig inte kan schemaläggas.

Verifiera planen genom att schemalägga representativa arbetsbelastningar och simulera dränering av en nod. Kontrollera att tilläggspoddar och de nödvändiga replikerna för arbetsbelastningen fortsätter att vara redo.

Nätverkskrav

Container Apps på Azure Arc kräver flera distinkta nätverksvägar:

Använd nätverkskrav för Azure Arc-aktiverad Kubernetes som den huvudsakliga slutpunktslistan. Kopiera inte slutpunktslistan till en brandväggsregeluppsättning utan att välja rätt Azure-moln och aktiverade Arc-funktioner. Testa varje nödvändigt fullt kvalificerat domännamn (FQDN) från klusternätverket. Arc-kraven anger att HTTPS-endpoints använder officiellt signerade och verifierbara certifikat. Kontrollera hur proxyn och TLS-inspektionen fungerar i ett icke-produktionskluster; interceptering som inte stöds eller ett ersättningscertifikat som inte är betrott kan förhindra att agenter och tilläggskomponenter ansluter.

Den valda LoadBalancer implementationen bestämmer adresspoolen, hälsoprober, routing och nödvändig kapacitet. Om en anpassad lastbalanserare kräver en reserverad adress, reservera adressen först och skicka den genom tilläggsinställningen loadBalancerIp under installationen. Hälsoprobeportar och källintervall är implementationsspecifika; hämta dem från den lastbalanserare du har valt i stället för att utgå från Azure Load Balancers standardvärden.

Det underliggande Arc-aktiverade Kubernetes-klustret styr nätverksbegränsningar för den anslutna miljön. Om ett applikationsberoende använder en privat endpoint, kontrollera från en applikationspodd att klustret kan lösa dess DNS-namn och dirigera trafiken till dess privata IP-adress. Applikationer som behöver klient-IP-information bör validera vidarebefordringshuvuden som produceras av den valda lastbalanseraren och proxykedjan och definiera vilka proxyer som är betrodda.

Verifiera nätverk

1. Distribuera en Kubernetes-testtjänst LoadBalancer och bekräfta att den får en adress som kan nås från varje avsett klientnätverk.
2. Från en kvalificerad klusternod eller diagnostikpod, lös och anslut till varje nödvändig Azure Arc-endpoint och arbetsbelastningsberoende.
3. Bekräfta att proxyn tillåter nödvändig HTTPS- och WebSocket-trafik och inte ersätter certifikat med en icke betrodd utfärdare.
4. Verifiera att kluster-DNS, pod-till-pod-trafik, tjänster, admission-webhooks och hälsokontroller för lastbalanserare fungerar med de avsedda nätverkspolicyerna.
5. Efter installation av tillägget, bekräfta att ingresstjänsten får den planerade IP-adressen och är nåbar innan produktions-DNS-poster skapas.

DNS-krav

Efter installation av tillägg, distribuera en testapplikation och hämta dess genererade FQDN. Verifiera att FQDN löser och når tilläggsingången från varje avsett klientnätverk. Namnet på den sammankopplade miljön ingår i den genererade applikationsdomänen, så välj det medvetet.

För interna applikationer, använd split-horizon DNS när interna och externa klienter kräver olika svar. Identifiera den auktoritativa DNS-zonen, inspelningstid till live och återställningskrav. Bestäm om applikationer använder den genererade domänen, anpassade domäner eller båda, och planera utfärdande och förnyelse av certifikat innan driftsättning.

Validera DNS och ingång från varje avsett klientnätverk:

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

Applikationens FQDN måste resolvas till ingångs-IP:n och returnera det förväntade applikationssvaret. Ta bort auktorisationsheaders, cookies och känsliga frågesträngar innan du delar utförligt utdata.

Identitet, hemligheter och register

Managed IDENTITIES stöds inte för containerappar på Azure Arc. Att hämta bilder från Azure Container Registry genom att använda managed identity stöds inte heller.

För åtkomst till Azure-resurser, använd en dedikerad applikationsregistrering och tjänsteprincip endast när måltjänsten stöder det. Tilldela endast de roller för dataplanet som krävs, inom den snävaste praktiskt möjliga omfattningen. Håll tenant-ID och klient-ID åtskilda från autentiseringsuppgifterna, använd ett certifikat när applikationen och måltjänst stöder det, och planera för utgång och rotation av autentiseringsuppgifter. Återanvänd inte Arc-anslutningsklusteridentiteten eller en klusteradministratörsidentitet för applikationsåtkomst.

För privata register använder du en autentiseringsuppgift som är begränsad till registret och som endast har hämtningsåtkomst, om registret har stöd för det. Undvik administratörsuppgifter för ACR för produktionsarbetslaster. Spara register- och applikationsuppgifter som Container Apps-hemligheter och referera till dem med namn från applikationskonfigurationen.

Container Apps hemligheter är applikationsbegränsade, och att ändra en hemlighet uppdaterar inte automatiskt befintliga versioner. Behandla både Azure-kontrollplansåtkomst och privilegierad Kubernetes-åtkomst som säkerhetsgränser. Begränsa åtkomsten till tilläggs- och applikationsnamnrymder enligt Kubernetes-säkerhetskraven för distributionen.

Använd denna rotationssekvens:

1. Skapa en andra giltig legitimation hos identitetsleverantören eller registret.
2. Uppdatera Container Apps hemlighet och distribuera eller starta om den berörda versionen vid behov.
3. Verifiera bildutdrag och applikationsautentisering med den nya inloggningsbehörigheten.
4. Återkalla den gamla inloggningsuppgiften.
5. Bekräfta att ingen aktiv revision eller jobb fortfarande refererar till det gamla värdet.

Placera aldrig hemliga värden i kommandohistorik, versionshantering, diagnostikpaket, pod-beskrivningar eller applikationsloggar. Begränsa vem som kan läsa tilläggsskyddade inställningar och Kubernetes-hemligheter.

Storage

Planera lagring enligt den persistens som krävs av arbetsbelastningen:

Begränsningarna för Container Apps on Arc dokumenterar för närvarande Azure Files SMB och kräver SMB CSI-drivrutinen. Anta inte att en volymtyp som stöds av Azure-hostade Container Apps stöds på Arc. Använd SMB-installationskommandona som länkas från Azure Container Apps i Azure Arc istället för att behålla en annan kopia här.

Behandla lagringskontouppgifter som används för en mount som hemligheter. Hanterade identiteter stöds inte för Container Apps på Arc. Testa de valda monteringsalternativen, filbehörigheter, samtidig åtkomst, felbeteende och legitimationsrotation med exakt CSI-drivrutin och lagringsversioner som används i produktion.

Planera säkerhetskopiering av persistenta data, återställningstestning, lagring och katastrofåterställning. Testa hur revisioner och jobb rapporterar monteringsfel, och inkludera pod-händelser och CSI-drivrutinsloggar i diagnosproceduren. Linux är det enda stödda nod-operativsystemet för tillägget.

Planobservabilitet

Log Analytics-integration är valfritt. Om du planerar att använda det, konfigurera det när du installerar tillägget eftersom du inte kan lägga till det i den tilläggsinstansen senare.

När du konfigurerar Log Analytics kan du hitta applikationsloggar i ContainerAppConsoleLogs_CL. Självstudiekursen Skapa en containerapp på Azure Arc visar TimeGenerated, ContainerAppName_s och Log_s; granska realtidstabellen innan du skapar frågor eller aviseringar. Avsätt 10 till 15 minuter för validering av den inledande inmatningen.

Planera åtkomst till arbetsytan, lagring, aviseringar, export och kostnad för datainmatning. Granska applikationsloggningen för inloggningsuppgifter, personuppgifter och känsliga URL:er innan du aktiverar insamling.

Om du inte konfigurerar Log Analytics, eller under en inmatningsincident, använd Kubernetes-loggar:

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

Systemkomponenter skriver loggar till standardutdata. Som standard skickas systemkomponenttelemetri till Microsoft medan applikationsloggar inte skickas om du inte konfigurerar Log Analytics. Om du anger logProcessor.enabled=false inaktiveras loggbearbetning och vidarebefordran av loggar till arbetsytan, och det kan öka det diagnostiska underlag som supporten ber dig samla in manuellt.

Innan produktion, testa ett unikt applikationsloggmeddelande från början till slut, skapa varningar för tilläggshälsa och applikationsfel, och bekräfta att både Azure- och Kubernetes-diagnostik är tillgängliga.

Uppgradering, backup och återhämtning

Välj och dokumentera en utgivningstakt för tillägg och en uppgraderingspolicy. Installationshandledningen för Container Apps använder stable release train med automatiska uppgraderingar till nya delversioner. Azure Arc-klustertillägg kan följa en utgivningstakt med automatiska uppgraderingar eller fästas till en viss version och uppgraderas manuellt. Granska versionsanteckningar för Container Apps-tillägg innan du byter version, och tillhandahåll extra kapacitet, kompatibla Kubernetes-versioner, underhållsfönster och applikationsvalidering.

Innan en tilläggs- eller Kubernetes-uppgradering:

1. Bekräfta att provisioneringstillståndet för det anslutna klustret och tilläggen är Succeeded.
2. Kontrollera att den avsedda kombinationen av Kubernetes och tillägget stöds.
3. Gå igenom versionsanteckningar och nuvarande konfiguration, inklusive release train, automatisk uppgradering, KEDA-installation, namnrymder, Log Analytics och loadBalancerIp.
4. Verifiera ledig kapacitet för rullande ersättning och kontrollera att störningsbudgetar tillåter framsteg.
5. Verifiera bildregisteranslutning och intagningspolicyer för målbilderna.
6. Säkerhetskopiera källkonfigurationen för applikationen och alla beständiga programdata.
7. Kör röktester för applikation, ingång, skalning, jobb, lagring och loggning före och efter ändringen.

Behandla inte en säkerhetskopia av Kubernetes-namnrymden som en säkerhetskopia av Azure-resurser. Det anslutna klustret, tillägget, den anpassade platsen, den anslutna miljön, containerappar och jobb representeras i Azure Resource Manager och har beroenden av resurser i klustret. Säkerhetskopiera deklarativ applikationskonfiguration separat. Återställ inte manuellt tilläggshanterade distributioner, anpassade resurser eller hemligheter ovanpå ett nyligen installerat tillägg, om inte Microsoft Support tillhandahåller den återställningsprocessen.

En nedgradering eller återställning till en tidigare version av ett tillägg är inte en allmän återställningsmekanism som är dokumenterad för Container Apps på Arc. Ändra inte releasekanalen, lås inte till en äldre version och ändra inte arbetsbelastningar som hanteras av tillägget som en incidentåtgärd utan att först ha bekräftat med Microsoft Support att det finns en lösning som stöds.

Utveckla och testa en recovery-runbook som tar hänsyn till Kubernetes-infrastruktur, nätverk, DNS, lastbalansering, lagring, Azure Arc-agenter, Container Apps-tillägget, anpassad plats, ansluten miljö, applikationskonfiguration, inloggningsuppgifter och persistenta applikationsdata. Verifiera ingress, revisioner, skalning, jobb, lagring och loggar efter återställning. Använd återställningsprocedurer som stöds av Kubernetes-topologin och säkerhetskopieringsprodukterna i driftsättningen.

Planera för Azure-frånkoppling. Arc-agenter måste ha anslutning för att upptäcka ändringar i tillägg och tillämpa önskat tillstånd. Skyddade inställningar för en nyskapad tilläggsresurs behålls i upp till 48 timmar; om klustret förblir frånkopplat under den perioden kan tillägget flyttas från Pending till Failed. Testa arbetsbelastningsbeteende vid förlust av Azure-anslutning istället för att anta en garanti för kontinuitet.

Relaterat innehåll

• Azure Container Apps i Azure Arc
• Sätt upp ett Azure Arc-aktiverat Kubernetes-kluster för att köra Azure Container Apps
• Skapa en containerapp i Azure Arc
• Felsöka Azure Container Apps i Azure Arc-aktiverad Kubernetes
• Azure Arc-aktiverade Kubernetes-nätverkskrav
• Anpassade platser på Azure Arc-aktiverade Kubernetes-kluster
• Klustertillägg i Azure Arc-enabled Kubernetes