Cargas de trabalho de contêiner no GDC

Esta página de visão geral explica o modelo operacional para cargas de trabalho de contêiner em um cluster do Kubernetes isolado do Google Distributed Cloud (GDC). O GDC oferece um serviço gerenciado do Kubernetes compatível com aplicativos de contêineres nativos do Kubernetes, que são amplamente consumidos e aceitos no Google Kubernetes Engine (GKE).

Esta página é destinada a desenvolvedores do grupo de operadores de aplicativos, que são responsáveis por gerenciar cargas de trabalho de aplicativos na organização. Para mais informações, consulte Públicos-alvo para documentação isolada do GDC.

Aplicativos do Kubernetes para um ambiente desconectado

O GKE no GDC é um serviço gerenciado do Kubernetes que incorpora muitos recursos do GKE ao seu universo do GDC por padrão. Esse serviço elimina a necessidade de instalar, fazer upgrade, integrar e executar o Kubernetes de código aberto por conta própria. Você pode operar e manter a distribuição do Kubernetes fornecida com uma API KRM padrão, como qualquer outra oferta do Kubernetes declarativa e idempotente. Da mesma forma, o GKE na GDC é oferecido no console da GDC, na CLI gdcloud e no Terraform. Para mais informações sobre clusters do Kubernetes do GDC, consulte a visão geral dos clusters do Kubernetes. Para mais informações sobre os principais conceitos do Kubernetes, consulte a documentação do GKE em Começar a aprender sobre o Kubernetes.

Estado da carga de trabalho do contêiner

Os contêineres no GDC são implantados em clusters do Kubernetes da seguinte forma:

É possível escalonar horizontalmente os nós do cluster do Kubernetes do GDC com base nos requisitos das cargas de trabalho de contêiner, mesmo após o provisionamento do cluster, à medida que os requisitos de computação evoluem.

O Kubernetes oferece vários recursos de carga de trabalho integrados para alcançar o estado de aplicativo de contêiner preferido. Para mais informações, consulte a documentação de workloads do Kubernetes.

Cargas de trabalho sem estado

Cargas de trabalho sem estado são aplicativos que não armazenam dados ou o estado do aplicativo no cluster do Kubernetes ou no armazenamento permanente. Em vez disso, os dados e o estado do aplicativo permanecem no cliente, o que torna os aplicativos sem estado mais escalonáveis. Por exemplo, um aplicativo de front-end pode ser sem estado: você implanta várias réplicas para aumentar a disponibilidade dele e reduzir escala vertical quando a demanda é baixa, e as réplicas não precisam de identidades exclusivas.

O Kubernetes usa o recurso Deployment para implantar aplicativos sem estado como pods uniformes e não exclusivos. As implantações gerenciam o estado pretendido do aplicativo, como:

  • A quantidade de pods para executar seu aplicativo.
  • A versão da imagem do contêiner a ser executada.
  • Os rótulos dos pods.

É possível mudar o estado desejado dinamicamente por meio de atualizações na especificação Pod do recurso Deployment.

Os aplicativos sem estado são diferentes das cargas de trabalho com estado, que usam armazenamento permanente para salvar dados e o estado do aplicativo.

Cargas de trabalho com estado

As cargas de trabalho com estado são aplicativos que salvam dados no armazenamento em disco permanente para uso do servidor, de clientes e de outros aplicativos. Um exemplo de aplicativo com estado é um banco de dados ou armazenamento de chave-valor em que os dados são salvos e recuperados por outros aplicativos. É necessário provisionar armazenamento permanente para o aplicativo com estado usar.

O Kubernetes usa o recurso StatefulSet para implantar aplicativos com estado. Os pods nos recursos StatefulSet não são intercambiáveis: cada pod tem um identificador exclusivo que é mantido, seja qual for o local em que está programado.

Os aplicativos com estado são diferentes das cargas de trabalho sem estado, em que os dados do cliente não são salvos no servidor entre as sessões.

Armazenamento permanente para contêineres

O GDC oferece armazenamento permanente de blocos e arquivos usando objetos PersistentVolumeClaim (PVC). Um PVC é uma solicitação de armazenamento referenciada por um objeto Pod. Um pod é um grupo de um ou mais contêineres com armazenamento compartilhado e recursos de rede. Um PVC tem um ciclo de vida independente do pod, o que permite que ele persista além de um único pod.

É possível provisionar dinamicamente o armazenamento permanente para suas cargas de trabalho com estado para que os volumes subjacentes sejam criados sob demanda. No GDC, configure o provisionamento dinâmico criando um dos seguintes objetos StorageClass pré-instalados:

  • standard-rwo: a classe de armazenamento de blocos ReadWriteOnce (RWO). O volume só pode ser acessado por um nó por vez. Essa classe de armazenamento tem uma garantia e um limite de operações de entrada e saída por segundo (IOPS) de 3 IOPS por GiB.

  • system-performance-rwo: a classe de armazenamento em blocos de desempenho ReadWriteOnce. Essa classe de armazenamento é uma versão mais eficiente do armazenamento RWO que oferece uma garantia de IOPS e um limite de 30 IOPS por GiB.

Também é possível criar um objeto VolumeSnapshot para copiar o volume de armazenamento do aplicativo contêiner em um momento específico sem criar um volume totalmente novo. Por exemplo, um administrador de banco de dados pode criar um snapshot de volume para fazer backup dos bancos de dados antes de realizar edições ou exclusões.

A seguir