Aracılığıyla paylaş

AKS kümelerindeki ağ sorunlarını giderme

  • Makale

Kubernetes'in yeni yüklemelerinde veya Kubernetes yükünü artırdığınızda ağ sorunları oluşabilir. Ağ sorunlarıyla ilgili diğer sorunlar da oluşabilir. Sorununuzun burada açıklanıp açıklanmadığını görmek için aks sorun giderme kılavuzunu her zaman denetleyin. Bu makalede ağ sorun giderme perspektifinden ek ayrıntılar ve dikkat edilmesi gerekenler ve ortaya çıkabilecek belirli sorunlar açıklanmaktadır.

İstemci API sunucusuna erişemiyor

Bu hatalar, Bir Azure Kubernetes Service (AKS) kümesinin API sunucusuna Kubernetes kümesi komut satırı aracı (kubectl) veya bir programlama dili aracılığıyla REST API gibi başka bir araç üzerinden ulaşamamanıza neden olan bağlantı sorunlarını içerir.

Hata

Aşağıdakine benzer hatalar görebilirsiniz:

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.

Neden 1

API sunucusu tarafından yetkilendirilen IP aralıkları kümenin API sunucusunda etkinleştirilebilir, ancak istemcinin IP adresi bu IP aralıklarına dahil değildir. IP aralıklarının etkinleştirilip etkinleştirilmediğini belirlemek için Azure CLI'da aşağıdaki az aks show komutu kullanın. IP aralıkları etkinleştirilirse, komut bir IP aralıkları listesi oluşturur.

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

Çözüm 1

İstemcinizin IP adresinin kümenin API sunucusu tarafından yetkilendirilmiş aralıklar içinde olduğundan emin olun:

  1. Yerel IP adresinizi bulun. Windows ve Linux'ta bulma hakkında bilgi için bkz . IP'mi bulma.

  2. Azure CLI'da komutunu kullanarak API sunucusu tarafından yetkilendirilmiş aralığı güncelleştirin az aks update . İstemcinizin IP adresini yetkilendirilin. Yönergeler için bkz . Kümenin API sunucusu yetkili IP aralıklarını güncelleştirme.

Neden 2

AKS kümeniz özel bir kümeyse, API sunucusu uç noktasının genel IP adresi yoktur. AKS kümesinin sanal ağına ağ erişimi olan bir VM kullanmanız gerekir.

Çözüm 2

Bu sorunun nasıl çözüleceğini öğrenmek için bkz . Özel kümeye bağlanma seçenekleri.

Pod IP adresini ayıramıyor

Hata

Pod durumunda takılıyor ContainerCreating ve olayları bir Failed to allocate address hata bildirmektedir:

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

Veya bir not enough IPs available hata:

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

Eklenti IPAM deposunda ayrılmış IP adreslerini denetleyin. Tüm IP adreslerinin ayrıldığını, ancak sayının çalışan Pod sayısından çok daha az olduğunu fark edebilirsiniz:

kubenet kullanıyorsanız:

# 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

Not

Calico içermeyen kubenet için yolu şeklindedir /var/lib/cni/networks/kubenet. Calico ile kubenet için yolu şeklindedir /var/lib/cni/networks/k8s-pod-network. Yukarıdaki betik, komutu yürütürken yolu otomatik olarak seçer.

# 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

Dinamik IP ayırma için Azure CNI kullanılıyorsa:

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

Neden 1

Bu hatanın nedeni ağ eklentisindeki bir hata olabilir. Eklenti, pod sonlandırıldığında IP adresini serbest bırakamaz.

Çözüm 1

Geçici bir çözüm veya düzeltme için Microsoft'a başvurun.

Neden 2

Pod oluşturma işlemi, sonlandırılan Podların çöp toplama işleminden çok daha hızlıdır.

Çözüm 2

Kubelet için hızlı çöp toplamayı yapılandırın. Yönergeler için Kubernetes çöp toplama belgelerine bakın.

Hizmete Podlar içinde erişilemiyor

Bu sorunu çözmenin ilk adımı, hizmet için uç noktaların otomatik olarak oluşturulup oluşturulmadığını denetlemektir:

kubectl get endpoints <service-name>

Boş bir sonuç alırsanız hizmetinizin etiket seçicisi yanlış olabilir. Etiketin doğru olduğunu onaylayın:

# 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

Yukarıdaki adımlar beklenen değerleri döndürmezse:

  • Pod'un containerPort hizmetiyle containerPortaynı olup olmadığını denetleyin.

  • Çalışıp çalışmadığını podIP:containerPort denetleyin:

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

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

Hizmet sorunlarının diğer olası nedenleri şunlardır:

  • Kapsayıcı belirtilen containerPortöğesini dinlemiyor. (Pod açıklamasını denetleyin.)
  • CNI eklentisi hatası veya ağ yolu hatası oluşuyor.
  • kube-proxy çalışmıyor veya iptables kuralları doğru yapılandırılmamış.
  • Ağ İlkeleri trafiği bırakıyor. Ağ İlkelerini uygulama ve test etme hakkında bilgi için bkz . Azure Kubernetes Ağ İlkelerine genel bakış.
    • Ağ eklentiniz olarak Calico kullanıyorsanız, ağ ilkesi trafiğini de yakalayabilirsiniz. Bunu yapılandırma hakkında bilgi için bkz . Calico sitesi.

Düğümler API sunucusuna erişemiyor

Birçok eklenti ve kapsayıcının Kubernetes API'sine (örneğin, kube-dns ve operatör kapsayıcıları) erişmesi gerekir. Bu işlem sırasında hatalar oluşursa, aşağıdaki adımlar sorunun kaynağını belirlemenize yardımcı olabilir.

İlk olarak, Kubernetes API'sinin Podlar içinde erişilebilir olup olmadığını onaylayın:

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

Ardından, şu anda kabuğuna alındığınız kapsayıcının içinden aşağıdakileri yürütebilirsiniz.

# 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

İyi durumdaki çıkış aşağıdakine benzer olacaktır.

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

Bir hata oluşursa hizmetin ve uç noktalarının kubernetes-internal iyi durumda olup olmadığını denetleyin:

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

Her iki test de öncekiler gibi yanıtlar döndürürse ve döndürülen IP ve bağlantı noktası kapsayıcınızınkilerle eşleşiyorsa, kube-apiserver çalışmıyor veya ağdan engellenmiş olabilir.

Erişimin engellenmesinin dört ana nedeni vardır:

Kapsayıcı içgörülerini kullanarak kube-apiserver günlüklerini de de de kontrol edebilirsiniz. kube-apiserver günlüklerini ve diğer birçok sorguyu sorgulama hakkında bilgi için bkz . Kapsayıcı içgörülerinden günlükleri sorgulama.

Son olarak kube-apiserver durumunu ve kümedeki günlüklerini de kontrol edebilirsiniz:

# 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

Hata 403 - Forbidden döndürürse kube-apiserver büyük olasılıkla rol tabanlı erişim denetimi (RBAC) ile yapılandırılır ve kapsayıcınızın ServiceAccount kaynaklara erişme yetkisi büyük olasılıkla yoktur. Bu durumda, uygun RoleBinding ve ClusterRoleBinding nesneleri oluşturmanız gerekir. Roller ve rol bağlamaları hakkında bilgi için bkz . Erişim ve kimlik. Kümenizde RBAC yapılandırma örnekleri için bkz . RBAC Yetkilendirmesini Kullanma.

Katkıda Bulunanlar

Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.

Asıl yazar:

Diğer katkıda bulunanlar:

Sonraki adımlar