Cargas de trabalho de contentores no GDC

Esta página de vista geral explica o modelo de funcionamento das cargas de trabalho de contentores num cluster do Kubernetes isolado do Google Distributed Cloud (GDC). O GDC oferece um serviço do Kubernetes gerido que suporta aplicações de contentores nativas do Kubernetes amplamente consumidas e suportadas no Google Kubernetes Engine (GKE).

Esta página destina-se a programadores no grupo de operadores de aplicações, que são responsáveis pela gestão das cargas de trabalho de aplicações da respetiva organização. Para mais informações, consulte Públicos-alvo para a documentação do GDC isolado.

Aplicações do Kubernetes para um ambiente desligado

O GKE no GDC é um serviço do Kubernetes gerido que incorpora muitas funcionalidades do GKE no seu universo do GDC por predefinição. Este serviço elimina a necessidade de instalar, atualizar, integrar e executar o Kubernetes de código aberto por si. 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 no GDC é oferecido a partir da consola do GDC, da CLI gdcloud e do Terraform. Para mais informações sobre os clusters do Kubernetes do GDC, consulte a vista geral dos clusters do Kubernetes. Para mais informações sobre os principais conceitos do Kubernetes, consulte a documentação do GKE em Comece a aprender sobre o Kubernetes.

Estado da carga de trabalho de contentores

Os contentores no GDC são implementados em clusters do Kubernetes da seguinte forma:

Pode aumentar horizontalmente os nós do cluster do Kubernetes do GDC com base nos requisitos das cargas de trabalho de contentores, mesmo após o aprovisionamento do cluster, à medida que os requisitos de computação evoluem.

O Kubernetes oferece vários recursos de cargas de trabalho incorporados para alcançar o estado da aplicação de contentores preferido. Para mais informações, consulte a documentação sobre cargas de trabalho do Kubernetes .

Cargas de trabalho sem estado

As cargas de trabalho sem estado são aplicações que não armazenam dados nem o estado da aplicação no cluster do Kubernetes ou no armazenamento persistente. Em vez disso, os dados e o estado da aplicação permanecem com o cliente, o que torna as aplicações sem estado mais escaláveis. Por exemplo, uma aplicação de frontend pode ser sem estado: implementa várias réplicas para aumentar a respetiva disponibilidade e reduz a escala quando a procura é baixa, e as réplicas não precisam de identidades únicas.

O Kubernetes usa o Deployment recurso para implementar aplicações sem estado como pods uniformes e não únicos Pods. As implementações gerem o estado desejado da sua aplicação, como o seguinte:

  • A quantidade de pods para executar a sua aplicação.
  • A versão da imagem do contentor a executar.
  • As etiquetas dos pods.

Pode alterar o estado desejado dinamicamente através de atualizações à especificação do Pod do recurso Deployment.

As aplicações sem estado contrastam com as cargas de trabalho com estado, que usam armazenamento persistente para guardar dados e o estado da aplicação.

Cargas de trabalho com estado

As cargas de trabalho com estado são aplicações que guardam dados no armazenamento de disco persistente para uso pelo servidor, pelos clientes e por outras aplicações. Um exemplo de uma aplicação com estado é uma base de dados ou um armazenamento de valores-chave no qual os dados são guardados e recuperados por outras aplicações. Tem de aprovisionar armazenamento persistente para a sua aplicação com estado usar.

O Kubernetes usa o StatefulSet recurso para implementar aplicações com estado. Os pods nos recursos StatefulSet não são intercambiáveis: cada pod tem um identificador único que é mantido independentemente de onde é agendado.

As aplicações com estado são diferentes das cargas de trabalho sem estado, nas quais os dados do cliente não são guardados no servidor entre sessões.

Armazenamento persistente para contentores

O GDC oferece armazenamento de blocos persistente através PersistentVolumeClaim (PVC) objetos. Um PVC é um pedido de armazenamento referenciado por um objeto Pod. Um pod é um grupo de um ou mais contentores, com armazenamento partilhado e recursos de rede. Um PVC tem um ciclo de vida independente do pod, o que lhe permite persistir além de um único pod.

Pode aprovisionar dinamicamente armazenamento persistente para as cargas de trabalho com estado para que os volumes subjacentes sejam criados a pedido. No GDC, configura o aprovisionamento dinâmico criando o objeto StorageClass pré-instalado standard-rwo. O objeto standard-rwo é uma classe de armazenamento de blocos ReadWriteOnce (RWO) que permite que um volume aceda apenas a um nó de cada vez.

Também pode criar um VolumeSnapshot objeto para copiar o volume de armazenamento da aplicação de contentores num ponto específico no tempo sem criar um volume totalmente novo. Por exemplo, um administrador de bases de dados pode criar uma captura de volume para fazer uma cópia de segurança das bases de dados antes de fazer modificações de edição ou eliminação.

O que se segue?