Imagens de nó

Nesta página, são descritas as imagens de nós disponíveis para o Kubernetes Engine. Para aprender a escolher uma imagem de nó, consulte este artigo.

Visão geral

Quando você cria um pool de nós ou um cluster do GKE, é possível escolher a imagem do sistema operacional que é executada em cada nó. Também pode atualizar um cluster existente para que use um tipo de imagem do nó diferente.

Imagens de nó disponíveis

O GKE oferece as seguintes opções de imagem de nó para o cluster:

Container-Optimized OS

A imagem de nó do Container-Optimized OS é baseada em uma versão recente do kernel do Linux e otimizada para melhorar a segurança do nó. Uma equipe do Google dá o suporte e rapidamente desenvolve as correções de segurança e verifica os recursos. A imagem do Container-Optimized OS oferece melhor suporte, segurança e estabilidade do que as outras.

Container-Optimized OS com containerd (cos_containerd)

O containerd é um importante bloco de construção e o principal componente do ambiente de execução do Docker. cos_containerd é uma variante da imagem do Container-Optimized OS com o containerd como o ambiente de execução do contêiner principal diretamente integrado ao Kubernetes.

Para depurar ou solucionar problemas no nó, interaja com o containerd usando a ferramenta de linha de comando portátil criada para os ambientes de execução do contêiner do Kubernetes: crictl. O crictl é compatível com funcionalidades comuns para visualizar contêineres e imagens, ler registros e executar comandos nos contêineres. Consulte o guia do usuário básico para um conjunto completo de recursos compatíveis e informações de uso.

O cos_containerd requer o Kubernetes versão 1.11.0 ou superior.

Para mais informações, visite Como usar o Container-Optimized OS com containerd.

Ubuntu

A imagem de nó do Ubuntu foi validada em relação aos requisitos de imagem de nó do GKE. Será preciso usar a imagem de nó do Ubuntu se os nós exigirem compatibilidade com os pacotes XFS, CephFS, Sysdig ou Debian.

Comparação de imagens de nó

As seções a seguir comparam os aspectos operacionais das imagens de nó do Container-Optimized OS e do Ubuntu, incluindo:

  • Gerenciamento de pacotes de software
  • inicialização do sistema
  • coleta de registros
  • Layout do sistema de arquivos
  • Compatibilidade com driver de armazenamento

Gerenciador de pacotes de software

As imagens de nó cos e cos_containerd usam um sistema de arquivos raiz mínimo com suporte interno para o ambiente de execução de contêiner do Docker (containerd), que também serve como gerenciador de pacotes de software para instalar software no host. A imagem do Ubuntu usa o gerenciador de pacotes Aptitude.

Como gerenciar software no Container-Optimized OS

Não é possível instalar pacotes de software em um host com a imagem do Container-Optimized OS (ou seja, fora dos contêineres) ou atualizar pacotes de software de maneira independente. No entanto, a imagem do node do Container-Optimized OS inclui algumas ferramentas de depuração comuns e oferece um wrapper toolbox para executar as ferramentas de depuração que você quiser. Veja a seguir alguns exemplos:

sudo toolbox ping www.google.com
sudo toolbox apt-get install psmisc
sudo toolbox pstree -p

Para ver mais exemplos sobre como usar o wrapper na instalação de outro software em um host com a imagem de nó cos, consulte os Guias de instruções do Container-Optimized OS.

Como gerenciar software no Ubuntu

A imagem do Ubuntu tem o gerenciador de pacotes Aptitude pré-instalado. É possível usar o comando apt-get para instalar pacotes nessas imagens. Por exemplo, para instalar pacotes ceph:

sudo apt-get update
sudo apt-get install ceph

Inicialização do sistema

As imagens de nó do Ubuntu e do Container-Optimized OS usam systemd para gerenciar recursos e serviços do sistema durante o processo de inicialização.

As duas imagens de nó usam arquivos de serviço systemd para definir services no nó e systemd.targets para agrupar destinos de inicialização por meio de dependências.

Coleta de registros

As imagens de nó do Ubuntu e do Container-Optimized OS usam systemd-journald para coletar registros de todo o sistema.

Como exibir registros no Container-Optimized OS e no Ubuntu

Para ver registros em um nó com a imagem do Ubuntu ou do Container-Optimized OS, é preciso usar o comando journalctl. Por exemplo, para ver registros do daemon do Docker:

sudo journalctl -u docker

Para ver registros do kubelet:

sudo journalctl -u kubelet

Layout do sistema de arquivos

A imagem de nó do Ubuntu usa o layout padrão do sistema de arquivos do Linux.

O layout do sistema de arquivos de imagem de nó do Container-Optimized OS é otimizado para melhorar a segurança do nó. O espaço do disco de inicialização foi dividido em três tipos de partições:

  • partição raiz, que é montada como somente leitura
  • partições com estado, que podem ser gravadas e têm estado
  • partições sem estado, que podem ser gravadas, mas o conteúdo não permanece durante as reinicializações

