Hálózati problémák elhárítása az AKS-fürtökben

  • Cikk

A Kubernetes új telepítéseinél vagy a Kubernetes-terhelés növelésekor hálózati problémák léphetnek fel. A hálózatkezelési problémákhoz kapcsolódó egyéb problémák is előfordulhatnak. Mindig tekintse meg az AKS hibaelhárítási útmutatóját, és ellenőrizze, hogy a probléma ott van-e ismertetve. Ez a cikk további részleteket és szempontokat ismertet a hálózati hibaelhárítás szempontjából, valamint az esetlegesen felmerülő konkrét problémákat.

Az ügyfél nem tudja elérni az API-kiszolgálót

Ezek a hibák olyan csatlakozási problémákat okoznak, amelyek akkor fordulnak elő, ha egy Azure Kubernetes Service- (AKS-) fürt API-kiszolgálóját nem éri el a Kubernetes-fürt parancssori eszközén (kubectl) vagy bármely más eszközön keresztül, például a REST API-t egy programozási nyelven keresztül.

Hiba

Az alábbihoz hasonló hibaüzenetek jelenhetnek meg:

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.

1. ok

Lehetséges, hogy az API-kiszolgáló által engedélyezett IP-tartományok engedélyezve vannak a fürt API-kiszolgálóján, de az ügyfél IP-címe nem szerepel ezekben az IP-tartományokban. Annak megállapításához, hogy az IP-tartományok engedélyezve vannak-e, használja az alábbi az aks show parancsot az Azure CLI-ben. Ha az IP-tartományok engedélyezve vannak, a parancs létrehozza az IP-tartományok listáját.

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

1\. megoldás

Győződjön meg arról, hogy az ügyfél IP-címe a fürt API-kiszolgálója által engedélyezett tartományokon belül van:

  1. Keresse meg a helyi IP-címét. A windowsos és a linuxos keresésről a Hogyan találom meg az IP-címemet? című témakörben talál további információt.

  2. Frissítse az API-kiszolgáló által engedélyezett tartományt az az aks update Azure CLI parancsával. Engedélyezze az ügyfél IP-címét. Útmutatásért tekintse meg a fürt API-kiszolgálójának engedélyezett IP-tartományainak frissítését.

Ok 2

Ha az AKS-fürt privát fürt, az API-kiszolgáló végpontja nem rendelkezik nyilvános IP-címmel. Olyan virtuális gépet kell használnia, amely hálózati hozzáféréssel rendelkezik az AKS-fürt virtuális hálózatához.

2\. megoldás

A probléma megoldásáról további információt a privát fürthöz való csatlakozás lehetőségeiben talál.

A pod nem tudja lefoglalni az IP-címet

Hiba

A pod elakadt az ContainerCreating állapotban, és az események hibát jeleznek Failed to allocate address :

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

Vagy hiba not enough IPs available :

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'}]

Ellenőrizze a lefoglalt IP-címeket a beépülő modul IPAM-tárolójában. Előfordulhat, hogy az összes IP-cím le van foglalva, de a szám sokkal kisebb, mint a futó podok száma:

Kubenet használata esetén:

# 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

Feljegyzés

A Calico nélküli Kubenet esetében az elérési út ./var/lib/cni/networks/kubenet A Calico kubenet esetében az elérési út./var/lib/cni/networks/k8s-pod-network A fenti szkript automatikusan kijelöli az elérési utat a parancs végrehajtása közben.

# 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

Ha az Azure CNI-t használja dinamikus IP-foglaláshoz:

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

1. ok

Ezt a hibát a hálózati beépülő modul hibája okozhatja. A beépülő modul nem tudja felszabadítani az IP-címet a pod leállásakor.

1\. megoldás

Kerülő megoldásért vagy javításért forduljon a Microsofthoz.

Ok 2

A pod létrehozása sokkal gyorsabb, mint a leállított podok szemétgyűjtése.

2\. megoldás

Konfigurálja a kubelet gyors szemétgyűjtését. Útmutatásért tekintse meg a Kubernetes szemétgyűjtési dokumentációját.

A szolgáltatás nem érhető el podokon belül

A probléma megoldásának első lépése annak ellenőrzése, hogy a végpontok automatikusan lettek-e létrehozva a szolgáltatáshoz:

kubectl get endpoints <service-name>

