Кластер GKE с включенным Istio не надежно взаимодействует с API инфраструктуры сервисов Google - PullRequest
0 голосов
/ 25 мая 2020

Мне не удалось надежно разрешить моему кластеру Google Kubernetes Engine с поддержкой istio подключаться к конечным точкам Google Cloud (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"

Примерно через час, предположительно из-за того, что токен доступа истек, журналы прокси-сервера показывают, что он снова не смог получить доступ токен, и я больше не могу делать запросы к своему модулю.

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

Как я могу предотвратить такое поведение и надежно установить связь прокси-сервера с инфраструктурой служб Google API?

1 Ответ

1 голос
/ 25 мая 2020

Хотя я не совсем уверен, что это решение, похоже, что использование выделенной учетной записи службы для генерации токенов доступа в расширяемом контейнере прокси-сервера предотвращает описанное выше поведение, и я могу надежно отправлять запросы к прокси-серверу и восходящий сервис, даже через час.

У учетной записи службы, которую я использую, есть следующие роли:

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

Предполагая, что это стабильное решение проблемы, я гораздо более доволен этим результатом, потому что мне не на 100% комфортно использовать сервер метаданных, поскольку он полагается на учетную запись службы, связанную с узлом GKE. Эта учетная запись службы часто более мощная, чем она должна быть для ESP для выполнения своей работы.

Однако я буду продолжать следить за этим на всякий случай, если прокси-сервер снова станет недоступным.

...