Use um registro de imagem particular sem secrets

O GKE na AWS oferece uma maneira de extrair imagens particulares do Artifact Registry ou do Container Registry sem precisar usar um secret do Kubernetes. Anteriormente, era preciso executar as seguintes etapas:

  1. Criar uma conta de serviço do Google Identity and Access Management (IAM).
  2. Conceda permissões à conta de serviço para acessar o registro particular.
  3. Faça o download da chave da conta de serviço e salve-a como um secret do Kubernetes no seu cluster.
  4. Referencie esse secret no manifesto YAML para pods ou implantações para que eles possam acessar imagens do repositório de contêineres privados.
  5. Alterne e gerencie regularmente as chaves associadas à conta de serviço do Google IAM.

O GKE na AWS elimina todas essas etapas manuais e processa automaticamente a autenticação e a autorização necessárias para extrair imagens particulares.

Antes de começar

Para executar as etapas desta página, primeiro conclua o seguinte:

Verificar se há imagens no Artifact Registry

Para concluir o restante destas etapas, você precisa de uma imagem de contêiner. Veja o nome das suas imagens de contêiner executando as seguintes etapas:

  1. Configure a ferramenta de linha de comando do Docker para autenticar no Artifact Registry com o SDK do Google Cloud:

    gcloud auth configure-docker

    A Google Cloud CLI registra um auxiliar de credenciais para todos os registros do Docker compatíveis com o Google.

  2. Confirme se o Artifact Registry inclui uma imagem com o comando docker images.

    docker images

    O Docker se conecta ao Artifact Registry e retorna as imagens disponíveis no seu repositório. Por exemplo, a resposta a seguir mostra uma imagem de contêiner chamada hello-app no repositório PROJECT_NAME em us-west1-docker.pkg.dev.

    REPOSITORY                                                            TAG          IMAGE ID       CREATED          SIZE
us-west1-docker.pkg.dev/PROJECT_NAME/hello-repo/hello-app   v1           f7cfe0d58569   21 minutes ago   11.5MB

Se você não tiver uma imagem de contêiner pronta, crie uma seguindo as etapas em Como implantar um aplicativo em contêiner.

Criar pods com imagens privadas sem secrets de extração de imagens

Para criar um pod capaz de acessar uma imagem de contêiner particular de um registro, não é mais necessário fornecer o campo spec.imagePullSecrets na especificação do pod. Para configurar o pod, siga estas etapas:

  1. Crie uma definição de pod sem o campo spec.imagePullSecrets:

    apiVersion: v1
kind: Pod
metadata:
  name: POD_NAME
spec:
  containers:
  - name: CONTAINER_NAME
    image: LOCATION-docker.pkg.dev/PROJECT_NAME/REPOSITORY_NAME/IMAGE_NAME:IMAGE_VERSION

    Substitua:

    • POD_NAME: o nome do pod.
    • CONTAINER_NAME: o nome do contêiner dentro do pod
    • LOCATION: a região do Google Cloud que contém seu registro. Por exemplo, us-west1.
    • PROJECT_NAME: o nome do projeto do Google que hospeda o repositório do Artifact Registry, que pode ser o mesmo projeto do cluster. Se o repositório estiver em um projeto diferente, consulte Usar o Artifact Registry quando ele não estiver no mesmo projeto que o cluster para etapas adicionais.
    • REPOSITORY_NAME: o nome do seu repositório
    • IMAGE_NAME: o nome da imagem.
    • IMAGE_VERSION: a versão da imagem.

  2. Aplique a configuração ao cluster com kubectl:

    kubectl apply -f YAML_FILE_NAME

    Substitua YAML_FILE_NAME pelo nome do arquivo YAML.

Exemplo de criação de pods sem Secrets pull de imagem

Confira um exemplo de como criar um pod do Kubernetes sem precisar de secrets de extração de imagem. O pod extrai a imagem hello-app do Artifact Registry.

  1. Para extrair a imagem hello-app, copie o seguinte YAML em um arquivo chamado hello-pod.yaml:

    apiVersion: v1
kind: Pod
metadata:
  name: hello-pod
spec:
  containers:
  - name: hello-container
    image: us-west1-docker.pkg.dev/example-project/hello-repo/hello-app:v1

  2. Aplique a configuração ao cluster com kubectl:

    kubectl apply -f hello-pod.yaml

  3. Confirme se o pod está sendo executado com kubectl get.

    kubectl get pod/hello-pod

    A resposta inclui um pod com status Running.

    NAME        READY   STATUS    RESTARTS   AGE
hello-pod   1/1     Running   0          15s

Criar implantações com imagens privadas sem secrets de pull de imagens

Para criar uma implantação que possa acessar uma imagem de contêiner particular de um registro, não é mais necessário fornecer o campo spec.imagePullSecrets na especificação da implantação. Para configurar a implantação, siga estas etapas:

  1. Crie uma definição de implantação sem o campo spec.imagePullSecrets:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: DEPLOYMENT_NAME