Ha üres eredményt kap, előfordulhat, hogy a szolgáltatás címkeválasztója hibás. Ellenőrizze, hogy a címke helyes-e:

# 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

Ha az előző lépések a várt értékeket adják vissza:

  • Ellenőrizze, hogy a pod containerPort megegyezik-e a szolgáltatással containerPort.

  • Ellenőrizze, hogy működik-e podIP:containerPort :

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

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

A szolgáltatásproblémák további lehetséges okai:

  • A tároló nem figyeli a megadott containerPortértéket. (Ellenőrizze a pod leírását.)
  • CNI beépülő modulhiba vagy hálózati útvonalhiba történik.
  • A kube-proxy nem fut, vagy az iptables-szabályok nincsenek megfelelően konfigurálva.
  • A hálózati házirendek forgalomleadást bonyolítanak. A hálózati szabályzatok alkalmazásával és tesztelésével kapcsolatos információkért tekintse meg az Azure Kubernetes hálózati szabályzatainak áttekintését.
    • Ha a Calico-t használja hálózati beépülő modulként, akkor a hálózati házirendek forgalmát is rögzítheti. Ennek konfigurálásáról további információt a Calico webhelyén talál.

A csomópontok nem érik el az API-kiszolgálót

Számos bővítménynek és tárolónak hozzá kell férnie a Kubernetes API-hoz (például kube-dns- és operátortárolókhoz). Ha a folyamat során hibák lépnek fel, az alábbi lépések segíthetnek meghatározni a probléma forrását.

Először ellenőrizze, hogy a Kubernetes API elérhető-e a Podokon belül:

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

Ezután hajtsa végre a következőt a most rendszerhéjba helyezett tárolóból.

# 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

Az kifogástalan kimenet az alábbihoz hasonlóan fog kinézni.

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

Ha hiba történik, ellenőrizze, hogy a szolgáltatás és végpontjai kubernetes-internal kifogástalan állapotban vannak-e:

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

Ha mindkét teszt az előzőekhez hasonló válaszokat ad vissza, és a visszaadott IP-cím és port megegyezik a tárolóéval, akkor valószínű, hogy a kube-apiserver nem fut vagy le van tiltva a hálózatról.

A hozzáférés blokkolásának négy fő oka lehet:

  • A hálózati házirendek. Előfordulhat, hogy megakadályozzák az API felügyeleti síkhoz való hozzáférést. A hálózati házirendek teszteléséről további információt a Hálózati házirendek áttekintése című témakörben talál.
  • Az API engedélyezett IP-címei. A probléma megoldásáról további információt a fürt API-kiszolgálójának engedélyezett IP-tartományainak frissítése című témakörben talál.
  • A privát tűzfal. Ha privát tűzfalon keresztül irányítja át az AKS-forgalmat, győződjön meg arról, hogy vannak kimenő szabályok az AKS-fürtök kötelező kimenő hálózati szabályaiban és teljes tartományneveiben leírtak szerint.
  • A privát DNS-ét. Ha privát fürtöt üzemeltet, és nem tudja elérni az API-kiszolgálót, előfordulhat, hogy a DNS-továbbítók nincsenek megfelelően konfigurálva. A megfelelő kommunikáció biztosítása érdekében végezze el a hubon a lépéseket, és egyéni DNS-sel küllős legyen.

A Kube-apiserver naplóit a Container Insights használatával is ellenőrizheti. A kube-apiserver-naplók és sok más lekérdezés lekérdezésével kapcsolatos információkért lásd : Naplók lekérdezése a Container Insightsból.

Végül ellenőrizheti a kube-apiserver állapotát és naplóit a fürtön:

# 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

Ha egy 403 - Forbidden hiba visszatér, a kube-apiserver valószínűleg szerepköralapú hozzáférés-vezérléssel (RBAC) van konfigurálva, és a tároló ServiceAccount valószínűleg nem jogosult az erőforrások elérésére. Ebben az esetben megfelelő RoleBinding és ClusterRoleBinding objektumokat kell létrehoznia. A szerepkörökről és a szerepkörkötésekről az Access és az identitás című témakörben olvashat bővebben. Az RBAC fürtre való konfigurálására vonatkozó példákért lásd az RBAC-hitelesítés használatát ismertető témakört.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

Egyéb közreműködők:

Következő lépések