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

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

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

Компонент tap использует порт 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=$(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/linkerd2#3497, когда служба Linkerd имел некоторые внутренние проблемы и не мог отвечать на запросы службы API. Исправлено перезапуском его модулей.

Решение:

Шаги, которые я выполнил:

1. kubectl get apiservices : Если связанный API-сервис не работает с ошибкой 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

3. Используйте kubectl описать pod/pod_name, чтобы проверить ошибку в pod coreDNS, и если он не работает из-за /etc/coredns/Corefile:10 - Error during parsing: Unknown directive proxy, то нам нужно использовать переадресацию вместо прокси в файле yaml, где находится конфигурация coreDNS. Поскольку CoreDNS версии 1.5x, используемой изображением, больше не поддерживает ключевое слово proxy.