spec:
  replicas: NUMBER_OF_REPLICAS
  template:
    spec:
      containers:
      - name: CONTAINER_NAME
        image: LOCATION-docker.pkg.dev/PROJECT_NAME/REPOSITORY_NAME/IMAGE_NAME:IMAGE_VERSION

    Substitua:

    • DEPLOYMENT_NAME: o nome da implantação.
    • NUMBER_OF_REPLICAS: quantas instâncias do pod definido na implantação devem estar em execução a qualquer momento.
    • CONTAINER_NAME: o nome do contêiner dentro do pod
    • LOCATION: a região do Google Cloud que contém seu registro. Por exemplo, us-west1.
    • PROJECT_NAME: o nome do projeto do Google que hospeda o repositório do Artifact Registry, que pode não ser igual ao projeto do cluster. Se o repositório estiver em um projeto diferente, consulte Usar o Artifact Registry quando ele não estiver no mesmo projeto que o cluster para etapas adicionais.
    • REPOSITORY_NAME: o nome do seu repositório
    • IMAGE_NAME: o nome da imagem.
    • IMAGE_VERSION: a versão da imagem.

  2. Aplique a configuração ao cluster com kubectl.

    kubectl apply -f name-of-your-yaml-file.yaml

Exemplo de criação de uma implantação sem Secrets de pull de imagem

Este é um exemplo de como criar uma implantação sem Secrets de pull de imagens. A implantação extrai uma imagem hello-app do Artifact Registry.

  1. Crie um arquivo chamado hello-deployment.yaml com o seguinte conteúdo:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-app-deployment
spec:
  selector:
    matchLabels:
      app: products
      department: sales
  replicas: 3
  template:
    metadata:
      labels:
        app: products
        department: sales
    spec:
      containers:
      - name: hello
        image: LOCATION-docker.pkg.dev/PROJECT_NAME/hello-repo/hello-app:v1
        env:
        - name: "PORT"
          value: "50001"

    Substitua:

  2. Aplique a configuração ao cluster com kubectl.

    kubectl apply -f hello-deployment.yaml

  3. Confirme se a implantação está em execução com kubectl pods.

    kubectl get pods --selector=app=products

    A saída exibe três pods Running.

    NAME                                    READY   STATUS    RESTARTS   AGE
hello-app-deployment-67d9c6d98c-b69f2   1/1     Running   0          14m
hello-app-deployment-67d9c6d98c-d6k5c   1/1     Running   0          14m
hello-app-deployment-67d9c6d98c-p2md5   1/1     Running   0          14m

Use o Artifact Registry quando ele não estiver no mesmo projeto que o cluster

Para usar um repositório do Artifact Registry que está em um projeto do Google diferente daquele que contém seu cluster, execute as seguintes etapas:

Conceda à conta de serviço das instâncias de máquina virtual do pool de nós do cluster, conhecida como Agente de serviço de máquinas do pool de nós, as permissões necessárias para acessar esse registro.

gcloud projects add-iam-policy-binding AR_PROJECT_ID \
  --member=NODE_POOL_MACHINE_SERVICE_AGENT \
  --role=ROLE

Essa etapa garante que o cluster possa recuperar artefatos do registro nesse projeto separado.

Substitua:

  • AR_PROJECT_ID: o ID do projeto do Google que hospeda o Artifact Registry.
  • NODE_POOL_MACHINE_SERVICE_AGENT: a conta de serviço do pool de nós do cluster, que tem o seguinte formato: service-CLUSTER_RESOURCE_PROJECT_NUMBER@gcp-sa-gkemulticloudnpmachine.iam.gserviceaccount.com
  • ROLE: o papel roles/artifactregistry.reader ou um papel personalizado que concede permissões suficientes para acessar imagens no repositório do Artifact Registry.

Usar o Google Container Registry particular

Para integrar um Google Container Registry particular ao seu cluster do GKE na AWS, independentemente do local do projeto do Google, siga estas etapas:

Permita que o Agente de serviço de máquinas do pool de nós, a conta de serviço das instâncias de máquina virtual do pool de nós do cluster, acesse o Container Registry:

gcloud projects add-iam-policy-binding GCR_PROJECT_ID \
  --member=NODE_POOL_MACHINE_SERVICE_AGENT \
  --role=ROLE

Essa etapa permite o acesso da conta de serviço do cluster às imagens de contêiner particulares.

Substitua:

  • GCR_PROJECT_ID: o ID do projeto que hospeda o Container Registry.
  • NODE_POOL_MACHINE_SERVICE_AGENT: a conta de serviço do pool de nós, no formato service-CLUSTER_RESOURCE_PROJECT_NUMBER@gcp-sa-gkemulticloudnpmachine.iam.gserviceaccount.com.
  • ROLE: escolha storage.objectViewer ou um papel personalizado para ter acesso suficiente ao Container Registry. Tenha cuidado com acesso amplo com storage.objectViewer.

Limpar

Para remover os recursos criados nesta página, execute estes comandos:

kubectl apply -f POD_YAML_FILE
kubectl delete -f DEPLOYMENT_YAML_FILE

Substitua:

  • POD_YAML_FILE: o nome do arquivo YAML em que você definiu o pod.
  • DEPLOYMENT_YAML_FILE: o nome do arquivo YAML em que você definiu a implantação.

A seguir