Esta página foi traduzida pela API Cloud Translation.

Antes de começar

O registo de um cluster do Kubernetes fora do Google Cloud Google Cloud requer os seguintes passos, além de concluir os pré-requisitos gerais.

Confirme a conetividade de rede

Para registar o cluster com êxito, tem de garantir que os domínios abaixo estão acessíveis a partir do cluster do Kubernetes.

cloudresourcemanager.googleapis.com resolve os metadados relativos ao Google Cloud projeto ao qual o cluster está a ser ligado.
oauth2.googleapis.com para obter tokens OAuth de curta duração para operações de agentes em relação a gkeconnect.googleapis.com.
gkeconnect.googleapis.com para estabelecer o canal usado para receber pedidos de Google Cloud e emitir respostas.
gkehub.googleapis.com para criar Google Cloudrecursos de membro da frota do lado do servidor que correspondem ao cluster com o qual está a estabelecer ligação Google Cloud.
www.googleapis.com para autenticar tokens de serviço de Google Cloud pedidos de serviço recebidos.
gcr.io e storage.googleapis.com para extrair a imagem do agente GKE Connect.

Se quiser registar o cluster com a identidade de carga de trabalho da frota, os seguintes domínios também têm de estar acessíveis:

securetoken.googleapis.com
iamcredentials.googleapis.com
sts.googleapis.com

Se estiver a usar um proxy para o Connect, também tem de atualizar a lista de autorizações do proxy com os domínios relevantes.

Se usar o gcloud para registar o cluster do Kubernetes, estes domínios também têm de estar acessíveis no ambiente onde executa os comandos gcloud.

Usar os VPC Service Controls

Se quiser usar os VPC Service Controls para segurança de dados adicional na sua aplicação, tem de garantir que os seguintes serviços estão no seu perímetro de serviço:

API Resource Manager (cloudresourcemanager.googleapis.com)
API GKE Connect (gkeconnect.googleapis.com)
API Fleet (gkehub.googleapis.com)

Se quiser registar o cluster com a identidade de carga de trabalho da frota ativada, também precisa dos seguintes serviços:

API das credenciais da conta de serviço de IAM (iamcredentials.googleapis.com)
API Security Token Service (sts.googleapis.com)

Também tem de configurar a conetividade privada para aceder às APIs relevantes. Pode saber como fazê-lo em Configurar a conetividade privada.

Configure a identidade

Todas as opções de registo de clusters manuais fora do Google Cloud requerem que configure a autenticação no Google. Pode ser o seguinte:

Workload Identity da frota (recomendado quando disponível). Pode saber mais sobre as vantagens de ativar o Workload Identity da frota em Use o Workload Identity da frota.
Uma Google Cloud conta de serviço

Os clusters anexados podem ser registados com a identidade de carga de trabalho da frota ativada se o cluster cumprir os nossos pré-requisitos do cluster anexado, conforme descrito abaixo. Caso contrário, registe os clusters anexados com uma Google Cloud conta de serviço para autenticação. A secção seguinte mostra como criar uma conta de serviço.

Crie uma Google Cloud conta de serviço com o `gcloud`

Para registar manualmente um cluster através de uma Google Cloud conta de serviço, precisa de um ficheiro JSON com as credenciais da conta de serviço. Para seguir o princípio do menor privilégio, recomendamos que crie uma conta de serviço distinta para cada cluster do Kubernetes que registar e que associe apenas funções da IAM ao cluster correspondente.

Para criar este ficheiro, siga estes passos:

gcloud

Crie uma conta de serviço executando o seguinte comando:

gcloud iam service-accounts create SERVICE_ACCOUNT_NAME --project=FLEET_HOST_PROJECT_ID

Apresente uma lista de todas as contas de serviço de um projeto executando o seguinte comando:

gcloud iam service-accounts list --project=FLEET_HOST_PROJECT_ID

Se estiver a criar uma conta de serviço distinta para cada cluster do Kubernetes que registar, associe a função de IAM gkehub.connect à conta de serviço do respetivo cluster com uma condição de IAM no nome de associação do cluster:

MEMBERSHIP_NAME=MEMBERSHIP_NAME
FLEET_HOST_PROJECT_ID=FLEET_HOST_PROJECT_ID
SERVICE_ACCOUNT_NAME=SERVICE_ACCOUNT_NAME
gcloud projects add-iam-policy-binding ${FLEET_HOST_PROJECT_ID} \
   --member="serviceAccount:${SERVICE_ACCOUNT_NAME}@${FLEET_HOST_PROJECT_ID}.iam.gserviceaccount.com" \
   --role="roles/gkehub.connect" \
   --condition "expression=resource.name == \
'projects/${FLEET_HOST_PROJECT_ID}/locations/global/memberships/${MEMBERSHIP_NAME}',\
title=bind-${SERVICE_ACCOUNT_NAME}-to-${MEMBERSHIP_NAME}"

