kubernetes “无法检索服务器API的完整列表:tap.linkerd.io/v1alpha1“在GKE中的专用群集上使用Linkerd时出错

mwg9r5ms  于 2023-03-12  发布在  Kubernetes
关注(0)|答案(5)|浏览(135)

为什么当我在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
a0x5cqrl

a0x5cqrl1#

GKE上专用群集的默认防火墙规则仅允许端口44310250上的流量。这将分别允许与kube-apiserverkubelet通信。
Linkerd使用端口84438089在控制和部署到data plane的代理之间进行通信。
tap组件使用端口8089来处理对其apiserver的请求。
代理注入器和服务配置文件验证器组件都是admission controllers类型,使用端口8443处理请求。
Linkerd 2 docs包含在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
wr98u20j

wr98u20j2#

在我的例子中,它与linkerd/linkerd2#3497有关,当时Linkerd服务有一些内部问题,无法响应API服务请求。通过重新启动它的pod修复。

ct2axkht

ct2axkht3#

解决方案:

我遵循的步骤是:

  1. kubectl get apiservices:如果链接的apiservice因错误CrashLoopBackOff而关闭,请尝试按照步骤2操作,否则请尝试使用kubectl delete apiservice/“service_name”重新启动链接的服务。
  2. kubectl get pods -n kube-system,发现像metric-server、linkered、kubernetes-dashboard这样的pod由于主核心DNS pod出现故障而出现故障。
    对我来说是:
NAME                          READY   STATUS             RESTARTS   AGE
pod/coredns-85577b65b-zj2x2   0/1     CrashLoopBackOff   7          13m

1.使用kubectl describe pod/“pod_name”来检查coreDNS pod中的错误,如果它是因为/etc/coredns/Corefile:10 - Error during parsing: Unknown directive proxy而关闭的,那么我们需要在coreDNS配置所在的yaml文件中使用转发而不是代理。因为映像使用的CoreDNS版本1.5x不再支持代理关键字。

m1m5dgzv

m1m5dgzv4#

这是一个linkerd的问题。要诊断任何与linkerd相关的问题,您可以使用linkerd CLI并运行linkerd check,这应该会显示您是否存在linkerd问题,并说明如何修复它。
对我来说,问题是linkerd根证书过期了,在我的例子中,linkerd是在一个开发集群中试验的,所以我删除了它,但是,如果你需要更新你的证书,你可以按照下面的链接中的说明操作。
https://linkerd.io/2.11/tasks/replacing_expired_certificates/
多亏了https://stackoverflow.com/a/59644120/1212371,我才走上了正确的道路。

gorkyyrv

gorkyyrv5#

在我的例子中,这是由于网络策略阻止了apiserver访问linkerd tap服务。请记住,如果您有网络策略,如果tap pod在podSelector中,并且有指定from部分的Ingress策略,那么apiserver将需要显式地被授予访问权限。
只给予apiserver访问权限可能会比较麻烦,因此您可能需要使用单独的netpol为tap服务打开该端口(欢迎任何其他建议)。

相关问题