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êineres em um cluster do Kubernetes isolado fisicamente do Google Distributed Cloud (GDC). O GDC oferece um serviço gerenciado do Kubernetes que é compatível com aplicativos de contêineres nativos do Kubernetes, amplamente consumidos e compatíveis com o 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 da documentação do GDC com isolamento físico.

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 de 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

As 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 os seguintes:

  • A quantidade de pods para executar o 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 fornece armazenamento em blocos persistente por meio de 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 recursos de armazenamento e de rede compartilhados. 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 o objeto StorageClass pré-instalado standard-rwo. O objeto standard-rwo é uma classe de armazenamento em blocos ReadWriteOnce (RWO) que permite que um volume acesse apenas um nó por vez.

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