Visão geral de como implantar cargas de trabalho

Se quiser implantar e gerenciar seus aplicativos em contêiner e outras cargas de trabalho em clusters do Google Kubernetes Engine (GKE), use o sistema Kubernetes para criar objetos do controlador. Esses objetos representam os aplicativos, daemons e jobs em lote em execução nos clusters.

Para criar esses objetos de controlador, use a API Kubernetes ou a kubectl, uma interface de linha de comando para o Kubernetes instalada pela gcloud. Normalmente, você cria uma representação do objeto de controlador pretendido do Kubernetes como um arquivo de configuração YAML e usa esse arquivo com a API Kubernetes ou a interface de linha de comando kubectl.

Tipos de cargas de trabalho

O Kubernetes oferece diferentes tipos de objetos de controlador que correspondem a diferentes tipos de cargas de trabalho que é possível executar. Certos objetos de controlador são mais adequados para representar tipos específicos de cargas de trabalho. Nas seções a seguir, descrevemos alguns tipos comuns de cargas de trabalho e os objetos de controlador do Kubernetes que é possível criar para executar no cluster. Veja alguns deles:

  • Aplicativos sem estado
  • Aplicativos com estado
  • Jobs em lote
  • Daemons

Aplicativos sem estado

Um aplicativo sem estado não preserva o próprio estado e não salva dados no armazenamento permanente. Todos os dados do usuário e da sessão permanecem com o cliente.

Alguns exemplos de aplicativos sem estado incluem front-ends da Web como o Nginx, servidores da Web como o Apache Tomcat (links em inglês) e outros aplicativos da Web.

É possível criar uma Implantação do Kubernetes para implantar um aplicativo sem estado no cluster. Os pods criados por implantações não são exclusivos e não preservam o estado, o que facilita o escalonamento e a atualização de aplicativos sem estado.

Aplicativos com estado

Um aplicativo com estado exige que o estado seja salvo ou permanente. Esses aplicativos usam armazenamento permanente, como volumes permanentes, para salvar dados para uso do servidor ou de outros usuários.

Exemplos de aplicativos com estado incluem bancos de dados como o MongoDB e filas de mensagens como o Apache ZooKeeper (links em inglês).

É possível criar um StatefulSet do Kubernetes para implantar um aplicativo com estado. Os pods criados pelo StatefulSets têm identificadores exclusivos e podem ser atualizados de maneira segura e ordenada.

Jobs em lote

Os jobs em lote representam tarefas finitas, independentes e muitas vezes paralelas que são executadas até a conclusão. Alguns exemplos de jobs em lote incluem tarefas automáticas ou agendadas, como enviar e-mails, renderizar vídeos e executar cálculos exorbitantes.

É possível criar um job do Kubernetes para executar e gerenciar uma tarefa em lote no cluster. É possível especificar o número de pods que precisam completar as tarefas antes da conclusão do job, bem como o número máximo de pods que precisam ser executados em paralelo.

Daemons

Com os daemons, é possível executar tarefas em segundo plano nos nodes atribuídos sem a necessidade de intervenção do usuário. Exemplos de daemons incluem coletores de registros como o Fluentd (em inglês) e serviços de monitoramento.

É possível criar um DaemonSet do Kubernetes para implantar um daemon no cluster. O DaemonSets cria um pod por node, e é possível escolher um nó específico em que o DaemonSet fará a implantação.

DaemonSets no Autopilot do GKE

O GKE administra os nós nos clusters criados usando o modo de operação Autopilot (em inglês). Não é possível adicionar, remover ou modificar manualmente os nós ou as máquinas virtuais (VMs) subjacentes do Compute Engine. No entanto, o objeto de nó do Kubernetes ainda está visível, e o Autopilot é compatível com DaemonSets como suas cargas de trabalho.

O Autopilot do GKE limita algumas funções administrativas que afetam todos os pods de carga de trabalho, incluindo pods gerenciados por DaemonSets. Os DaemonSets que executam funções administrativas em nós que usam privilégios elevados, como o contexto de segurança privileged, não serão executados em clusters do Autopilot, a menos que explicitamente permitido pelo GKE.

