启用了Istio的GKE集群无法可靠地与Google服务基础架构API进行通信。

Question

我一直无法可靠地允许我的istio启用的Google Kubernetes Engine集群通过以下方式连接到Google Cloud Endpoints（服务管理API）。可扩展服务代理. 当我部署花苞时，代理总是无法启动，导致花苞被重新启动，并输出以下错误。

INFO:Fetching an access token from the metadata service
WARNING:Retrying (Retry(total=0, connect=None, read=None, redirect=0, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fea4abece90>: Failed to establish a new connection: [Errno 111] Connection refused',)': /computeMetadata/v1/instance/service-accounts/default/token
ERROR:Failed fetching metadata attribute: http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token

然而重启后，代理报告一切正常，它能够抓取一个访问令牌，我能够成功地向Pod发出请求。

INFO:Fetching an access token from the metadata service
INFO:Fetching the service config ID from the rollouts service
INFO:Fetching the service configuration from the service management service
INFO:Attribute zone: europe-west2-a
INFO:Attribute project_id: my-project
INFO:Attribute kube_env: KUBE_ENV
nginx: [warn] Using trusted CA certificates file: /etc/nginx/trusted-ca-certificates.crt
10.154.0.5 - - [23/May/2020:21:19:36 +0000] "GET /domains HTTP/1.1" 200 221 "-" "curl/7.58.0"

大约一个小时后，可能是因为访问令牌过期了，代理日志显示它又无法获取访问令牌，我无法再向Pod发出请求。

2020/05/23 22:14:04 [error] 9#9: upstream timed out (110: Connection timed out)
2020/05/23 22:14:04[error]9#9: Failed to fetch service account token
2020/05/23 22:14:04[error]9#9: Fetch access token unexpected status: INTERNAL: Failed to fetch service account token

我有一个ServiceEntry资源，应该允许代理向GKE节点的元数据服务器发出请求。

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: google-metadata-server
spec:
  hosts:
  - metadata.google.internal # GCE metadata server
  addresses:
  - 169.254.169.254 # GCE metadata server
  location: MESH_EXTERNAL
  ports:
  - name: http
    number: 80
    protocol: HTTP
  - name: https
    number: 443
    protocol: HTTPS

我已经通过以下方式确认了这一点 exec到其中一个容器中并运行。

curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token

我如何才能防止这种行为，并可靠地让代理与谷歌服务基础设施API通信？

Answer 1

虽然我并不完全相信这是解决方案，但似乎使用专用服务帐户在可扩展服务代理容器内生成访问令牌可以防止上述报告的行为发生，而且我能够可靠地向代理和上游服务发出请求，即使在一个小时之后。

我使用的服务账户具有以下角色。

• roles/cloudtrace.agent
• roles/servicemanagement.serviceController

假设这是一个稳定的解决问题的方法，我对这个结果很满意，因为我并不是100%放心使用元数据服务器，因为它依赖于与GKE节点相关联的服务账户。这个服务账户往往比ESP需要的功能更强大，以便ESP完成它的工作。

不过，我会继续监控，以防万一上游的代理再次变得无法访问。