Fehler beim Pullen von Images aus der Azure Container Registry im Azure Kubernetes Service-Cluster
Notiz
Waren diese Informationen hilfreich? Wir schätzen Ihr Feedback. Bitte verwenden Sie die Schaltfläche Feedback auf dieser Seite, um uns mitzuteilen, wie gut Ihnen dieser Artikel gefallen hat oder wie wir ihn verbessern können.
Wenn Sie microsoft Azure Container Registry zusammen mit Azure Kubernetes Service (AKS) verwenden, muss ein Authentifizierungsmechanismus eingerichtet werden. Sie können die AKS to Container Registry-Integration mithilfe einiger einfacher Azure CLI- oder Azure PowerShell-Befehle einrichten. Diese Integration weist die AcrPull-Rolle für die Kubelet-Identität zu, die dem AKS-Cluster zugeordnet ist, um Bilder aus einer Containerregistrierung abzurufen.
In einigen Fällen schlägt das Abrufen von Images aus einer Containerregistrierung in einen AKS-Cluster fehl. Dieser Artikel enthält Anleitungen zur Problembehandlung der am häufigsten auftretenden Fehler, wenn Sie Bilder aus einer Containerregistrierung in einen AKS-Cluster abrufen.
Voraussetzungen
In diesem Artikel wird davon ausgegangen, dass Sie über einen vorhandenen AKS-Cluster und eine vorhandene Containerregistrierung verfügen. Sehen Sie sich die folgenden Schnellstarts an:
Wenn Sie einen AKS-Cluster benötigen, stellen Sie einen mithilfe der Azure CLI oder der Azure-Portal bereit.
Wenn Sie eine Azure Container Registry (ACR) benötigen, erstellen Sie eine mithilfe der Azure CLI oder des Azure-Portal.
Außerdem benötigen Sie Azure CLI Version 2.0.59 oder eine höhere Version, um installiert und konfiguriert zu werden. Führen Sie az-Version aus, um die Version zu bestimmen. Wenn Sie Azure CLI installieren oder aktualisieren müssen, lesen Sie "Installieren von Azure CLI".
Symptome und erste Problembehandlung
Der Kubernetes-Pod ist "ImagePullBackOff" oder "ErrImagePull". Um detaillierte Fehlerinformationen zu erhalten, führen Sie den folgenden Befehl aus, und überprüfen Sie Ereignisse aus der Ausgabe.
kubectl describe pod <podname> -n <namespace>
Es wird empfohlen, mit der Problembehandlung zu beginnen, indem Sie die Integrität der Containerregistrierung überprüfen und überprüfen, ob auf die Containerregistrierung über den AKS-Cluster zugegriffen werden kann.
Führen Sie den folgenden Befehl aus, um die Integrität der Containerregistrierung zu überprüfen:
az acr check-health --name <myregistry> --ignore-errors --yes
Bei Erkennen eines Problems werden ein Fehlercode und eine Beschreibung bereitgestellt. Weitere Informationen zu den Fehlern und möglichen Lösungen finden Sie in der Fehlerreferenz zur Integritätsprüfung.
Notiz
Wenn Sie Helm-bezogene oder notarbezogene Fehler erhalten, bedeutet dies nicht, dass sich ein Problem auf die Containerregistrierung oder AKS auswirkt. Es gibt nur an, dass Helm oder Notar nicht installiert ist oder dass Azure CLI nicht mit der aktuellen installierten Version von Helm oder Notar kompatibel ist usw.
Führen Sie den folgenden Az aks Check-acr-Befehl aus, um zu überprüfen, ob auf die Containerregistrierung über den AKS-Cluster zugegriffen werden kann:
az aks check-acr --resource-group <MyResourceGroup> --name <MyManagedCluster> --acr <myacr>.azurecr.io
In den folgenden Abschnitten können Sie die häufigsten Fehler beheben, die in Ereignissen in der Ausgabe des kubectl describe pod Befehls angezeigt werden.
Ursache 1: 401 Nicht autorisierter Fehler
Ein AKS-Cluster erfordert eine Identität. Dabei kann es sich um eine verwaltete Identität oder einen Dienstprinzipal handeln. Wenn der AKS-Cluster eine verwaltete Identität verwendet, wird die Kubelet-Identität für die Authentifizierung mit ACR verwendet. Wenn der AKS-Cluster als Identität eines Dienstprinzipals verwendet wird, wird der Dienstprinzipal selbst für die Authentifizierung mit ACR verwendet. Unabhängig davon, was die Identität ist, ist die richtige Autorisierung, die zum Abrufen eines Images aus einer Containerregistrierung verwendet wird, erforderlich. Andernfalls wird möglicherweise der folgende Fehler "401 Nicht autorisiert" angezeigt:
Fehler beim Abrufen des Bilds "<acrname.azurecr.io/>< repository:tag>": [rpc error: code = Unknown desc = failed to pull and unpack image "<acrname.azurecr.io/>< repository:tag>": failed to resolve reference "<acrname.azurecr.io/<> repository:tag>": failed to authorize: failed to fetch oauth token: unexpected status: 401 Unauthorized
Mehrere Lösungen können Ihnen bei der Behebung dieses Fehlers helfen, vorbehaltlich der folgenden Einschränkungen:
Lösungen 2, 3 und 5 gelten nur für AKS-Cluster, die einen Dienstprinzipal verwenden.
Lösungen 1, 2, 3 und 4 gelten für die Azure-Methode zum Erstellen der Rollenzuweisung auf Containerregistrierungsebene für die Identität von AKS.
Lösungen 5 und 6 gelten für die Kubernetes-Methode zum Ziehen eines Kubernetes-Geheimnis.
Lösung 1: Sicherstellen, dass die AcrPull-Rollenzuweisung für identitätserstellen erstellt wird
Die Integration zwischen AKS und Containerregistrierung erstellt eine AcrPull-Rollenzuweisung auf Containerregistrierungsebene für die Kubelet-Identität des AKS-Clusters. Stellen Sie sicher, dass die Rollenzuweisung erstellt wird.
Verwenden Sie eine der folgenden Methoden, um zu überprüfen, ob die AcrPull-Rollenzuweisung erstellt wird:
Führen Sie den folgenden Befehl aus:
az role assignment list --scope /subscriptions/<subscriptionID>/resourceGroups/<resourcegroupname>/providers/Microsoft.ContainerRegistry/registries/<acrname> -o tableÜberprüfen Sie die Azure-Portal, indem Sie Azure Container Registry>Access Control (IAM)>-Rollenzuweisungen auswählen. Weitere Informationen finden Sie unter Auflisten von Azure-Rollenzuweisungen mithilfe des Azure-Portal.
Neben der AcrPull-Rolle können einige integrierte Rollen und benutzerdefinierte Rollen auch die Aktion "Microsoft.ContainerRegistry/registries/pull/read" enthalten. Überprüfen Sie diese Rollen, wenn Sie eine dieser Rollen haben.
Wenn die AcrPull-Rollenzuweisung nicht erstellt wird, erstellen Sie sie, indem Sie die Containerregistrierungsintegration für den AKS-Cluster mit dem folgenden Befehl konfigurieren:
az aks update -n <myAKSCluster> -g <myResourceGroup> --attach-acr <acr-resource-id>
Lösung 2: Sicherstellen, dass der Dienstprinzipal nicht abgelaufen ist
Stellen Sie sicher, dass der geheime Schlüssel des Dienstprinzipals, der dem AKS-Cluster zugeordnet ist, nicht abgelaufen ist. Führen Sie die folgenden Befehle aus, um das Ablaufdatum Ihres Dienstprinzipals zu überprüfen:
SP_ID=$(az aks show --resource-group <myResourceGroup> --name <myAKSCluster> \
--query servicePrincipalProfile.clientId -o tsv)
az ad app credential list --id "SP_ID" --query "[].endDateTime" --output tsv
Weitere Informationen finden Sie unter Überprüfen des Ablaufdatums Ihres Dienstprinzipals.
Wenn der geheime Schlüssel abgelaufen ist, aktualisieren Sie die Anmeldeinformationen für den AKS-Cluster.
Lösung 3: Stellen Sie sicher, dass die AcrPull-Rolle dem richtigen Dienstprinzipal zugewiesen ist.
In einigen Fällen bezieht sich die Rollenzuweisung der Containerregistrierung weiterhin auf den alten Dienstprinzipal. Beispiel: Wenn der Dienstprinzipal des AKS-Clusters durch einen neuen ersetzt wird. Führen Sie die folgenden Schritte aus, um sicherzustellen, dass die Rollenzuweisung der Containerregistrierung auf den richtigen Dienstprinzipal verweist:
Führen Sie den folgenden Befehl aus, um den Dienstprinzipal zu überprüfen, der vom AKS-Cluster verwendet wird:
az aks show --resource-group <myResourceGroup> \ --name <myAKSCluster> \ --query servicePrincipalProfile.clientId \ --output tsvFühren Sie den folgenden Befehl aus, um den Dienstprinzipal zu überprüfen, auf den die Containerregistrierungsrolle verweist:
az role assignment list --scope /subscriptions/<subscriptionID>/resourceGroups/<resourcegroupname>/providers/Microsoft.ContainerRegistry/registries/<acrname> -o tableVergleichen Sie die beiden Dienstprinzipale. Wenn sie nicht übereinstimmen, integrieren Sie den AKS-Cluster erneut in die Containerregistrierung.
Lösung 4: Stellen Sie sicher, dass auf die Kubelet-Identität in der AKS VMSS verwiesen wird.
Wenn eine verwaltete Identität für die Authentifizierung mit dem ACR verwendet wird, wird die verwaltete Identität als Kubelet-Identität bezeichnet. Standardmäßig wird die Kubelet-Identität auf der AKS VMSS-Ebene zugewiesen. Wenn die Kubelet-Identität aus der AKS VMSS entfernt wird, können die AKS-Knoten keine Bilder aus dem ACR abrufen.
Führen Sie den folgenden Befehl aus, um die Kubelet-Identität Ihres AKS-Clusters zu finden:
az aks show --resource-group <MyResourceGroup> --name <MyManagedCluster> --query identityProfile.kubeletidentity
Anschließend können Sie die Identitäten der AKS VMSS auflisten, indem Sie vmSS aus der Knotenressourcengruppe öffnen und identitätsbenutzer auswählen>, der im Azure-Portal zugewiesen ist, oder indem Sie den folgenden Befehl ausführen:
az vmss identity show --resource-group <NodeResourceGroup> --name <AksVmssName>
Wenn die Kubelet-Identität Ihres AKS-Clusters nicht der AKS-VMSS zugewiesen ist, weisen Sie sie zurück.
Notiz
Das Ändern der AKS-VMSS mithilfe der IaaS-APIs oder des Azure-Portal wird nicht unterstützt, und kein AKS-Vorgang kann die Kubelet-Identität aus der AKS VMSS entfernen. Dies bedeutet, dass etwas Unerwartetes entfernt wurde, z. B. eine manuelle Entfernung, die von einem Teammitglied durchgeführt wird. Um eine solche Entfernung oder Änderung zu verhindern, können Sie die Verwendung des NRGLockdown-Features in Betracht ziehen.
Da Änderungen an den AKS-VMSS nicht unterstützt werden, werden sie nicht auf AKS-Ebene verteilt. Um die Kubelet-Identität der AKS VMSS neu zuzuweisen, ist ein Abstimmungsvorgang erforderlich. Führen Sie zu diesem Zweck den folgenden Befehl aus:
az aks update --resource-group <MyResourceGroup> --name <MyManagedCluster>
Lösung 5: Stellen Sie sicher, dass der Dienstprinzipal korrekt ist und der geheime Schlüssel gültig ist.
Wenn Sie ein Bild mithilfe eines Pullschlüssels abrufen und der geheime Kubernetes-Schlüssel mithilfe der Werte eines Dienstprinzipals erstellt wurde, stellen Sie sicher, dass der zugeordnete Dienstprinzipal korrekt ist und der geheime Schlüssel weiterhin gültig ist. Führen Sie folgende Schritte aus:
Führen Sie den folgenden Kubectl-Befehl und den base64-Befehl aus, um die Werte des Geheimen Kubernetes anzuzeigen:
kubectl get secret <secret-name> --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decodeÜberprüfen Sie das Ablaufdatum, indem Sie den folgenden Az ad sp-Listenbefehl für Anmeldeinformationen ausführen. Der Benutzername ist der Dienstprinzipalwert.
az ad sp credential list --id "<username>" --query "[].endDate" --output tsvSetzen Sie bei Bedarf den geheimen Schlüssel dieses Dienstprinzipals zurück, indem Sie den folgenden Az ad sp-Befehl zum Zurücksetzen von Anmeldeinformationen ausführen:
az ad sp credential reset --name "$SP_ID" --query password --output tsvAktualisieren oder erneut erstellen Sie den Kubernetes-Geheimschlüssel entsprechend.
Lösung 6: Stellen Sie sicher, dass der geheime Kubernetes-Schlüssel die richtigen Werte des Administratorkontos der Containerregistrierung aufweist.
Wenn Sie ein Image mithilfe eines Pullschlüssels abrufen und der geheime Kubernetes-Schlüssel mithilfe von Werten des Administratorkontos der Containerregistrierung erstellt wurde, stellen Sie sicher, dass die Werte im Geheimen Kubernetes mit den Werten des Containerregistrierungsadministratorkontos identisch sind. Führen Sie folgende Schritte aus:
Führen Sie den folgenden Kubectl-Befehl und den base64-Befehl aus, um die Werte des Geheimen Kubernetes anzuzeigen:
kubectl get secret <secret-name> --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decodeSuchen Sie im Azure-Portal nach Containerregistrierungen, und wählen Sie sie aus.
Wählen Sie in der Liste der Containerregistrierungen Ihre Containerregistrierung aus.
Wählen Sie im Navigationsbereich für die Containerregistrierung Die Zugriffstasten aus.
Vergleichen Sie auf der Seite "Zugriffstasten " für die Containerregistrierung die Containerregistrierungswerte mit den Werten im Geheimen Kubernetes.
Wenn die Werte nicht übereinstimmen, aktualisieren oder erstellen Sie den geheimen Kubernetes-Schlüssel entsprechend neu.
Notiz
Wenn ein Vorgang zum Generieren eines Kennworts aufgetreten ist, wird ein Vorgang mit dem Namen "Anmeldeinformationen für die Containerregistrierung generieren" auf der Seite "Aktivitätsprotokoll" der Containerregistrierung angezeigt. Das Aktivitätsprotokoll hat einen Aufbewahrungszeitraum von 90 Tagen.
Ursache 2: Fehler "Bild nicht gefunden"
Fehler beim Abrufen des Bilds "<acrname.azurecr.io/>< repository:tag>": [rpc error: code = NotFound desc = failed to pull and unpack image "<acrname.azurecr.io/<> repository:tag>": failed to resolve reference "<acrname.azurecr.io/>< repository:tag>": <acrname.azurecr.io/>< repository:tag>: not found
Lösung: Stellen Sie sicher, dass der Bildname korrekt ist.
Wenn dieser Fehler angezeigt wird, vergewissern Sie sich, dass der Bildname vollständig korrekt ist. Überprüfen Sie den Registrierungsnamen, den Registrierungsanmeldungsserver, den Repositorynamen und das Tag. Ein häufiger Fehler ist, dass der Anmeldeserver anstelle von "azurecr.io" als "azureacr.io" angegeben wird.
Wenn der Imagename nicht vollständig korrekt ist, kann auch der Fehler "401 Nicht autorisiert" auftreten, da AKS immer anonymen Pull versucht, unabhängig davon, ob die Containerregistrierung anonymen Pullzugriff aktiviert hat.
Ursache 3: 403 Verbotener Fehler
Fehler beim Abrufen des Bilds "<acrname.azurecr.io/< repository:tag>": rpc error: code = Unknown desc = failed to pull and unpack image "<acrname.azurecr.io/<> repository:tag>": failed to resolve reference "<acrname.azurecr.io/><> repository:tag>": failed to authorize: failed to fetch anonymous token: unexpected status: 403 Forbidden
Lösung 1: Stellen Sie sicher, dass die AKS-Netzwerkverbindung in der Privates DNS Zone der Containerregistrierung festgelegt ist.
Wenn sich die Netzwerkschnittstelle des privaten Endpunkts der Containerregistrierung und der AKS-Cluster in verschiedenen virtuellen Netzwerken befinden, stellen Sie sicher, dass die virtuelle Netzwerkverbindung für das virtuelle Netzwerk des AKS-Clusters in der Privates DNS Zone der Containerregistrierung festgelegt ist. (Dieser Link heißt standardmäßig "privatelink.azurecr.io".) Wenn sich die virtuelle Netzwerkverbindung nicht in der Privates DNS Zone der Containerregistrierung befindet, fügen Sie sie mithilfe einer der folgenden Methoden hinzu:
Wählen Sie im Azure-Portal die private DNS-Zone "privatelink.azurecr.io" aus, wählen Sie im Bereich "Einstellungen" die Option "Virtuelle Netzwerkverbindungen>hinzufügen" und dann einen Namen und das virtuelle Netzwerk des AKS-Clusters aus. Wählen Sie OK aus.
Notiz
Es ist optional, das Feature "Automatische Registrierung aktivieren" auszuwählen.
Lösung 2: Hinzufügen der öffentlichen IP-Adresse des AKS-Lastenausgleichs zu zulässigem IP-Adressbereich der Containerregistrierung
Wenn der AKS-Cluster öffentlich eine Verbindung mit der Containerregistrierung herstellt (NICHT über einen privaten Link oder endpunkt), und der Zugriff auf das öffentliche Netzwerk der Containerregistrierung ist auf ausgewählte Netzwerke beschränkt, fügen Sie die öffentliche IP-Adresse von AKS Load Balancer dem zulässigen IP-Adressbereich der Containerregistrierung hinzu:
Stellen Sie sicher, dass der Zugriff auf das öffentliche Netzwerk auf ausgewählte Netzwerke beschränkt ist.
Navigieren Sie im Azure-Portal zur Containerregistrierung. Wählen Sie unter Einstellungen die Option Netzwerk aus. Auf der Registerkarte "Öffentlicher Zugriff" ist der Zugriff auf "Öffentliche Netzwerke" oder "Deaktiviert" festgelegt.
Rufen Sie die öffentliche IP-Adresse des AKS-Lastenausgleichs mithilfe einer der folgenden Methoden ab:
Navigieren Sie im Azure-Portal zum AKS-Cluster. Wählen Sie unter "Einstellungen" die Option "Eigenschaften" aus, wählen Sie einen der Skalierungsgruppen für virtuelle Computer in der Ressourcengruppe der Infrastruktur aus, und überprüfen Sie die öffentliche IP-Adresse des AKS-Lastenausgleichs.
Führen Sie den folgenden Befehl aus:
az network public-ip show --resource-group <infrastructure-resource-group> --name <public-IP-name> --query ipAddress -o tsv
Zugriff über die öffentliche IP-Adresse des AKS-Lastenausgleichs zulassen, indem Sie eine der folgenden Möglichkeiten verwenden:
Führen Sie den Befehl wie folgt aus
az acr network-rule add:az acr network-rule add --name acrname --ip-address <AKS-load-balancer-public-IP-address>Weitere Informationen finden Sie unter Hinzufügen einer Netzwerkregel zur Registrierung.
Navigieren Sie im Azure-Portal zur Containerregistrierung. Wählen Sie unter Einstellungen die Option Netzwerk aus. Fügen Sie auf der Registerkarte "Öffentlicher Zugriff" unter "Firewall" die öffentliche IP-Adresse des AKS-Lastenausgleichs zum Adressbereich hinzu, und wählen Sie dann "Speichern" aus. Weitere Informationen finden Sie unter Access über ausgewähltes öffentliches Netzwerk – Portal.
Notiz
Wenn der Zugriff auf öffentliche Netzwerke auf "Deaktiviert" festgelegt ist, wechseln Sie zuerst zu ausgewählten Netzwerken .
Ursache 4: "I/o-Timeoutfehler"
Fehler beim Abrufen des Bilds "<acrname.azurecr.io/>< repository:tag>": rpc error: code = Unknown desc = failed to pull and unpack image "<acrname.azurecr.io/<> repository:tag>": Failed to resolve reference "<acrname>... azurecr.io/< repository:tag>": Anforderung fehlgeschlagen: Head "https://< acrname.azurecr.io/v2/<> repository>/manifests/v1": dial tcp <acrprivateipaddress>:443: i/o timeout
Notiz
Der Fehler "i/o timeout" tritt nur auf, wenn Sie eine private Verbindung mit einer Containerregistrierung mithilfe von Azure Private Link herstellen.
Lösung 1: Sicherstellen, dass virtuelle Netzwerk-Peering verwendet wird
Wenn sich die Netzwerkschnittstelle des privaten Endpunkts der Containerregistrierung und der AKS-Cluster in verschiedenen virtuellen Netzwerken befinden, stellen Sie sicher, dass virtuelle Netzwerk-Peering für beide virtuellen Netzwerke verwendet wird. Sie können virtuelle Netzwerk-Peering überprüfen, indem Sie den Azure CLI-Befehl az network vnet peering list --resource-group <MyResourceGroup> --vnet-name <MyVirtualNetwork> --output table oder im Azure-Portal ausführen, indem Sie im Bereich "Einstellungen" die VNETs-Peerings > auswählen. Weitere Informationen zum Auflisten aller Peerings eines angegebenen virtuellen Netzwerks finden Sie in der Az-Netzwerk-vnet-Peeringliste.
Wenn das virtuelle Netzwerk-Peering für beide virtuellen Netzwerke verwendet wird, stellen Sie sicher, dass der Status "Verbunden" ist. Wenn der Status "Getrennt" lautet, löschen Sie das Peering aus beiden virtuellen Netzwerken, und erstellen Sie ihn erneut. Wenn der Status "Verbunden" lautet, lesen Sie den Leitfaden zur Problembehandlung: Der Peeringstatus ist "Verbunden".
Für weitere Problembehandlung stellen Sie eine Verbindung mit einem der AKS-Knoten oder Pods her, und testen Sie dann die Verbindung mit der Containerregistrierung auf TCP-Ebene mithilfe des Hilfsprogramms Telnet oder Netcat. Überprüfen Sie die IP-Adresse mit dem nslookup <acrname>.azurecr.io Befehl, und führen Sie dann den telnet <ip-address-of-the-container-registry> 443 Befehl aus.
Weitere Informationen zum Herstellen einer Verbindung mit AKS-Knoten finden Sie unter Herstellen einer Verbindung mit SSH mit Azure Kubernetes Service (AKS)-Clusterknoten zur Wartung oder Problembehandlung.
Lösung 2: Verwenden des Azure Firewall Service
Wenn sich die Netzwerkschnittstelle des privaten Endpunkts der Containerregistrierung und der AKS-Cluster in verschiedenen virtuellen Netzwerken befinden, können Sie zusätzlich zu virtuellem Netzwerk-Peering azure Firewall Service verwenden, um eine Hub-Spoke-Netzwerktopologie in Azure einzurichten. Wenn Sie die Firewallregel einrichten, müssen Sie Netzwerkregeln verwenden, um die ausgehende Verbindung mit den IP-Adressen des privaten Endpunkts der Containerregistrierung explizit zuzulassen.
Ursache 5: Keine Übereinstimmung für die Plattform im Manifest
Das Hostbetriebssystem (Knotenbetriebssystem) ist nicht mit dem Image kompatibel, das für den Pod oder Container verwendet wird. Wenn Sie beispielsweise einen Pod für die Ausführung eines Linux-Containers auf einem Windows-Knoten oder einen Windows-Container auf einem Linux-Knoten planen, tritt der folgende Fehler auf:
Fehler beim Abrufen des Bilds "<acrname.azurecr.io/>< repository:tag>":
[
rpc-Fehler:
code = NotFound
desc = konnte das Bild "<acrname.azurecr.io/<> repository:tag>" nicht abrufen und entpacken: keine Übereinstimmung für die Plattform im Manifest: nicht gefunden,
]
Dieser Fehler kann für ein Bild auftreten, das von einer beliebigen Quelle abgerufen wird, solange das Image nicht mit dem Hostbetriebssystem kompatibel ist. Der Fehler ist nicht auf Images beschränkt, die aus der Containerregistrierung abgerufen werden.
Lösung: Konfigurieren des nodeSelector-Felds ordnungsgemäß in Ihrer Pod- oder Bereitstellung
Geben Sie das richtige nodeSelector Feld in den Konfigurationseinstellungen Ihres Pods oder Ihrer Bereitstellung an. Der richtige Wert für die Einstellung dieses Felds kubernetes.io/os stellt sicher, dass der Pod auf dem richtigen Knotentyp geplant wird. In der folgenden Tabelle wird gezeigt, wie Sie die kubernetes.io/os Einstellung in YAML festlegen:
| Containertyp | YAML-Einstellung |
|---|---|
| Linux-Container | "kubernetes.io/os": linux |
| Windows-Container | "kubernetes.io/os": windows |
Der folgende YAML-Code beschreibt beispielsweise einen Pod, der auf einem Linux-Knoten geplant werden muss:
apiVersion: v1
kind: Pod
metadata:
name: aspnetapp
labels:
app: aspnetapp
spec:
containers:
- image: "mcr.microsoft.com/dotnet/core/samples:aspnetapp"
name: aspnetapp-image
ports:
- containerPort: 80
protocol: TCP
nodeSelector:
"kubernetes.io/os": linux
Weitere Informationen
Wenn die Anleitung zur Problembehandlung in diesem Artikel Ihnen nicht hilft, das Problem zu beheben, sollten Sie folgendes berücksichtigen:
Überprüfen Sie die Netzwerksicherheitsgruppen und Routentabellen, die Subnetzen zugeordnet sind, wenn Sie über eines dieser Elemente verfügen.
Wenn eine virtuelle Appliance wie eine Firewall den Datenverkehr zwischen Subnetzen steuert, überprüfen Sie die Firewall- und Firewallzugriffsregeln.
Informationen zum Haftungsausschluss von Drittanbietern
Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.
Kontaktieren Sie uns für Hilfe
Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.