Ошибка "невозможно получить полный список серверных API: tap.linkerd.io/v1alpha1" при использовании Linkerd в частном кластере в GKE

Почему при установке возникает следующая ошибка Linkerd 2.x на частном кластере в ГКЭ?

Error: could not get apiVersions from Kubernetes: unable to retrieve the complete list of server APIs: tap.linkerd.io/v1alpha1: the server is currently unable to handle the request
Источник

5 ответов

Решение:

Я выполнил следующие шаги:

  1. kubectl get apiservices: Если связанный apiservice не работает с ошибкой CrashLoopBackOff, попробуйте выполнить шаг 2, в противном случае просто попробуйте перезапустить связанный сервис, используя kubectl delete apiservice/"service_name". Для меня это был v1alpha1.tap.linkerd.io.

  2. kubectl get pods -n kube-system и обнаружил, что модули, такие как metrics-server, linkered, kubernetes-dashboard, не работают из-за отказа основного модуля coreDNS.

Для меня это было:

NAME                          READY   STATUS             RESTARTS   AGE
pod/coredns-85577b65b-zj2x2   0/1     CrashLoopBackOff   7          13m
  1. Используйте kubectl describe pod/"pod_name", чтобы проверить ошибку в модуле coreDNS, и если он не работает из-за /etc/coredns/Corefile:10 - Error during parsing: Unknown directive proxy, то нам нужно использовать пересылку вместо прокси в файле yaml, где находится конфигурация coreDNS. Поскольку CoreDNS версии 1.5x, используемый изображением, больше не поддерживает ключевое слово proxy.
Источник

В моем случае это было связано с linkerd / linkerd2#3497, когда служба Linkerd имела некоторые внутренние проблемы и не могла отвечать на запросы службы API. Исправлено перезапуском его подов.

Источник

В правилах брандмауэра по умолчанию из частного кластера на GKE разрешают только трафик на порты443 а также 10250. Это позволяет общаться сkube-apiserver а также kubeletсоответственно.

Linkerd использует порты 8443 а также 8089для связи между элементом управления и прокси-серверами, развернутыми в плоскости данных.

Компонент крана использует порт8089 обрабатывать запросы к apiserver.

Компоненты прокси-инжектора и валидатора профиля службы, которые являются типами контроллеров доступа, используют порт8443 для обработки запросов.

Документы Linkerd 2 включают инструкции по настройке брандмауэра в частном кластере GKE: https://linkerd.io/2/reference/cluster-configuration/

Они включены ниже:

Получите имя кластера:

CLUSTER_NAME=your-cluster-name
gcloud config set compute/zone your-zone-or-region

Получите кластер MASTER_IPV4_CIDR:

MASTER_IPV4_CIDR=$(gcloud container clusters describe $CLUSTER_NAME \
  | grep "masterIpv4CidrBlock: " \
  | awk '{print $2}')

Получите кластер NETWORK:

NETWORK=$(gcloud container clusters describe $CLUSTER_NAME \
  | grep "^network: " \
  | awk '{print $2}')

Получите автоматически сгенерированный кластер NETWORK_TARGET_TAG:

NETWORK_TARGET_TAG=$(gcloud compute firewall-rules list \
  --filter network=$NETWORK --format json \
  | jq ".[] | select(.name | contains(\"$CLUSTER_NAME\"))" \
  | jq -r '.targetTags[0]' | head -1)

Проверьте значения:

echo $MASTER_IPV4_CIDR $NETWORK $NETWORK_TARGET_TAG

# example output
10.0.0.0/28 foo-network gke-foo-cluster-c1ecba83-node

Создайте правила брандмауэра для прокси-инжектора и нажмите:

gcloud compute firewall-rules create gke-to-linkerd-control-plane \
  --network "$NETWORK" \
  --allow "tcp:8443,tcp:8089" \
  --source-ranges "$MASTER_IPV4_CIDR" \
  --target-tags "$NETWORK_TARGET_TAG" \
  --priority 1000 \
  --description "Allow traffic on ports 8843, 8089 for linkerd control-plane components"

Наконец, убедитесь, что брандмауэр создан:

gcloud compute firewall-rules describe gke-to-linkerd-control-plane
Источник

Это была проблема компоновщика для меня. Чтобы диагностировать любые проблемы, связанные с linkerd, вы можете использовать интерфейс командной строки linkerd и запустить linkerd checkэто должно показать вам, есть ли проблема с linkerd и ссылками на инструкции по ее устранению.

Для меня проблема заключалась в том, что срок действия корневых сертификатов linkerd истек. В моем случае linkerd был экспериментальным в кластере разработки, поэтому я удалил его. Однако, если вам нужно обновить свои сертификаты, вы можете следовать инструкциям по следующей ссылке.

https://linkerd.io/2.11/tasks/replacing_expired_certificates/

Благодаря /questions/50692072/oshibka-nevozmozhno-poluchit-polnyij-spisok-servernyih-api-taplinkerdiov1alpha1/50692082#50692082 я оказался на правильном пути.

Источник

В моем случае это было вызвано тем, что NetworkPolicy блокировала доступ API-сервера к службе linkerd Tap. Имейте в виду, что если у вас есть NetworkPolicy, еслиtapмодули находятся в podSelector, и существует политика Ingress, которая определяетfromраздел, то аписерверу необходимо будет явно предоставить доступ.

Может быть сложно предоставить доступ только к API-серверу, поэтому вам может потребоваться просто открыть этот порт для службы Tap с помощью отдельного netpol (хотя любые другие предложения приветствуются).

Источник
Другие вопросы по тегам