Implantar em um cluster do Google Kubernetes Engine

Neste documento, descrevemos como implantar aplicativos nos clusters do Google Kubernetes Engine.

O Cloud Deploy permite implantar cargas de trabalho baseadas em contêiner em qualquer cluster do Google Kubernetes Engine. Todos os recursos do Cloud Deploy são compatíveis quando você implanta em destinos do GKE.

Antes de começar

Neste arquivo skaffold.yaml, a estrofe deploy inclui kubectl, que indica que o Skaffold está renderizando e implantando no Kubernetes (GKE). Os manifestos que você usa para esse aplicativo estão listados lá.

Crie a configuração de destino

Cada destino pode ser configurado no YAML do pipeline de entrega ou pode estar em um arquivo separado. Além disso, é possível configurar mais de um destino no mesmo arquivo, mas eles precisam estar em estrofes de kind: Target diferentes.

Na definição do destino, crie uma estrofe gke para apontar para o cluster do GKE:

A sintaxe para especificar um cluster do GKE é a seguinte:

gke:
 cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]

Esse identificador de recurso do GKE usa os seguintes elementos:

  • [project_name] é o nome do projeto do Google Cloud em que você está executando esse cluster.

    O cluster em que você está implantando não precisa estar no mesmo projeto que o pipeline de entrega.

  • [location] é a região em que o cluster foi criado.

  • [cluster_name] é o nome dado ao cluster quando ele foi criado.

    Esse nome está na lista de clusters do seu projeto, no console do Google Cloud.

    lista de clusters no console do Google Cloud

Veja a seguir um exemplo de configuração de destino, que aponta para um cluster do GKE:

      apiVersion: deploy.cloud.google.com/v1
      kind: Target
      metadata:
       name: dev
      description: development cluster
      gke:
       cluster: projects/my-app/locations/us-central1/clusters/my-app-dev-cluster

Criar a configuração do Skaffold

Nesta seção, você verá um exemplo de configuração simples do Skaffold para usar ao implantar em um cluster do GKE.

Veja a seguir um arquivo skaffold.yaml de exemplo para implantação em um cluster do GKE:

apiVersion: skaffold/v4beta7
kind: Config
metadata: 
  name: gke-application
manifests:
  rawYaml:
  - deployment.yaml
deploy:
  kubectl: {}

O artigo Como usar o Skaffold com o Cloud Deploy descreve em mais detalhes como usar o Skaffold com o pipeline de entrega.

Preparar manifestos do Kubernetes

Para implantar o aplicativo no GKE, forneça ao Cloud Deploy um ou mais manifestos do Kubernetes, que são renderizados e aplicados aos clusters de destino para implantar o aplicativo.

Se você não tiver esses manifestos, crie-os antes de tentar implantar usando um pipeline de entrega do Cloud Deploy.

Você pode usar Kustomize ou Helm para ajudar a criar manifestos. Você também poderá usar o Kustomize ou o Helm se os manifestos forem criados a partir de um modelo e precisarem ser renderizados.

Como tudo funciona em conjunto

Agora que você tem os manifestos do Kubernetes, a configuração skaffold.yaml e as definições de destino do Cloud Deploy e registrou os destinos como recursos do Cloud Deploy, é possível invocar o pipeline de entrega para criar uma versão e avançar na progressão de destinos definidos no pipeline.

Implantar usando um proxy

É possível especificar um proxy para o cluster de destino do GKE. Isso é para organizações configuradas para acessar os clusters somente por meio de um proxy.

Para isso, adicione uma propriedade proxyUrl à estrofe gke na configuração de destino:

gke:
 cluster: projects/my-app/locations/us-central1/clusters/my-app-dev-cluster
 proxyUrl: [URL]

Em que URL é o URL do proxy.

Implantar em um cluster particular

É possível implantar seu aplicativo em um cluster particular do GKE usando uma destas duas opções:

Usar uma rede de nuvem privada virtual

É possível configurar um destino para implantar em um cluster particular do GKE conectado a uma rede da nuvem privada virtual:

  1. Crie seu cluster particular

    Trata-se de um cluster nativo de VPC em que os nós e os pods são isolados por padrão da Internet pública.

    Se você planeja usar o IP interno do destino do cluster particular, defina internalIp como true em gke na configuração de destino.

  2. No Cloud Build, crie um pool de workers particulares que possa ser usado para implantar nesse cluster particular.

  3. Configure o ambiente de execução para usar esse pool privado.

    Use este pool para RENDER. Também é possível usá-lo para DEPLOY e VERIFY. Veja um exemplo que usa RENDER e DEPLOY:

    executionConfigs:
    - usages:
      - RENDER
      - DEPLOY
      workerPool: "projects/p123/locations/us-central1/workerPools/wp123"
    

Para mais informações, consulte Como acessar clusters particulares do GKE de pools particulares do Cloud Build usando o Identity Service para GKE e Acessar clusters particulares do GKE com os pools particulares do Cloud Build.

Considerações sobre projetos e permissões

É possível configurar um destino para usar um pool de workers privados que pode ser implantado em um cluster particular. Mas é preciso observar algumas coisas se os recursos estiverem em projetos diferentes.

  • Quando o Cloud Deploy e o pool de workers estão em projetos separados

Para se comunicar com um pool particular que tenha acesso a uma VPC e que esteja em um projeto diferente do destino, o agente de serviço do Cloud Deploy precisa de permissões suficientes para se comunicar com esse projeto.

A conta de serviço de execução também precisa de permissões para acessar o bucket do Cloud Storage.

  • Quando o pool de workers e o cluster estão em projetos separados

Se o cluster particular do GKE estiver em um projeto diferente do pool de workers particulares, a conta de serviço de execução exigirá permissões suficientes para se comunicar com o projeto em que o cluster está.

Usar destinos do GKE Enterprise e conectar gateway

É possível configurar um destino para implantar em um cluster particular do GKE usando destinos do Anthos e conectar o gateway.

Essa abordagem não requer o uso de uma nuvem privada virtual ou conexões de rede privada virtual.

A seguir