☰

O pod Kubernetes em execução no Google Compute Engine não consegue acessar o serviço de metadados

tag-icon • tag-icon kubernetes google-compute-engine
O pod Kubernetes em execução no Google Compute Engine não consegue acessar o serviço de metadados

Estou tentando executar o Google Cloud Python SDK de dentro de um pod K8, rodando no Google Compute Engine. Há uma conta de serviço anexada à VM, que dá acesso ao gerenciador de segredos. Consigo acessar o gerenciador de segredos do host, mas a execução do SDK python do pod k8 reclama de não conseguir acessar o serviço de metadados

>>> 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 não é resolvido no pod 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’

No entanto, o host é capaz de resolvê-lo

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.

Como posso fazer com que o pod resolva metadata.google.internal?

Responder1

Isso é causado porque o pod do Kubernetes não consegue resolver o metadata.google.internalnome DNS para o IP adequado. Sua máquina host provavelmente tem uma entrada /etc/hostsque codifica esse domínio para o IP: 169.254.169.254.

Você poderá replicar isso em seu pod modificando seu /etc/hostsarquivo.

Lembre-se de que isso só funcionará em VMs executadas no GCP. Lá fora, o endereço IP 169.254.169.254 é apenas mais um endereço IP que não tem significado especial.

EDIT: acabei de verificar /etc/hosts em uma das minhas VMs do GCP e aqui está o que encontrei:

$ 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

Então tente copiar a última linha para seus pods /etc/hosts.

Responder2

O problema era que os microk8s não copiavam a entrada de hosts do host etc. para os pods. Assim que mudamos para k3, o problema foi resolvido

informação relacionada