Модуль Kubernetes, работающий на вычислительном движке Google, не может получить доступ к службе метаданных

Модуль Kubernetes, работающий на вычислительном движке Google, не может получить доступ к службе метаданных

Я пытаюсь запустить Google Cloud Python SDK из модуля K8, работающего на Google Compute Engine. К виртуальной машине прикреплена учетная запись службы, которая предоставляет ей доступ к менеджеру секретов. Я могу получить доступ к менеджеру секретов с хоста, однако запуск Python SDK из модуля K8 жалуется на невозможность доступа к службе метаданных

>>> secret_id = 'unskript_test'
>>> name = client.secret_path(project_id, secret_id)
>>> response = client.get_secret(request={"name": name})
Traceback (most recent call last):
  File "/opt/conda/lib/python3.7/site-packages/google/api_core/grpc_helpers.py", line 67, in error_remapped_callable
    return callable_(*args, **kwargs)
  File "/opt/conda/lib/python3.7/site-packages/grpc/_channel.py", line 946, in __call__
    return _end_unary_response_blocking(state, call, False, None)
  File "/opt/conda/lib/python3.7/site-packages/grpc/_channel.py", line 849, in _end_unary_response_blocking
    raise _InactiveRpcError(state)
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
    status = StatusCode.UNAVAILABLE
    details = "Getting metadata from plugin failed with error: Failed to retrieve http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/?recursive=true from the Google Compute Enginemetadata service. Compute Engine Metadata server unavailable"
    debug_error_string = "{"created":"@1630634901.103779641","description":"Getting metadata from plugin failed with error: Failed to retrieve http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/?recursive=true from the Google Compute Enginemetadata service. Compute Engine Metadata server unavailable","file":"src/core/lib/security/credentials/plugin/plugin_credentials.cc","file_line":90,"grpc_status":14}"
>

metadata.google.internal не разрешается из модуля k8

jovyan@jovyan-25ca6c8c-157d-49e5-9366-f9d57fcb7a9f:~$ wget http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/?recursive=true
--2021-09-03 02:11:19--  http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/?recursive=true
Resolving metadata.google.internal (metadata.google.internal)... failed: Name or service not known.
wget: unable to resolve host address ‘metadata.google.internal’

Однако хост может решить эту проблему.

ubuntu@gcp-test-proxy:~$ wget http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/?recursive=true
--2021-09-03 02:11:27--  http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/?recursive=true
Resolving metadata.google.internal (metadata.google.internal)... 169.254.169.254
Connecting to metadata.google.internal (metadata.google.internal)|169.254.169.254|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
2021-09-03 02:11:27 ERROR 403: Forbidden.

Как заставить модуль разрешить metadata.google.internal?

решение1

Это вызвано тем, что pod Kubernetes не может преобразовать metadata.google.internalDNS-имя в правильный IP. На вашей хост-машине, вероятно, есть запись, /etc/hostsкоторая жестко привязывает этот домен к IP: 169.254.169.254.

Вы сможете повторить это в своем Pod, изменив его /etc/hostsфайл.

Просто помните, что это будет работать только на виртуальных машинах, работающих на GCP. За пределами IP-адрес 169.254.169.254 — это просто еще один IP-адрес, который не имеет особого значения.

EDIT: Только что проверил /etc/hosts на одной из моих виртуальных машин GCP, и вот что я обнаружил:

$ cat /etc/hosts
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
169.254.169.254 metadata.google.internal metadata

Так что попробуйте просто скопировать последнюю строку в свои модули /etc/hosts.

решение2

Проблема была в том, что microk8s не копировал хост и т. д. хосты записи в pods. После того, как мы перешли на k3, это было решено

Связанный контент