Para mais informações sobre os limites aplicados pelo Autopilot, consulte Limitações e restrições de carga de trabalho. É possível usar DaemonSets com cargas de trabalho que atendam às restrições definidas pelo Autopilot, bem como DaemonSets de alguns parceiros do Google Cloud.

Práticas recomendadas para DaemonSets no piloto automático

O GKE usa o tamanho total das cargas de trabalho implantadas para determinar o tamanho dos nós que o Autopilot provisiona para o cluster. Se você adicionar ou redimensionar um DaemonSet depois que o Autopilot provisionar um nó, o GKE não redimensionará os nós existentes para acomodar o novo tamanho total da carga de trabalho. DaemonSets com solicitações de recursos maiores que a capacidade alocável de nós atuais após a contagem de pods do sistema também não serão programados nesses nós.

A partir da versão 1.27.6-gke.1248000 do GKE, os clusters no modo Autopilot detectam nós que não podem caber em todos os DaemonSets e, com o tempo, migram cargas de trabalho para nós maiores que possam se adequar a todos os DaemonSets. Esse processo leva algum tempo, especialmente se os nós executarem pods do sistema, que precisam de mais tempo para serem encerrados. Dessa forma, não há interrupção nos recursos principais do cluster.

Na versão 1.27.5-gke.200 ou anterior do GKE, recomendamos restringir e reduzir nós que não podem acomodar pods de DaemonSet.

Para todas as versões do GKE, recomendamos as seguintes práticas ao implantar DaemonSets no Autopilot:

  • Implante DaemonSets antes de qualquer outra carga de trabalho.
  • Defina um PriorityClass mais alto em DaemonSets do que os pods regulares. A prioridade mais alta permite que o GKE remova pods de prioridade mais baixa para acomodar pods de DaemonSet se o nó puder acomodar esses pods. Isso ajuda a garantir que o DaemonSet esteja presente em cada nó sem acionar a recriação do nó.

Como gerenciar objetos de carga de trabalho

Use métodos imperativos e declarativos para criar, gerenciar e excluir objetos. Nas seções a seguir, descrevemos esses métodos e as ferramentas que podem ser usadas para empregá-los:

Comandos imperativos

Com os comandos imperativos (em inglês), você cria, visualiza, atualiza e exclui objetos rapidamente com a kubectl. Esses comandos são úteis para tarefas únicas ou para fazer alterações em objetos ativos em um cluster. Os comandos imperativos normalmente são usados para realizar operações em objetos implantados ativos no cluster.

A kubectl apresenta vários comandos orientados por verbo para criar e editar objetos do Kubernetes. Exemplo:

  • run (em inglês): gera um novo objeto no cluster. A menos que seja especificado de outra forma, run cria um objeto de implantação. run também aceita vários outros geradores (em inglês).
  • expose (em inglês): cria um novo objeto Service para balancear a carga de tráfego em um conjunto de pods rotulados.
  • autoscale (em inglês): cria um novo objeto Autoscaler para realizar o escalonamento horizontal automático em um objeto controller, como uma implantação.

Os comandos imperativos não exigem arquivos de configuração nem uma compreensão profunda do esquema de objeto.

Configuração imperativa de objetos

Com a configuração imperativa de objetos (em inglês), você cria, atualiza e exclui objetos usando arquivos de configuração que contêm definições de objeto totalmente especificadas. É possível armazenar arquivos de configuração de objetos em sistemas de controle de origem e auditar alterações mais facilmente do que com comandos imperativos.

Execute operações kubectl apply, delete e replace (todos em inglês) com arquivos de configuração ou diretórios contendo arquivos de configuração.

Configuração declarativa de objetos

