Netwerkproblemen in AKS-clusters oplossen

  • Artikel

Netwerkproblemen kunnen optreden in nieuwe installaties van Kubernetes of wanneer u de Kubernetes-belasting verhoogt. Andere problemen die betrekking hebben op netwerkproblemen kunnen ook optreden. Controleer altijd de AKS-gids voor probleemoplossing om te zien of uw probleem daar wordt beschreven. In dit artikel worden aanvullende details en overwegingen beschreven vanuit het perspectief van het oplossen van netwerkproblemen en specifieke problemen die zich kunnen voordoen.

Client kan de API-server niet bereiken

Deze fouten hebben betrekking op verbindingsproblemen die optreden wanneer u de API-server van een AKS-cluster (Azure Kubernetes Service) niet kunt bereiken via het opdrachtregelprogramma kubernetes-cluster (kubectl) of een ander hulpprogramma, zoals de REST API via een programmeertaal.

Fout

Mogelijk ziet u fouten die er als volgt uitzien:

Unable to connect to the server: dial tcp <API-server-IP>:443: i/o timeout 

Unable to connect to the server: dial tcp <API-server-IP>:443: connectex: A connection attempt
failed because the connected party did not properly respond after a period, or established 
connection failed because connected host has failed to respond.

Oorzaak 1

Het is mogelijk dat IP-bereiken die door de API-server zijn geautoriseerd, zijn ingeschakeld op de API-server van het cluster, maar het IP-adres van de client is niet opgenomen in deze IP-bereiken. Gebruik de volgende az aks show opdracht in Azure CLI om te bepalen of IP-bereiken zijn ingeschakeld. Als de IP-bereiken zijn ingeschakeld, produceert de opdracht een lijst met IP-bereiken.

az aks show --resource-group <cluster-resource-group> \ 
    --name <cluster-name> \ 
    --query apiServerAccessProfile.authorizedIpRanges

Oplossing 1

Zorg ervoor dat het IP-adres van uw client binnen de bereiken valt die zijn geautoriseerd door de API-server van het cluster:

  1. Zoek uw lokale IP-adres. Zie Mijn IP-adres vinden voor meer informatie over hoe u het kunt vinden in Windows en Linux.

  2. Werk het bereik bij dat is geautoriseerd door de API-server met behulp van de az aks update opdracht in Azure CLI. Autoriseren van het IP-adres van uw client. Zie De geautoriseerde IP-bereiken van een clusterserver bijwerken voor instructies.

Oorzaak 2

Als uw AKS-cluster een privécluster is, heeft het EINDPUNT van de API-server geen openbaar IP-adres. U moet een virtuele machine gebruiken die netwerktoegang heeft tot het virtuele netwerk van het AKS-cluster.

Oplossing 2

Zie de opties voor het maken van verbinding met een privécluster voor meer informatie over het oplossen van dit probleem.

Pod kan het IP-adres niet toewijzen

Fout

De pod is vastgelopen in de ContainerCreating status en de gebeurtenissen melden een Failed to allocate address fout:

Normal   SandboxChanged          5m (x74 over 8m)    kubelet, k8s-agentpool-00011101-0 Pod sandbox
changed, it will be killed and re-created. 

  Warning  FailedCreatePodSandBox  21s (x204 over 8m)  kubelet, k8s-agentpool-00011101-0 Failed 
create pod sandbox: rpc error: code = Unknown desc = NetworkPlugin cni failed to set up pod 
"deployment-azuredisk6-874857994-487td_default" network: Failed to allocate address: Failed to 
delegate: Failed to allocate address: No available addresses

Of een not enough IPs available fout:

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox 
'ac1b1354613465324654c1588ac64f1a756aa32f14732246ac4132133ba21364': plugin type='azure-vnet' 
failed (add): IPAM Invoker Add failed with error: Failed to get IP address from CNS with error: 
%w: AllocateIPConfig failed: not enough IPs available for 9c6a7f37-dd43-4f7c-a01f-1ff41653609c, 
waiting on Azure CNS to allocate more with NC Status: , IP config request is [IPConfigRequest: 
DesiredIPAddress , PodInterfaceID a1876957-eth0, InfraContainerID 
a1231464635654a123646565456cc146841c1313546a515432161a45a5316541, OrchestratorContext 
{'PodName':'a_podname','PodNamespace':'my_namespace'}]

Controleer de toegewezen IP-adressen in het IPAM-archief van de invoegtoepassing. Mogelijk vindt u dat alle IP-adressen zijn toegewezen, maar het aantal is veel kleiner dan het aantal actieve pods:

Als u kubenet gebruikt:

# Kubenet, for example. The actual path of the IPAM store file depends on network plugin implementation. 
chroot /host/
ls -la "/var/lib/cni/networks/$(ls /var/lib/cni/networks/ | grep -e "k8s-pod-network" -e "kubenet")" | grep -v -e "lock\|last\|total" -e '\.$' | wc -l
244

Notitie

Voor kubenet zonder Calico is /var/lib/cni/networks/kubenethet pad . Voor kubenet met Calico is /var/lib/cni/networks/k8s-pod-networkhet pad . Het bovenstaande script selecteert automatisch het pad tijdens het uitvoeren van de opdracht.

# Check running Pod IPs
kubectl get pods --field-selector spec.nodeName=<your_node_name>,status.phase=Running -A -o json | jq -r '.items[] | select(.spec.hostNetwork != 'true').status.podIP' | wc -l
7

Als u Azure CNI gebruikt voor dynamische IP-toewijzing:

kubectl get nnc -n kube-system -o wide

