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 ar do Google Distributed Cloud (GDC). O GDC oferece um serviço 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 por gerir cargas de trabalho de aplicações para a respetiva organização. Para mais informações, consulte a documentação sobre públicos-alvo para GDC com isolamento de ar.

Aplicações Kubernetes para um ambiente desligado

O GKE no GDC é um serviço 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, tal 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 clusters Kubernetes do GDC, consulte a vista geral do cluster Kubernetes. Para mais informações sobre os principais conceitos do Kubernetes, consulte a documentação do GKE para Começar a saber mais sobre o Kubernetes.

Estado da carga de trabalho do contentor

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

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

O Kubernetes oferece vários recursos de carga de trabalho incorporados para alcançar o estado da aplicação de contentor preferido. Para mais informações, consulte a documentação sobre as 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 alternativa, 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 front-end pode ser sem estado: implementa várias réplicas para aumentar a respetiva disponibilidade e reduzir a escala quando a procura é baixa, e as réplicas não precisam de identidades únicas.

O Kubernetes usa o recurso Deployment para implementar aplicações sem estado como pods uniformes e não exclusivos. As implementações gerem o estado pretendido 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 pretendido dinamicamente através de atualizações à especificação do DeploymentrecursoPod.

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 em disco persistente para utilização 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 chave/valor no qual os dados são guardados e obtidos por outras aplicações. Tem de aprovisionar armazenamento persistente para a sua aplicação com estado usar.

O Kubernetes usa o recurso StatefulSet para implementar aplicações com estado. Os agrupamentos nos recursos StatefulSet não são intercambiáveis: cada agrupamento tem um identificador exclusivo que é mantido independentemente do local 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 de objetos PersistentVolumeClaim (PVC). 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 para além de um único Pod.

Pode aprovisionar dinamicamente armazenamento persistente para as suas cargas de trabalho com estado, de modo que os volumes subjacentes sejam criados a pedido. No GDC, configura o aprovisionamento dinâmico criando um dos seguintes objetos StorageClass pré-instalados:

  • standard-rwo: a classe de armazenamento de blocos ReadWriteOnce (RWO). Só é possível aceder ao volume através de um nó de cada vez. Esta classe de armazenamento inclui uma garantia de operações de entrada/saída por segundo (IOPS) e um limite de 3 IOPS por GiB.

  • system-performance-rwo: a classe de armazenamento de blocos de desempenho ReadWriteOnce. Esta classe de armazenamento é uma versão com melhor desempenho do armazenamento RWO que inclui uma garantia de IOPS e um limite de 30 IOPS por GiB.

Também pode criar um objeto VolumeSnapshot 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 da base de dados pode criar uma captura instantânea do 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?