GKE上专用群集的默认防火墙规则仅允许端口443和10250上的流量。这将分别允许与kube-apiserver和kubelet通信。
Linkerd使用端口8443和8089在控制和部署到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

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

解决方案：

我遵循的步骤是：

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不再支持代理关键字。

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

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