Esta página mostra como personalizar um disco de arranque de nó nos seus clusters e node pools do Google Kubernetes Engine (GKE).
Vista geral
Quando cria um cluster ou um conjunto de nós do GKE, pode escolher o tipo de disco persistente no qual o sistema de ficheiros do nó do Kubernetes é instalado para cada nó. Por predefinição, o GKE usa discos persistentes equilibrados na versão 1.24 ou posterior. Também pode especificar outros tipos de discos persistentes, como o padrão ou o SSD. Para mais informações, consulte as Opções de armazenamento.
Os discos persistentes equilibrados e SSD têm quotas de disco diferentes das quotas de disco persistente padrão. Se estiver a mudar de discos persistentes padrão para discos persistentes equilibrados, pode ter de pedir aumentos de quota. Para mais informações, consulte o artigo Quotas de recursos.
Vantagens da utilização de um disco de arranque SSD
A utilização de um disco persistente SSD como disco de arranque para os seus nós oferece algumas vantagens de desempenho:
- Os nós têm tempos de arranque mais rápidos.
- Os ficheiros binários e os ficheiros publicados a partir de contentores estão disponíveis para o nó mais rapidamente. Isto pode aumentar o desempenho para cargas de trabalho com utilização intensiva de E/S, como aplicações de serviço Web que alojam ficheiros estáticos ou tarefas em lote com utilização intensiva de E/S de curta duração.
- Os ficheiros armazenados nos suportes locais do nó (expostos através de volumes
hostPath
ouemptyDir
) podem ter um desempenho de E/S melhorado.
Especificar um tipo de disco de arranque do nó
Pode especificar o tipo de disco de arranque quando cria um cluster ou um conjunto de nós.
gcloud
Para criar um cluster com um disco de arranque personalizado, execute o seguinte comando.
[DISK-TYPE]
pode ter um dos seguintes valores:
pd-balanced
(a predefinição na versão 1.24 ou posterior)pd-standard
(a predefinição na versão 1.23 ou anterior)pd-ssd
hyperdisk-balanced
Para mais informações, consulte o artigo Tipos de discos persistentes.
gcloud container clusters create [CLUSTER_NAME] --disk-type [DISK_TYPE]
Para criar um node pool num cluster existente:
gcloud container node-pools create [POOL_NAME] --disk-type [DISK_TYPE]
Por exemplo, o seguinte comando cria um cluster example-cluster
,
com o tipo de disco persistente SSDpd-ssd
:
gcloud container clusters create example-cluster --disk-type pd-ssd
Consola
Para selecionar o disco de arranque quando cria o cluster com a Google Cloud consola:
Na Google Cloud consola, aceda à página Criar um cluster do Kubernetes.
Configure o cluster conforme necessário.
No menu de navegação, expanda default-pool e clique em Nodes.
Na lista pendente Tipo de disco de arranque, selecione um tipo de disco persistente.
Clique em Criar.
Para criar um pool de nós com um disco de arranque personalizado para um cluster existente:
Aceda à página do Google Kubernetes Engine na Google Cloud consola.
Na lista de clusters, clique no nome do cluster que quer modificar.
Clique em add_box Adicionar conjunto de nós.
Configure o seu conjunto de nós conforme necessário.
No menu de navegação, clique em Nodes.
Na lista pendente Tipo de disco de arranque, selecione um tipo de disco persistente.
Clique em Criar.
Proteger discos de arranque de nós
Por predefinição, um disco de arranque do nó armazena a sua imagem de contentor, alguns registos de processos do sistema, registos de pods e a camada de contentor gravável.
Se as suas cargas de trabalho usarem volumes configMap
, emptyDir
ou hostPath
, os seus pods podem escrever dados adicionais em discos de arranque de nós. Pode configurar o emptyDir
para ter o apoio do tmpfs para impedir esta situação. Para saber como, consulte a
documentação do Kubernetes.
Uma vez que os volumes secret
, downwardAPI
e projected
são suportados por tmpfs, os pods que os usam não escrevem dados no disco de arranque do nó.
Por predefinição,o GKE Google Cloud encripta o conteúdo do cliente enquanto inativo incluindo os discos de arranque dos nós, e gere a encriptação por si sem que tenha de fazer nada.
No entanto, quando usar volumes que escrevem no disco de arranque do nó, pode querer controlar ainda mais a forma como os dados da carga de trabalho são protegidos no GKE. Pode fazê-lo impedindo que os pods escrevam em discos de arranque de nós ou usando chaves de encriptação geridas pelo cliente (CMEK) para discos de arranque de nós.
Impeça que os pods escrevam em discos de arranque
Para impedir que os pods escrevam dados diretamente no disco de arranque do nó, use um dos seguintes métodos.
Controlador de políticas
O Policy Controller é uma funcionalidade do GKE Enterprise que lhe permite declarar e aplicar políticas personalizadas em grande escala nos seus clusters do GKE em frotas.
- Instale o Policy Controller.
- Defina uma restrição que restrinja os seguintes tipos de volumes através do modelo de restrição
k8sPspVolumeTypes
:configMap
emptyDir
(se não tiver o apoio do tmpfs)hostPath
Para obter instruções, consulte o artigo Use a biblioteca de modelos de restrições na documentação do Policy Controller.
A restrição de exemplo seguinte restringe estes tipos de volumes 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 PodSecurity
O controlador de admissão PodSecurity do Kubernetes integrado permite-lhe aplicar diferentes níveis das normas de segurança de pods em espaços de nomes específicos ou no cluster. A política restrita impede que os pods escrevam no disco de arranque do nó.
Para usar o controlador de admissão PodSecurity, consulte o artigo Aplique políticas de segurança predefinidas ao nível do pod com o PodSecurity.
Encriptação gerida pelo cliente
Se quiser controlar e gerir a rotação das chaves de encriptação de forma autónoma, pode usar as chaves de encriptação geridas pelo cliente (CMEK). Estas chaves são usadas para encriptar as chaves de encriptação de dados que encriptam os seus dados. Para saber como usar as CMEK para discos de arranque de nós, consulte o artigo Usar chaves de encriptação geridas pelo cliente.
Uma limitação da CMEK para discos de arranque de nós é que não pode ser alterada após a criação do conjunto de nós. Isto significa que:
- Se o conjunto de nós foi criado com a encriptação gerida pelo cliente, não pode desativar posteriormente a encriptação nos discos de arranque.
- Se o conjunto de nós foi criado sem encriptação gerida pelo cliente, não pode ativar posteriormente a encriptação nos discos de arranque. No entanto, pode criar um novo conjunto de nós com a encriptação gerida pelo cliente ativada e eliminar o conjunto de nós anterior.
Limitações
Antes de configurar um disco de arranque personalizado, considere as seguintes limitações:
- A série de máquinas C3
e a série de máquinas G2
não suportam o tipo de disco de arranque do nó
pd-standard
.
O que se segue?
- Saiba como especificar uma plataforma de CPU mínima.
- Saiba mais sobre a encriptação gerida pelo cliente.
- Saiba como usar chaves de encriptação geridas pelo cliente no GKE.