Caso contrário, associe a função à conta de serviço para todos os clusters no projeto sem a condição.

FLEET_HOST_PROJECT_ID=FLEET_HOST_PROJECT_ID
gcloud projects add-iam-policy-binding ${FLEET_HOST_PROJECT_ID} \
   --member="serviceAccount:SERVICE_ACCOUNT_NAME@${FLEET_HOST_PROJECT_ID}.iam.gserviceaccount.com" \
   --role="roles/gkehub.connect"

Transfira o ficheiro JSON da chave privada da conta de serviço. Use este ficheiro quando registar um cluster:

FLEET_HOST_PROJECT_ID=FLEET_HOST_PROJECT_ID
gcloud iam service-accounts keys create LOCAL_KEY_PATH \
   --iam-account=SERVICE_ACCOUNT_NAME@${FLEET_HOST_PROJECT_ID}.iam.gserviceaccount.com \
   --project=${FLEET_HOST_PROJECT_ID}

where:

FLEET_HOST_PROJECT_ID é o Google Cloud ID do projeto no qual quer registar clusters. Saiba como encontrar este valor.
SERVICE_ACCOUNT_NAME é o nome a apresentar que escolhe para a [conta de serviço].
MEMBERSHIP_NAME é o nome de associação que escolhe para representar o cluster de forma exclusiva enquanto o regista.
LOCAL_KEY_PATH é um caminho de ficheiro local onde quer guardar a chave privada da conta de serviço, um ficheiro JSON. Recomendamos que dê ao ficheiro o nome da conta de serviço e o ID do projeto, como /tmp/creds/[SERVICE_ACCOUNT_NAME]-[FLEET_HOST_PROJECT_ID].json.

Pré-requisitos do cluster anexado

Consoante o tipo de cluster Kubernetes de terceiros que quer registar como um cluster anexado, pode ter de cumprir alguns requisitos adicionais para instalar o Connect Agent e/ou usar a identidade de carga de trabalho da frota.

Configure as restrições de contexto de segurança (SCC) (clusters do OpenShift)

Nos clusters OpenShift OKE e OKD, os administradores podem usar SCCs para controlar as autorizações dos pods. Para permitir a instalação do Connect Agent no seu cluster, tem de criar um SCC personalizado.

A seguinte definição de SCC de exemplo especifica o conjunto de condições com que o Connect Agent tem de ser executado para ser aceite no cluster:

# Connect Agent SCC
apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  name: gke-connect-scc
allowPrivilegeEscalation: false
# This is redundant with non-root + disallow privilege escalation,
# but we provide it for defense in depth.
requiredDropCapabilities:
- ALL
runAsUser:
  type: MustRunAsNonRoot
seLinuxContext:
  type: RunAsAny
supplementalGroups:
  type: MustRunAs
  ranges:
  - min: 1
    max: 65535
fsGroup:
  type: MustRunAs
  ranges:
  - min: 1
    max: 65535
volumes:
- secret
- projected
readOnlyRootFilesystem: true
seccompProfiles:
- docker/default
users:
groups:
  # Grants all service accounts in the gke-connect namespace access to this SCC
  - system:serviceaccounts:gke-connect

Partindo do princípio de que guardou a definição de SCC como gke-connect-scc.yaml, use a ferramenta de linha de comandos oc do OpenShift para criar o SCC gke-connect-scc para o seu cluster, da seguinte forma:

$ oc create -f gke-connect-scc.yaml

Para verificar se o SCC personalizado foi criado, execute o seguinte comando oc:

$ oc get scc | grep gke-connect-scc

Requisitos do Workload Identity da frota

Pode registar clusters anexados com a Identidade de carga de trabalho da frota ativada se a sua plataforma criar um ponto final OIDC público para o cluster (ou lhe permitir criar um) ou se tiver a deteção do emissor de contas de serviço do Kubernetes ativada para o cluster. Se não conseguir cumprir estes requisitos, tem de registar clusters anexados com uma Google Cloud conta de serviço para autenticação.

Para tipos de clusters específicos, consulte o seguinte:

Clusters do OpenShift: podem ser registados com o Workload Identity da frota ativado depois de configurar o SCC personalizado, conforme descrito acima.
Clusters kind: requerem que a deteção do emissor da conta de serviço esteja ativada para usar o Workload Identity da frota. Esta opção está ativada por predefinição a partir da versão 1.20 do Kubernetes. Se precisar de ativar esta funcionalidade, siga as instruções em Projeção do volume de tokens de contas de serviço. A deteção do emissor da conta de serviço é ativada automaticamente quando o projeto de volume de tokens da conta de serviço está ativado.

O que se segue?

Siga as instruções para registar um cluster.