Com a configuração declarativa de objetos, é possível realizar a operação em arquivos de configuração armazenados localmente sem precisar da definição explícita das operações a serem executadas. Em vez disso, as operações são detectadas automaticamente por objeto pela kubectl. Isso é útil se você estiver trabalhando com um diretório de arquivos de configuração com muitas operações diferentes. O gerenciamento declarativo de objetos exige uma compreensão profunda dos arquivos de configuração e esquemas de objetos.

Para criar e atualizar objetos declarativamente, execute kubectl apply (em inglês). apply lê todo o objeto ativo e calcula e combina as diferenças enviando solicitações de patch ao servidor da API para atualizar objetos.

Imagens públicas do Docker Hub

Quando você implanta uma imagem de contêiner pública do Docker Hub, o GKE verifica automaticamente se há uma cópia em cache da imagem de contêiner no proxy de armazenamento em cache mirror.gcr.io. Se uma cópia em cache não estiver disponível, o GKE extrairá a imagem solicitada do Docker Hub e o proxy de armazenamento em cache poderá armazenar a imagem em cache para uso futuro. Para mais informações, consulte Como extrair imagens em cache.

Console

Depois de implantar uma carga de trabalho usando kubectl ou a API, é possível usar o menu Cargas de trabalho do GKE no console do Google Cloud para inspecionar, gerenciar e editar cargas de trabalho em execução nos seus clusters.

O menu oferece estes recursos:

  • Use o editor de texto baseado em YAML para editar objetos ativos do seu navegador da Web.
  • Veja informações detalhadas sobre objetos, incluindo histórico de revisão, eventos e atividades recentes e os respectivos pods gerenciados.
  • Escalone implantações, jobs e StatefulSets com facilidade.
  • Faça escalonamento automático, acione atualizações contínuas e escalone implantações manualmente no menu Ações.
  • Use o Cloud Shell para inspecionar, editar e excluir qualquer objeto.

API

Para criar e gerenciar cargas de trabalho de maneira programática, use a API REST do GKE e a API Kubernetes (em inglês) com as bibliotecas de cliente do Google Cloud.

Arquivos de configuração

Quando você implanta uma carga de trabalho usando qualquer um dos métodos descritos anteriormente, o GKE adiciona um arquivo de configuração ao cluster que representa o objeto.

A configuração ativa de um objeto pode ser diferente do arquivo local. O YAML costuma ser usado para criar e representar objetos do Kubernetes, mas também é possível usar o JSON (links em inglês).

Para saber mais sobre as especificações de objetos do Kubernetes, os status e a API Kubernetes, consulte Noções básicas de objetos do Kubernetes e a referência da API Kubernetes (ambos em inglês).

Como inspecionar configurações em tempo real

Console

Para inspecionar a configuração ativa de um objeto implantado, execute as etapas a seguir:

  1. Acesse a página Cargas de trabalho no console do Google Cloud.

    Acesse "Cargas de trabalho"

  2. Selecione a carga de trabalho desejada.

  3. Clique em YAML.

gcloud

Para inspecionar a configuração ativa de um objeto implantado, execute o comando abaixo:

kubectl get [OBJECT_TYPE] [OBJECT_NAME] -o yaml

[OBJECT_TYPE] pode ser deployment, statefulset, job ou outro tipo de objeto. Exemplo:

kubectl get deployment my-stateless-app -o yaml

Como gerenciar o uso de recursos com cotas

Quando muitos usuários ou equipes compartilham os recursos no cluster, há a preocupação de que alguns possam usar mais do que o compartilhamento justo. Use o objeto ResourceQuota do Kubernetes para limitar o consumo de recursos em namespaces específicos.

O GKE também aplica um objeto gke-resource-quotas imutável padrão a namespaces em clusters com 100 nós ou menos para evitar instabilidade.

Usar o GitLab para implantar no GKE

Se você usa o GitLab para integração contínua, é possível utilizar o componente GitLab GKE (em inglês) para implantar a carga de trabalho em um cluster do GKE.

Você também pode testar o tutorial completo para usar o GitLab com o Google Cloud.

Para mais informações, acesse a visão geral do GitLab no Google Cloud.

A seguir