Ao usar o Container-Optimized OS, fique atento ao particionamento se você executar serviços próprios com certas expectativas sobre o layout do sistema de arquivos fora dos contêineres.

Como trabalhar com o sistema de arquivos do Container-Optimized OS

Na lista a seguir, mostramos os caminhos no sistema de arquivos de imagem do node do Container-Optimized OS, juntamente com as propriedades e o uso recomendado:

Caminho Propriedades Finalidade
/
  • somente leitura
  • executável
O sistema de arquivos raiz é ativado como somente leitura para manter a integridade. O kernel verifica a integridade do sistema de arquivos raiz durante a inicialização e se recusa a inicializar em caso de erros.
/home
/var
  • gravável
  • não executável
  • com estado
Esses caminhos visam armazenar dados que permanecem durante todo o período do disco de inicialização. Eles são ativados em /mnt/stateful_partition.
/var/lib/google
/var/lib/cloud
/var/lib/docker
/var/lib/kubelet
/var/lib/toolbox
  • gravável
  • executável
  • com estado
Esses caminhos são diretórios de trabalho para pacotes do Compute Engine (por exemplo, serviço de gerente de contas), cloud-init, Docker, Kubelet e Toolbox, respectivamente.
/etc
  • gravável
  • não executável
  • sem estado
  • tmpfs
Em /etc, geralmente é mantida a configuração, por exemplo, os serviços systemd definidos por meio do cloud-init. É recomendável capturar o estado desejado das instâncias no cloud-init. O cloud-init é aplicado quando uma instância é criada do zero e também quando ela é reiniciada.
/tmp
  • gravável
  • não executável
  • sem estado
  • tmpfs
/tmp é normalmente usado como um espaço de rascunho. Não o use para armazenar dados persistentes.
/mnt/disks
  • gravável
  • executável
  • sem estado
  • tmpfs
É possível ativar discos permanentes nos diretórios em /mnt/disks.

Compatibilidade com driver de armazenamento

Cada imagem do node difere nos tipos de plug-ins de armazenamento com os quais é compatível. Os termos a seguir são usados para descrever a compatibilidade de uma imagem do node com determinado driver de armazenamento:

  • sim - teste/suporte total: este plug-in de armazenamento tem suporte total e foi completamente testado com a imagem de nó especificada.
  • Sim — teste limitado: este plug-in de armazenamento funciona com a imagem de nó especificada, mas foi testado apenas de maneira limitada. Talvez haja algum comportamento inesperado. Para o Container-Optimized OS, esses plugins serão testados e totalmente compatíveis.
  • Não compatível: este plug-in de armazenamento não foi testado nem usado com a imagem de nó especificada, e o GKE não oferece nenhuma garantia de funcionalidade. Não há planos de testá-lo.
  • Não: este plug-in de armazenamento não funciona com a imagem de nó especificada devido a uma limitação inerente ao SO do nó ou ao Google Cloud Platform.

A matriz a seguir descreve como cada imagem de nó do GKE é compatível com alguns plug-ins de armazenamento comuns.

Tipo de volume Ele funciona no Container-Optimized OS (cos)? Ele funciona no Ubuntu?
Google Compute Engine
Disco permanente (EXT4 ou XFS)
Sim — totalmente testado/compatível
(O XFS não é compatível.)
Sim — totalmente testado/compatível
GlusterFS Sim — totalmente testado/compatível
(O XFS não é compatível.)
Sim — totalmente testado/compatível
NFSv3 Sim — totalmente testado/compatível Sim — totalmente testado/compatível
NFSv4 Sim — totalmente testado/compatível Sim — totalmente testado/compatível
CephFS Não Sim — teste limitado
(O driver não é instalado por padrão. É necessário instalar o cliente ceph, de preferência por meio do DaemonSet.)
Cinder Não Não
Fibre Channel Não Não
Flocker Não compatível Não compatível
iSCSI Não Não
RBD Não Não

Modificações na VM do nó

As modificações no disco de inicialização de uma VM do nó não permanecem nas recriações de nós. Eles são recriados durante [upgrades manuais], [upgrades automáticos], [reparos automáticos] e [escalonamentos automáticos]. Para que as modificações sejam mantidas durante a recriação dos nós, use um DaemonSet.

Não é recomendado gerenciar softwares críticos fornecidos por uma imagem de nó, como o kernel ou o ambiente de execução do contêiner (seja o containerd ou o docker). As imagens dos nós são testadas extensivamente e a modificação do software crítico fornecido na imagem do nó o coloca em um estado desconhecido e não-testável.

Notas da versão das imagens de nós

Container-Optimized OS

O Google oferece uma documentação abrangente para o Container-Optimized OS:

Ubuntu

Periodicamente, o Google atualiza as imagens do Ubuntu que estão disponíveis para uso em nós de clusters. Consulte as notas da versão do GKE para saber mais sobre essas atualizações, incluindo um link para um manifesto que lista os pacotes instalados por padrão.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Kubernetes Engine