为什么当我在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
为什么当我在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条答案
按热度按时间a0x5cqrl1#
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/
它们包括如下:
获取群集名称:
获取群集MASTER_IPV4_CIDR:
获取群集网络:
获取群集自动生成的NETWORK_TARGET_TAG:
验证值:
为代理注入器创建防火墙规则,然后点击:
最后,验证防火墙是否已创建:
wr98u20j2#
在我的例子中,它与linkerd/linkerd2#3497有关,当时Linkerd服务有一些内部问题,无法响应API服务请求。通过重新启动它的pod修复。
ct2axkht3#
解决方案:
我遵循的步骤是:
kubectl get apiservices
:如果链接的apiservice因错误CrashLoopBackOff而关闭,请尝试按照步骤2操作,否则请尝试使用kubectl delete apiservice/“service_name”重新启动链接的服务。kubectl get pods -n kube-system
,发现像metric-server、linkered、kubernetes-dashboard这样的pod由于主核心DNS pod出现故障而出现故障。对我来说是:
1.使用kubectl describe pod/“pod_name”来检查coreDNS pod中的错误,如果它是因为
/etc/coredns/Corefile:10 - Error during parsing: Unknown directive proxy
而关闭的,那么我们需要在coreDNS配置所在的yaml文件中使用转发而不是代理。因为映像使用的CoreDNS版本1.5x不再支持代理关键字。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,我才走上了正确的道路。
gorkyyrv5#
在我的例子中,这是由于网络策略阻止了apiserver访问linkerd tap服务。请记住,如果您有网络策略,如果
tap
pod在podSelector中,并且有指定from
部分的Ingress策略,那么apiserver将需要显式地被授予访问权限。只给予apiserver访问权限可能会比较麻烦,因此您可能需要使用单独的netpol为tap服务打开该端口(欢迎任何其他建议)。