为什么在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
解决方案：
我遵循的步骤是：
-
kubectl get apiservices：如果链接的apiservice因错误CrashLoopBackOff而关闭，请尝试执行步骤2，否则只需尝试使用kubectl delete apiservice/"重新启动链接的服务；service_name"；。对我来说，这是v1alpha1.tap.linkerd.io. -
kubectl get pods -n kube-system发现像metrics server、linked、kubernetes dashboard这样的pod由于主coreDNS pod宕机而宕机。
对我来说是：
NAME READY STATUS RESTARTS AGE
pod/coredns-85577b65b-zj2x2 0/1 CrashLoopBackOff 7 13m
- 使用kubectl描述pod/"；pod_name"为了检查coreDNS pod中的错误，如果它因为
/etc/coredns/Corefile:10 - Error during parsing: Unknown directive proxy而关闭，那么我们需要在coreDNS配置所在的yaml文件中使用forward而不是proxy。因为映像使用的CoreDNS版本1.5x不再支持proxy关键字
GKE上私有集群的默认防火墙规则只允许端口443和10250上的流量。这允许分别与kube-apiserver和kubelet进行通信。
CCD_ 9使用端口CCD_ 10和CCD_。
抽头组件使用端口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服务请求。通过重新启动pod修复。
这对我来说是一个linkerd问题。要诊断任何与linkerd相关的问题，您可以使用linkerd CLI并运行linkerd check，这将显示linkerd是否存在问题，并按照说明进行链接以修复。
对我来说，问题是linkerd根证书已经过期。在我的案例中，linkerd在开发集群中是实验性的，所以我删除了它。但是，如果你需要更新你的证书，你可以按照下面链接中的说明进行操作。
https://linkerd.io/2.11/tasks/replacing_expired_certificates/
感谢https://stackoverflow.com/a/59644120/1212371我走上了正确的道路。
在我的案例中，它是由NetworkPolicy阻止apiserver访问linkerd-tap服务引起的。请记住，如果您有NetworkPolicy，如果tappod在podSelector中，并且有一个指定from节的Ingress策略，则需要显式授予apiserver访问权限。
只允许apiserver访问可能很棘手，因此您可能只需要用一个单独的netpol为tap服务打开该端口(但欢迎任何其他建议(。