Поделиться через

Устранение неполадок сети в кластерах AKS

  • Статья

Проблемы с сетью могут возникать в новых установках Kubernetes или при увеличении нагрузки Kubernetes. Могут возникнуть и другие проблемы, связанные с сетевыми проблемами. Всегда проверка руководстве по устранению неполадок AKS, чтобы узнать, описана ли проблема. В этой статье описаны дополнительные сведения и рекомендации по устранению неполадок сети и конкретных проблем, которые могут возникнуть.

Клиент не может связаться с сервером API

Эти ошибки связаны с проблемами подключения, возникающими, когда вы не можете получить доступ к серверу API кластера Служба Azure Kubernetes (AKS) через средство командной строки кластера Kubernetes (kubectl) или любое другое средство, например REST API с помощью языка программирования.

Ошибка

Могут появиться ошибки, которые выглядят следующим образом:

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

Возможно, диапазоны IP-адресов, авторизованные сервером API, включены на сервере API кластера, но IP-адрес клиента не входит в эти диапазоны IP-адресов. Чтобы определить, включены ли диапазоны IP-адресов, используйте следующую az aks show команду в Azure CLI. Если диапазоны IP-адресов включены, команда создаст список диапазонов IP-адресов.

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

Решение 1

Убедитесь, что IP-адрес клиента находится в пределах диапазонов, авторизованных сервером API кластера:

  1. Найдите локальный IP-адрес. Сведения о том, как найти его в Windows и Linux, см. в статье "Как найти ip-адрес".

  2. Обновите диапазон, авторизованный сервером API, с помощью az aks update команды в Azure CLI. Авторизовать IP-адрес клиента. Инструкции см. в статье Об обновлении разрешенных диапазонов IP-адресов сервера API кластера.

Причина 2

Если кластер AKS является частным кластером, конечная точка сервера API не имеет общедоступного IP-адреса. Необходимо использовать виртуальную машину с сетевым доступом к виртуальной сети кластера AKS.

Решение 2

Сведения о том, как устранить эту проблему, см . в параметрах подключения к частному кластеру.

Не удается выделить IP-адрес pod

Ошибка

Модуль Pod застрял в ContainerCreating состоянии, и его события сообщают об ошибке 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

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

Проверьте выделенные IP-адреса в хранилище IPAM подключаемого модуля. Вы можете найти, что все IP-адреса выделены, но число гораздо меньше, чем количество запущенных модулей Pod:

При использовании kubenet:

# 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

Примечание.

Для kubenet без Calico путь имеет значение /var/lib/cni/networks/kubenet. Для kubenet с Calico путь имеет значение /var/lib/cni/networks/k8s-pod-network. Приведенный выше скрипт автоматически выбирает путь при выполнении команды.

# 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

При использовании Azure CNI для динамического распределения IP-адресов:

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

Эта ошибка может быть вызвана ошибкой в сетевом подключаемом модуле. Подключаемый модуль может не удалять IP-адрес при завершении модуля Pod.

Решение 1

Обратитесь к корпорации Майкрософт за решением или исправлением.

Причина 2

Создание pod гораздо быстрее, чем сборка мусора завершенных модулей Pod.

Решение 2

Настройте быструю сборку мусора для kubelet. Инструкции см . в документации по сборке мусора Kubernetes.

Служба недоступна в pod

Первым шагом решения этой проблемы является проверка, были ли автоматически созданы конечные точки для службы:

kubectl get endpoints <service-name>

Если вы получите пустой результат, селектор меток службы может оказаться неправильным. Убедитесь, что метка правильна:

# 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

Если предыдущие шаги возвращают ожидаемые значения:

  • Проверьте, совпадает ли модуль Pod containerPort со службой containerPort.

  • Проверьте, работает ли podIP:containerPort работа:

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

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

Это некоторые другие потенциальные причины проблем со службой:

  • Контейнер не прослушивает указанный containerPortобъект. (Проверьте описание pod.)
  • Возникает ошибка подключаемого модуля CNI или ошибка сетевого маршрута.
  • Kube-proxy не работает или правила iptables не настроены правильно.
  • Политики сети сбрасывают трафик. Сведения о применении и тестировании политик сети см. в обзоре политик сети Azure Kubernetes.
    • Если вы используете Calico в качестве сетевого подключаемого модуля, вы также можете записать трафик политики сети. Сведения о настройке см. на сайте Calico.

Узлы не могут связаться с сервером API

Многие надстройки и контейнеры должны получить доступ к API Kubernetes (например, контейнерам kube-dns и операторам). Если во время этого процесса возникают ошибки, вы можете определить источник проблемы.

Сначала проверьте, доступен ли API Kubernetes в pod:

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

Затем выполните следующую команду из контейнера, в который вы теперь оболочки.

# 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

Работоспособные выходные данные будут выглядеть следующим образом.

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

Если возникает ошибка, проверка ли kubernetes-internal служба и ее конечные точки работоспособны:

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

Если оба теста возвращают ответы, такие как предыдущие, и IP-адрес и порт, возвращенные для контейнера, вероятно, что kube-apiserver не запущен или заблокирован из сети.

Существует четыре основных причины, по которым может быть заблокирован доступ:

Вы также можете проверка журналы kube-apiserver с помощью аналитики контейнеров. Сведения о запросах журналов kube-apiserver и многих других запросах см. в статье "Как запрашивать журналы из аналитики контейнеров".

Наконец, вы можете проверка состояние kube-apiserver и его журналы в самом кластере:

# 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

403 - Forbidden Если ошибка возвращается, kube-apiserver, вероятно, настроен с помощью управления доступом на основе ролей (RBAC), и ваш контейнерServiceAccount, вероятно, не авторизован для доступа к ресурсам. В этом случае необходимо создать соответствующие RoleBinding объекты и ClusterRoleBinding объекты. Сведения о ролях и привязках ролей см. в разделе Access и identity. Примеры настройки RBAC в кластере см. в разделе "Использование авторизации RBAC".

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.

Автор субъекта:

Другие участник:

Следующие шаги