NAME                               REQUESTED IPS  ALLOCATED IPS  SUBNET  SUBNET CIDR   NC ID                                 NC MODE  NC TYPE  NC VERSION
aks-agentpool-12345678-vmss000000  32             32             subnet  10.18.0.0/15  559e239d-f744-4f84-bbe0-c7c6fd12ec17  dynamic  vnet     1

# Check running Pod IPs
kubectl get pods --field-selector spec.nodeName=aks-agentpool-12345678-vmss000000,status.phase=Running -A -o json | jq -r '.items[] | select(.spec.hostNetwork != 'true').status.podIP' | wc -l
21

Oorzaak 1

Deze fout kan worden veroorzaakt door een fout in de netwerkinvoegtoepassing. De invoegtoepassing kan de toewijzing van het IP-adres niet ongedaan maken wanneer een pod wordt beëindigd.

Oplossing 1

Neem contact op met Microsoft voor een tijdelijke oplossing of oplossing.

Oorzaak 2

Het maken van pods is veel sneller dan garbagecollection van beëindigde pods.

Oplossing 2

Configureer snelle garbagecollection voor de kubelet. Zie de documentatie voor de Garbagecollection van Kubernetes voor instructies.

Service is niet toegankelijk binnen Pods

De eerste stap voor het oplossen van dit probleem is om te controleren of eindpunten automatisch zijn gemaakt voor de service:

kubectl get endpoints <service-name>

Als u een leeg resultaat krijgt, is de labelkiezer van uw service mogelijk onjuist. Controleer of het label juist is:

# Query Service LabelSelector. 
kubectl get svc <service-name> -o jsonpath='{.spec.selector}' 

# Get Pods matching the LabelSelector and check whether they're running. 
kubectl get pods -l key1=value1,key2=value2

Als de voorgaande stappen verwachte waarden retourneren:

  • Controleer of de pod containerPort hetzelfde is als de service containerPort.

  • Controleer of podIP:containerPort het werkt:

    # Testing via cURL. 
curl -v telnet ://<Pod-IP>:<containerPort>

# Testing via Telnet. 
telnet <Pod-IP>:<containerPort>

Dit zijn enkele andere mogelijke oorzaken van serviceproblemen:

Knooppunten kunnen de API-server niet bereiken

Veel invoegtoepassingen en containers moeten toegang hebben tot de Kubernetes-API (bijvoorbeeld kube-dns en operatorcontainers). Als er fouten optreden tijdens dit proces, kunt u met de volgende stappen de oorzaak van het probleem bepalen.

Controleer eerst of de Kubernetes-API toegankelijk is binnen Pods:

kubectl run curl --image=mcr.microsoft.com/azure-cli -i -t --restart=Never --overrides='[{"op":"add","path":"/spec/containers/0/resources","value":{"limits":{"cpu":"200m","memory":"128Mi"}}}]' --override-type json --command -- sh

Voer vervolgens het volgende uit vanuit de container waarnaar u nu bent geshelld.

# If you don't see a command prompt, try selecting Enter. 
KUBE_TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) 
curl -sSk -H "Authorization: Bearer $KUBE_TOKEN" https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT/api/v1/namespaces/default/pods

De uitvoer in orde ziet er ongeveer als volgt uit.

{ 
  "kind": "PodList", 
  "apiVersion": "v1", 
  "metadata": { 
    "selfLink": "/api/v1/namespaces/default/pods", 
    "resourceVersion": "2285" 
  }, 
  "items": [ 
   ... 
  ] 
}

Als er een fout optreedt, controleert u of de kubernetes-internal service en de eindpunten in orde zijn:

kubectl get service kubernetes-internal

NAME                TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE 
kubernetes-internal ClusterIP   10.96.0.1    <none>        443/TCP   25m 

kubectl get endpoints kubernetes-internal

NAME                ENDPOINTS          AGE 
kubernetes-internal 172.17.0.62:6443   25m

Als beide tests antwoorden retourneren zoals de voorgaande en het IP-adres en de poort die zijn geretourneerd, overeenkomen met de antwoorden voor uw container, is het waarschijnlijk dat kube-apiserver niet wordt uitgevoerd of wordt geblokkeerd voor het netwerk.

Er zijn vier belangrijke redenen waarom de toegang mogelijk wordt geblokkeerd:

U kunt ook kube-apiserverlogboeken controleren met behulp van Container Insights. Zie Logboeken opvragen uit Container Insights voor meer informatie over het uitvoeren van query's op kube-apiserver-logboeken en vele andere query's.

Ten slotte kunt u de status van de kube-apiserver en de bijbehorende logboeken in het cluster zelf controleren:

# Check kube-apiserver status. 
kubectl -n kube-system get pod -l component=kube-apiserver 

# Get kube-apiserver logs. 
PODNAME=$(kubectl -n kube-system get pod -l component=kube-apiserver -o jsonpath='{.items[0].metadata.name}')
kubectl -n kube-system logs $PODNAME --tail 100

Als er een 403 - Forbidden fout wordt geretourneerd, is kube-apiserver waarschijnlijk geconfigureerd met op rollen gebaseerd toegangsbeheer (RBAC) en is uw container ServiceAccount waarschijnlijk niet gemachtigd voor toegang tot resources. In dit geval moet u de juiste RoleBinding objecten maken.ClusterRoleBinding Zie Access en identiteit voor informatie over rollen en rolbindingen. Zie RBAC-autorisatie gebruiken voor voorbeelden van het configureren van RBAC in uw cluster.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

Andere Inzenders:

Volgende stappen