Como configurar um disco de inicialização personalizado

Veja nesta página como personalizar um disco de inicialização de nós nos clusters e pools do Google Kubernetes Engine (GKE).

Visão geral

Quando você cria um cluster do GKE ou um pool de nós, é possível escolher o tipo de Persistent Disk em que os sistemas de arquivos de nós do Kubernetes ficam instalados para cada nó. Por padrão, o GKE usa discos permanentes equilibrados na versão 1.24 ou posterior. Também é possível especificar outros tipos de Persistent Disk, como padrão ou SSD. Para mais informações, consulte Opções de armazenamento.

Os discos permanentes equilibrados e SSD têm cotas de disco diferentes das cotas de disco permanente padrão. Se você estiver mudando de discos permanentes padrão para equilibrados, precisará solicitar aumentos de cotas. Para mais informações, consulte Cotas de recurso.

Benefícios do uso de um disco SSD de inicialização

Usar um disco permanente SSD como um disco de inicialização para seus nós oferece alguns benefícios de desempenho:

• Os nós têm tempos de inicialização mais rápidos.
• Binários e arquivos disponibilizados de contêineres estão disponíveis para o nó mais rapidamente. Isso pode aumentar o desempenho das cargas de trabalho com muito tráfego de E/S, como aplicativos de exibição da Web que hospedam arquivos estáticos ou jobs em lote de curta execução com muito tráfego de E/S.
• Os arquivos armazenados na mídia local do nó (expostos por meio de volumes hostPath ou emptyDir) podem apresentar um desempenho melhor de I/O.

Como especificar um tipo de disco de inicialização de nós

É possível especificar o tipo de disco de inicialização ao criar um cluster ou um pool de nós.

gcloud container clusters create [CLUSTER_NAME] --disk-type [DISK_TYPE]

gcloud container node-pools create [POOL_NAME] --disk-type [DISK_TYPE]

gcloud container clusters create example-cluster --disk-type pd-ssd

Como proteger os discos de inicialização de nós

Um disco de inicialização de nós armazena a imagem do contêiner, alguns registros de processos do sistema, registros de pods e a camada de contêineres graváveis por padrão.

Se as cargas de trabalho usarem os volumes configMap, emptyDir ou hostPath, seus pods poderão gravar mais dados nos discos de inicialização de nós. Para interromper essa ação, configure emptyDir para ter suporte de tmpfs. Para saber como fazer isso, consulte a documentação do Kubernetes. Como os volumes secret, downwardAPI e projected têm o suporte de tmpfs, os pods que os utilizam não gravam dados no disco de inicialização de nós.

Por padrão, o Google Cloud criptografa o conteúdo do cliente em repouso, incluindo os discos de inicialização de nós, e o GGE gerencia a criptografia sem que você precise realizar nenhuma ação.

No entanto, ao usar volumes que gravam no disco de inicialização de nós, é possível ter um controle ainda melhor da proteção dos dados de carga de trabalho no GKE. Para fazer isso, impeça que os pods gravem nos discos de inicialização de nós ou use as chaves de criptografia gerenciadas pelo cliente (CMEKs) nos discos de inicialização de nós.

Impedir que os pods gravem em discos de inicialização

Para impedir que os pods gravem dados diretamente no disco de inicialização de nós, use um dos métodos a seguir.

Policy Controller

O Controlador de Políticas é um recurso do GKE Enterprise que permite declarar e aplicar políticas personalizadas em escala nos clusters do GKE nas frotas.

1. Instale o Controlador de Políticas.
2. Defina uma restrição que restrinja os tipos de volume a seguir usando o modelo de restrição k8sPspVolumeTypes:
   • configMap
   • emptyDir (se não houver suporte de tmpfs)
   • hostPath Para instruções, consulte Usar a biblioteca de modelos de restrição na documentação do Controlador de Políticas.

O exemplo de restrição a seguir restringe esses tipos de volume em todos os pods no cluster:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPVolumeTypes
metadata:
  name: deny-boot-disk-writes
spec:
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]
  parameters:
    volumes:
    - configMap
    - emptyDir
    - hostPath

Controlador de admissão do PodSecurity

O controlador de admissão integrado do PodSecurity do Kubernetes permite aplicar diferentes níveis dos padrões de segurança do pod em namespaces específicos ou no cluster. A política restrita impede que os pods gravem no disco de inicialização do nó.

Para usar o controlador de admissão do PodSecurity, consulte Aplicar políticas de segurança predefinidas no nível do pod usando o PodSecurity.

Criptografia gerenciada pelo cliente

Se você quiser controlar e gerenciar a rotação de chave de criptografia, opte pelas CMEKs. Elas são usadas para criptografar as chaves que criptografam seus dados. Para saber como utilizá-las em discos de inicialização de nós, consulte Como usar chaves de criptografia gerenciadas pelo cliente.

Uma limitação de CMEK para discos de inicialização de nós é que eles não podem ser alterados após a criação do pool de nós. Isso significa que:

• Se o pool de nós tiver sido criado com criptografia gerenciada pelo cliente, não será possível desativar a criptografia nos discos de inicialização.
• Se o pool de nós tiver sido criado sem criptografia gerenciada pelo cliente, não será possível ativar a criptografia nos discos de inicialização. No entanto, é possível criar um novo pool de nós com a criptografia gerenciada pelo cliente ativada e excluir o pool de nós anterior.

Limitações

Antes de configurar um disco de inicialização personalizado, considere as seguintes limitações:

• A série de máquina C3 e a série de máquina G2 não são compatíveis com o tipo de disco de inicialização de nós pd-standard.

A seguir

• Saiba como especificar uma plataforma mínima de CPU.
• Saiba mais sobre criptografia gerenciada pelo cliente
• Saiba mais sobre como usar chaves de criptografia gerenciadas pelo cliente no GKE