Implantar contêineres (GKE, clusters do GKE)

Nesta página, explicamos como implantar uma imagem de contêiner em um cluster do Google Kubernetes Engine (GKE) ou em um cluster do GKE em que a autorização binária está ativada. Os comandos kubectl usados para implantar a imagem são os mesmos que você usa para implantar imagens em clusters que não usam a autorização binária.

Antes de começar

Verifique se a API Binary Authorization está ativada no seu projeto e se há um cluster do GKE com autorização binária ativada. Consulte Como configurar no Google Kubernetes Engine ou Como configurar em clusters do GKE.

Instale kubectl para interagir com o GKE.

Configurar kubectl

Você precisa atualizar o arquivo local kubeconfig para sua instalação do kubectl. Isso fornece as credenciais e as informações de endpoint necessárias para acessar o cluster nos clusters do GKE ou no GKE.

Para configurar kubectl, execute este comando da gcloud:

GKE

gcloud container clusters get-credentials \
    --zone ZONE \
    CLUSTER_NAME

Substitua:

  • ZONE: o nome da zona do GKE em que o cluster está em execução, por exemplo, us-central1-a;
  • CLUSTER_NAME: o nome do cluster.

Clusters do GKE

gcloud container fleet memberships get-credentials \
    --location LOCATION \
    MEMBERSHIP_NAME

Substitua:

  • LOCATION: o local da associação da frota do cluster do GKE, por exemplo, global
  • MEMBERSHIP_NAME: o nome da associação da frota do cluster do GKE

Implantar a imagem do contêiner

Implante a imagem do contêiner da seguinte maneira:

  1. Configure as variáveis de ambiente:

    POD_NAME=POD_NAME
    IMAGE_PATH=IMAGE_PATH
    IMAGE_DIGEST=IMAGE_DIGEST
    

    Substitua:

    • POD_NAME: o nome que você quer usar para a carga de trabalho do GKE;
    • IMAGE_PATH: o caminho da imagem no Artifact Registry, Container Registry ou outro registro.
    • IMAGE_DIGEST: o resumo do manifesto da imagem. Os exemplos são:

      • Artifact Registry:
        • Caminho: us-docker.pkg.dev/google-samples/containers/gke/hello-app
        • Resumo: sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567
      • Container Registry:
        • Caminho: gcr.io/google-samples/hello-app
        • Resumo: sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4

      Para saber como conseguir o resumo de uma imagem no Artifact Registry, consulte Como gerenciar imagens. Para uma imagem no Container Registry, consulte Como listar versões de um imagem.

  2. Implante a imagem usando o comando kubectl run.

    É preciso implantar a imagem usando o resumo em vez de uma tag, como 1.0 ou latest, já que a autorização binária usa o resumo para procurar attestations.

    Para implantar a imagem, execute o seguinte comando kubectl:

    kubectl run ${POD_NAME} \
        --image ${IMAGE_PATH}@${IMAGE_DIGEST}
    

    Agora verifique se a implantação foi bloqueada pela autorização binária:

    kubectl get pods
    

    Você verá o pod listado.

Fail open

Se o GKE não conseguir acessar o servidor de autorização binária por qualquer motivo ou se o servidor retornar um erro, o GKE não poderá determinar se a autorização binária permitiria ou negaria a imagem. Nesse caso, o GKE falha ao abrir: o padrão é permitir que a imagem seja implantada, mas cria uma entrada de registro nos Registros de auditoria do Cloud para registrar por que a imagem foi permitida.

A aplicação do GKE falha em abrir devido a uma compensação entre confiabilidade e segurança. O GKE envia uma solicitação para a autorização binária sempre que um pod é criado ou atualizado. Isso inclui cenários em que os pods são criados ou atualizados automaticamente por controladores de carga de trabalho do Kubernetes de nível superior, como ReplicaSets e StatefulSets. Se o GKE falhar ao fechar em vez de abrir, qualquer interrupção da autorização binária interromperia a execução desses pods. Além disso, quando os pods são negados, o failover pode levar a falhas em cascata, porque o tráfego redirecionado sobrecarrega os pods que ainda estão em execução. Qualquer interrupção da autorização binária pode acionar uma interrupção completa no cluster, mesmo sem implantar novas imagens.

Implantar imagens que violam a política

A autorização binária é compatível com um recurso conhecido como implantação forçada que permite que uma imagem seja implantada mesmo que ela viole a política.

Para mais informações, consulte Como usar a implantação forçada.

Limpar

Para fazer a limpeza, exclua o pod executando o seguinte comando:

  kubectl delete pod ${POD_NAME}
  

A seguir