Share via

Veelgestelde vragen - Kubernetes en GitOps met Azure Arc

  • Artikel

In dit artikel vindt u veelgestelde vragen over Kubernetes en GitOps met Azure Arc.

Wat is het verschil tussen Kubernetes met Azure Arc en Azure Kubernetes Service (AKS)?

AKS is de beheerde Kubernetes-aanbieding van Azure. AKS vereenvoudigt het implementeren van een beheerd Kubernetes-cluster in Azure door veel van de complexiteit en operationele overhead naar Azure te offloaden. Omdat de Kubernetes-masters worden beheerd door Azure, beheert en onderhoudt u alleen de agentknooppunten.

Met Kubernetes met Azure Arc kunt u de beheermogelijkheden van Azure (zoals Azure Monitor en Azure Policy) uitbreiden door Kubernetes-clusters te verbinden met Azure. U onderhoudt het onderliggende Kubernetes-cluster zelf.

Moet ik mijn AKS-clusters die worden uitgevoerd in Azure verbinden met Azure Arc?

Op dit moment is het verbinden van een AKS-cluster (Azure Kubernetes Service) met Azure Arc niet vereist voor de meeste scenario's. Mogelijk wilt u een cluster verbinden om bepaalde Services met Azure Arc uit te voeren, zoals App Services en Data Services boven op het cluster. Dit kan worden gedaan met behulp van de functie voor aangepaste locaties van Kubernetes met Azure Arc.

Moet ik mijn AKS-HCI-cluster en Kubernetes-clusters in Azure Stack Edge verbinden met Azure Arc?

Verbinding maken uw AKS-HCI-cluster of Kubernetes-clusters in Azure Stack Edge naar Azure Arc biedt clusters met resourceweergave in Azure Resource Manager. Deze resourceweergave breidt mogelijkheden uit, zoals clusterconfiguratie, Azure Monitor en Azure Policy (Gatekeeper) met verbonden Kubernetes-clusters.

Als het Kubernetes-cluster met Azure Arc zich in Azure Stack Edge bevindt, AKS op Azure Stack HCI (>= update van april 2021) of AKS in Windows Server 2019 Datacenter (>= update van april 2021), wordt de Kubernetes-configuratie gratis opgenomen.

Hoe kan ik adres verlopen Kubernetes-resources met Azure Arc?

De door het systeem toegewezen beheerde identiteit die is gekoppeld aan uw Kubernetes-cluster met Azure Arc, wordt alleen gebruikt door de Azure Arc-agents om te communiceren met de Azure Arc-services. Het certificaat dat is gekoppeld aan deze door het systeem toegewezen beheerde identiteit, heeft een verloopperiode van 90 dagen en de agents proberen dit certificaat tussen dag 46 en dag 90 te vernieuwen. Om te voorkomen dat uw beheerde identiteitscertificaat verloopt, moet u ervoor zorgen dat het cluster minstens één keer online is tussen dag 46 en dag 90, zodat het certificaat kan worden vernieuwd.

Als het certificaat voor beheerde identiteit verloopt, wordt de resource overwogen Expired en werken alle Azure Arc-functies (zoals configuratie, bewaking en beleid) niet meer in het cluster.

Voer de volgende opdracht uit om te controleren wanneer het beheerde identiteitscertificaat verloopt voor een bepaald cluster:

az connectedk8s show -n <name> -g <resource-group>

In de uitvoer geeft de waarde van het managedIdentityCertificateExpirationTime certificaat aan wanneer het beheerde identiteitscertificaat verloopt (90D-markering voor dat certificaat).

Als de waarde van managedIdentityCertificateExpirationTime een tijdstempel uit het verleden aangeeft, wordt het connectivityStatus veld in de bovenstaande uitvoer ingesteld op Expired. In dergelijke gevallen werkt uw Kubernetes-cluster opnieuw met Azure Arc:

  1. Verwijder de Kubernetes-resource en -agents met Azure Arc in het cluster.

    az connectedk8s delete -n <name> -g <resource-group>

  2. Maak de Kubernetes-resource met Azure Arc opnieuw door agents in het cluster te implementeren.

    az connectedk8s connect -n <name> -g <resource-group>

Notitie

az connectedk8s delete verwijdert ook configuraties en clusterextensies boven op het cluster. Maak na het uitvoeren az connectedk8s connectde configuraties en clusterextensies in het cluster opnieuw, handmatig of met behulp van Azure Policy.

Als ik al CI/CD-pijplijnen gebruik, kan ik nog steeds Kubernetes of AKS- en GitOps-configuraties met Azure Arc gebruiken?

Ja, u kunt nog steeds configuraties gebruiken op een cluster dat implementaties ontvangt via een CI/CD-pijplijn. In vergelijking met traditionele CI/CD-pijplijnen bieden GitOps-configuraties enkele extra voordelen.

Driftafstemming

De CI/CD-pijplijn past wijzigingen slechts eenmaal toe tijdens de pijplijnuitvoering. De GitOps-operator in het cluster controleert echter continu de Git-opslagplaats om de gewenste status van Kubernetes-resources op het cluster op te halen. Als de GitOps-operator de gewenste status van resources vindt die verschilt van de werkelijke status van resources in het cluster, wordt deze drift afgestemd.

GitOps op schaal toepassen

CI/CD-pijplijnen zijn handig voor gebeurtenisgestuurde implementaties in uw Kubernetes-cluster (bijvoorbeeld een push naar een Git-opslagplaats). Als u echter dezelfde configuratie wilt implementeren voor al uw Kubernetes-clusters, moet u de referenties van elk Kubernetes-cluster handmatig configureren voor de CI/CD-pijplijn.

Voor Kubernetes met Azure Arc, omdat Azure Resource Manager uw GitOps-configuraties beheert, kunt u het maken van dezelfde configuratie automatiseren voor alle Kubernetes- en AKS-resources met Azure Arc met behulp van Azure Policy, binnen het bereik van een abonnement of een resourcegroep. Deze mogelijkheid is zelfs van toepassing op Kubernetes- en AKS-resources met Azure Arc die zijn gemaakt na de beleidstoewijzing.

Met deze functie worden basislijnconfiguraties (zoals netwerkbeleid, rolbindingen en podbeveiligingsbeleid) toegepast in de gehele Kubernetes-clusterinventaris om te voldoen aan nalevings- en governancevereisten.

Clustercompatibiliteit

De nalevingsstatus van elke GitOps-configuratie wordt teruggegeven aan Azure. Hiermee kunt u eventuele mislukte implementaties bijhouden.

Worden in Kubernetes met Azure Arc klantgegevens opgeslagen buiten de regio van het cluster?

De functie voor het inschakelen van het opslaan van klantgegevens in één regio is momenteel alleen beschikbaar in de regio Azië - zuidoost (Singapore) van de regio Azië en Stille Oceaan en Brazilië - zuid (São Paulo) regio van Brazilië Geo. Voor alle andere regio's worden klantgegevens opgeslagen in Geo. Dit is van toepassing op Open Service Mesh- en Azure Key Vault Secrets Provider-extensies die worden ondersteund in Kubernetes met Azure Arc. Zie de documentatie voor andere clusterextensies voor meer informatie over het opslaan van klantgegevens. Zie Trust Center voor meer informatie.

Volgende stappen