Adicionando Pools de Nós para Expandir Clusters

• Console
• CLI
• API

• Para expandir um cluster existente aumentando o número de pools de nós no cluster usando a Console:

  1. Abra o menu de navegação e selecione Serviços ao Desenvolvedor. Em Contêineres e Artefatos, selecione Clusters do Kubernetes (OKE).
  2. Escolha um Compartimento no qual você tem permissão para trabalhar.
  3. Na página Lista de Clusters, clique no nome do cluster que você deseja modificar.
  4. Em Resources, clique em Node pools.
  5. Clique no botão Adicionar pool de nós e amplie o cluster adicionando pools de nós.
  6. Informe os detalhes do novo pool de nós:
     • Nome: um nome à sua escolha para o novo pool de nós. Evite fornecer informações confidenciais.
     • Compartimento: O compartimento no qual criar o novo pool de nós.
     • Tipo de nó: Se o tipo de rede do cluster for Rede de pod nativo da VCN, especifique o tipo de nós de trabalho neste pool de nós (consulte Nós Virtuais e Nós Gerenciados). Selecione uma das seguintes opções:
       • Gerenciado: Selecione essa opção quando quiser ter responsabilidade pelo gerenciamento dos nós de trabalho no pool de nós. Nós gerenciados, em execução em instâncias de computação (bare metal ou máquina virtual) em sua tenancy. Como você é responsável pelo gerenciamento de nós gerenciados, tem a flexibilidade de configurá-los para atender aos seus requisitos específicos. Você é responsável pelo upgrade do Kubernetes em nós gerenciados e pelo gerenciamento da capacidade do cluster.
       • Virtual: Selecione essa opção quando quiser se beneficiar de uma experiência do Kubernetes 'sem servidor'. Os nós virtuais permitem que você execute pods do Kubernetes em escala sem a sobrecarga operacional de fazer upgrade da infraestrutura do plano de dados e gerenciar a capacidade dos clusters.

       Para obter mais informações, consulte Comparando Nós Virtuais com Nós Gerenciados.

     • Versão: (Somente pools de nós gerenciados) A versão do Kubernetes a ser executada em cada nó gerenciado em um pool de nós gerenciados. Por padrão, a versão do Kubernetes especificada para os nós de plano de controle é selecionada. A versão do Kubernetes nos nós de trabalho deve ser a mesma versão dos nós de plano de controle ou uma versão anterior que ainda seja compatível. Consulte Versões do Kubernetes e Kubernetes Engine (OKE).

       Observe que, se você especificar uma imagem do OKE para nós de trabalho, a versão do Kubernetes selecionada aqui deverá ser a mesma que a versão do Kubernetes na imagem do OKE.

  7. Se o tipo de rede do cluster for Rede de pod nativa da VCN e você tiver selecionado Gerenciado como o Tipo de Nó ou se o tipo de rede do cluster for Sobreposição de canal:

     1. Especifique detalhes de configuração para o pool de nós gerenciados:

        • Configuração de Posicionamento de Nó:
          • Domínio de disponibilidade: Um domínio de disponibilidade no qual serão colocados os nós de trabalho.
          • Sub-rede de nó de trabalho: Uma sub-rede regional (recomendada) ou uma sub-rede específica do AD configurada para hospedar nós de trabalho. Se você especificou sub-redes de balanceador de carga, as sub-redes de nó de trabalho deverão ser distintas. As sub-redes especificadas podem ser privadas (recomendado) ou públicas. Consulte Configuração da Sub-rede.
          • Domínios de falha: (Opcional) Um ou mais domínios de falha no domínio de disponibilidade no qual colocar nós de trabalho.

          Opcionalmente, clique em Mostrar opções avançadas para especificar um tipo de capacidade a ser usado (consulte Gerenciando Tipos de Capacidade do Nó de Trabalho). Se você especificar uma reserva de capacidade, certifique-se de que a forma do nó, o domínio de disponibilidade e o domínio de falha na configuração de posicionamento do pool de nós correspondam ao tipo de instância, domínio de disponibilidade e domínio de falha da reserva de capacidade, respectivamente. Consulte Usando Reservas de Capacidade para Provisionar Nós Gerenciados.

          Se preferir, clique em Outra Linha para selecionar domínios e sub-redes adicionais em que serão colocados nós de trabalho.

          Quando os nós de trabalho são criados, eles são distribuídos o mais uniformemente possível pelos domínios de disponibilidade e pelos domínios de falha selecionados. Se você não selecionar nenhum domínio de falha para um determinado domínio de disponibilidade, os nós de trabalho serão distribuídos o mais uniformemente possível em todos os domínios de falha nesse domínio de disponibilidade.

        • Forma do Nó: A forma a ser usada para nós de trabalho no pool de nós. A forma determina o número de CPUs e a quantidade de memória alocada para cada nó.

          Somente as formas disponíveis em sua tenancy que são suportadas pelo Kubernetes Engine são mostradas.

          Se você selecionar uma forma flexível, poderá especificar explicitamente o número de CPUs e a quantidade de memória.

          Consulte Imagens Suportadas (Incluindo Imagens Personalizadas) e Formas para Nós de Trabalho.

        • Imagem: A imagem a ser usada nos nós de trabalho do pool de nós. Uma imagem é um modelo de um disco rígido virtual que determina o sistema operacional e outro software para o nó.

          Para alterar a imagem padrão, clique em Alterar imagem. Na janela Procurar todas as imagens, escolha uma Origem da imagem e selecione uma imagem da seguinte forma:

          • Imagens do Nó de Trabalho do OKE: Recomendado. Fornecido pela Oracle e desenvolvido com base em imagens de plataforma. As imagens do OKE são otimizadas para servir como imagens base para nós de trabalho, com todas as configurações necessárias e o software necessário. Selecione uma imagem do OKE se quiser minimizar o tempo necessário para provisionar nós de trabalho no runtime em comparação com imagens de plataforma e imagens personalizadas.

            Os nomes de imagem do OKE incluem o número da versão da versão do Kubernetes que eles contêm. Observe que, se você especificar uma versão do Kubernetes para o pool de nós, a imagem do OKE selecionada aqui deverá ter o mesmo número de versão da versão do Kubernetes do pool de nós.

          • Imagens da plataforma: fornecidas pela Oracle e contêm apenas um sistema operacional Oracle Linux. Selecione uma imagem de plataforma se quiser que o Kubernetes Engine faça download, instale e configure o software necessário quando a instância de computação que hospeda um nó de trabalho for inicializada pela primeira vez.

          Consulte Imagens Suportadas (Incluindo Imagens Personalizadas) e Formas para Nós de Trabalho.

        • Contagem de nós: O número de nós de trabalho a serem criados no pool de nós, colocados nos domínios de disponibilidade selecionados e na sub-rede regional (recomendado) ou na sub-rede específica do AD especificada para cada domínio de disponibilidade.
        • Usar regras de segurança no Grupo de Segurança de Rede (NSG): Controle o acesso ao pool de nós usando regras de segurança definidas para um ou mais grupos de segurança de rede (NSGs) que você especifica (até cinco no máximo). Você pode usar regras de segurança definidas para NSGs em vez de, ou também, aquelas definidas para listas de segurança (NSGs são recomendados). Para obter mais informações sobre as regras de segurança a serem especificadas para o NSG, consulte Regras de Segurança para Nós de Trabalho.

        • Volume de inicialização: Configure as opções de tamanho e criptografia para o volume de inicialização do nó de trabalho:

          • Para especificar um tamanho personalizado para o volume de inicialização, marque a caixa de seleção Especificar um tamanho de volume de inicialização personalizado. Em seguida, informe um tamanho personalizado de 50 GB a 32 TB. O tamanho especificado deve ser maior que o tamanho do volume de inicialização padrão para a imagem selecionada. Consulte Tamanhos de Volume de Inicialização Personalizados para obter mais informações.

            Observe que, se você aumentar o tamanho do volume de inicialização, também será necessário estender a partição do volume de inicialização (a partição raiz) para tirar proveito do tamanho maior. Consulte Estendendo a Partição de um Volume de Inicialização. As imagens da plataforma Oracle Linux incluem o pacote oci-utils. Você pode usar o comando oci-growfs desse pacote em um script cloud-init personalizado para estender a partição raiz e, em seguida, aumentar o sistema de arquivos. Para obter mais informações, consulte Estendendo a Partição Raiz dos Nós de Trabalho.

          • Para instâncias de VM, você pode, opcionalmente, marcar a caixa de seleção Usar criptografia em trânsito. Para instâncias bare metal que suportam criptografia em trânsito, essa opção é ativada por padrão e não é configurável. Consulte Criptografia em Trânsito para obter mais informações sobre criptografia em trânsito. Se você estiver usando sua própria chave de criptografia do serviço Vault para o volume de inicialização, essa chave também será usada para criptografia em trânsito. Caso contrário, a chave de criptografia fornecida pelo sistema Oracle será usada.
          • Os volumes de inicialização são criptografados por padrão, mas você tem a opção de usar sua própria chave de criptografia do serviço Vault para criptografar os dados nesse volume. Para usar o Serviço Vault em suas necessidades de criptografia, marque a caixa de seleção criptografar este volume com uma chave que você gerencia. Selecione o compartimento e o vault do vault que contêm a chave principal de criptografia que você deseja usar e selecione o compartimento principal e a chave principal de criptografia. Se você ativar essa opção, essa chave será usada para criptografia de dados em repouso e criptografia em trânsito.
            Importante
            
            O serviço Block Volume não suporta criptografia de volumes com chaves criptografadas usando o algoritmo RSA (Rivest-Shamir-Adleman). Ao usar suas próprias chaves, você deverá usar as chaves criptografadas usando o algoritmo AES (Advanced Encryption Standard). Isso se aplica a volumes em blocos e volumes de inicialização.

          Observe que, para usar sua própria chave de criptografia do serviço Vault para criptografar dados, uma política do serviço IAM deve conceder acesso à chave de criptografia do serviço. Consulte Criar Política para Acessar Chaves de Criptografia Gerenciadas pelo Usuário para Criptografar Volumes de Inicialização, Volumes em Blocos e/ou Sistemas de Arquivos.

        • Comunicação de pod: Quando o Tipo de rede do cluster for Rede de pod nativo da VCN, especifique como os pods no pool de nós se comunicam entre si usando uma sub-rede de pod:
          • Sub-rede: Uma sub-rede regional configurada para hospedar pods. A sub-rede de pod especificada deve ser privada. Em algumas situações, a sub-rede do nó de trabalho e a sub-rede do pod podem ser a mesma sub-rede (nesse caso, a Oracle recomenda definir regras de segurança em grupos de segurança de rede, em vez de em listas de segurança). Consulte Configuração da Sub-rede.
          • Usar regras de segurança no Grupo de Segurança de Rede (NSG): Controle o acesso à sub-rede do pod usando regras de segurança definidas para um ou mais grupos de segurança de rede (NSGs) que você especifica (até cinco no máximo). Você pode usar regras de segurança definidas para NSGs em vez de, ou também, aquelas definidas para listas de segurança (NSGs são recomendados). Para obter mais informações sobre as regras de segurança a serem especificadas para o NSG, consulte Regras de Segurança para Nós de Trabalho e Pods.

          Opcionalmente, clique em Mostrar opções avançadas para especificar o número máximo de pods que você deseja executar em um único nó de trabalho em um pool de nós, até um limite de 110. O limite de 110 é imposto pelo Kubernetes. Se você quiser mais de 31 pods em um único nó de trabalho, a forma especificada para o pool de nós deverá suportar três ou mais VNICs (uma VNIC para estabelecer conexão com a sub-rede do nó de trabalho e pelo menos duas VNICs para estabelecer conexão com a sub-rede do pod). Consulte Número Máximo de VNICs e Pods Suportados por Diferentes Formas.

          Para obter mais informações sobre comunicação de pod, consulte Rede de Pod.

     2. Aceite os padrões para opções avançadas de pool de nós ou selecione Mostrar opções avançadas e especifique alternativas, da seguinte maneira:

        • Cordon e drenagem: Especifique quando e como conectar e drenar nós de trabalho antes de encerrá-los.

          • Período de tolerância de advertência (minutos): O período de tempo para permitir o cordão e o dreno de nós de trabalho antes de encerrá-los. Aceite o padrão (60 minutos) ou especifique uma alternativa. Por exemplo, ao reduzir um pool de nós ou alterar sua configuração de posicionamento, talvez você queira permitir 30 minutos para nós de trabalho do cordão e drená-los de suas cargas de trabalho. Para encerrar os nós de trabalho imediatamente, sem isolá-los e drená-los, especifique 0 minuto.
          • Forçar encerramento após o período de tolerância: Se os nós de trabalho devem ser encerrados no final do período de tolerância de despejo, mesmo que eles não tenham sido isolados e drenados com sucesso. Por padrão, essa opção não está selecionada.

            Selecione esta opção se você sempre quiser que os nós de trabalho sejam desligados no final do período de tolerância de despejo, mesmo que eles não tenham sido isolados e drenados com sucesso.

            Desmarque esta opção se não quiser que os nós de trabalho que não foram isolados e drenados com sucesso sejam desligados no final do período de tolerância para remoção. Os pools de nós que contêm nós de trabalho que não podem ser encerrados dentro do período de tolerância de remoção têm o status Precisa de atenção. O status da solicitação de serviço que iniciou a operação de encerramento é definido como Com Falha e a operação de encerramento é cancelada. Para obter mais informações, consulte Monitorando Clusters.

          Para obter mais informações, consulte Observações sobre Cordonagem e Drenagem de Nós Gerenciados Antes do Encerramento.

        • Script de inicialização: (Opcional) Um script para cloud-init ser executado em cada instância que hospeda nós de trabalho quando a instância é inicializada pela primeira vez. O script especificado deve ser gravado em um dos formatos suportados pelo cloud-init (por exemplo, cloud-config) e deve ser um tipo de arquivo suportado (por exemplo, .yaml). Especifique o script como segue:
          • Escolher Script Cloud-Init: Selecione um arquivo que contenha o script cloud-init ou arraste e solte o arquivo na caixa.
          • Colar Script Cloud-Init: Copie o conteúdo de um script cloud-init e cole-o na caixa.

          Se você ainda não tiver gravado scripts cloud-init para inicializar nós de trabalho em clusters criados pelo Kubernetes Engine, talvez seja útil clicar em Fazer Download do Modelo de Script Cloud-Init Personalizado. O arquivo baixado contém a lógica padrão fornecida pelo Kubernetes Engine. É possível adicionar sua própria lógica personalizada antes ou depois da lógica padrão, mas não modifique a lógica padrão. Para obter exemplos, consulte Exemplo de Casos de Uso para Scripts Cloud-init Personalizados.

        • Labels do Kubernetes: (Opcional) Um ou mais labels (além de um label padrão) a serem adicionados aos nós de trabalho no pool de nós para ativar o direcionamento de cargas de trabalho em pools de nós específicos. Por exemplo, para excluir todos os nós de um pool de nós da lista de servidores de backend em um conjunto de backend do balanceador de carga, especifique node.kubernetes.io/exclude-from-external-load-balancers=true (consulte node.kubernetes.io/exclude-from-external-load-balancers).
        • Tags do pool de nós e Tags do nó: (Opcional) Uma ou mais tags a serem adicionadas ao pool de nós e às instâncias de computação que hospedam nós de trabalho no pool de nós. O serviço Tagging permite que você agrupe recursos diferentes entre compartimentos e também permite anotar recursos com seus próprios metadados. Consulte Marcando Recursos Relacionados ao Cluster do Kubernetes.
        • Chave SSH Pública: (Opcional) A parte da chave pública do par de chaves que você deseja usar para acesso SSH a cada nó no pool de nós. A chave pública está instalada em todos os nós de trabalho no cluster. Observe que, se você não especificar uma chave SSH pública, o Kubernetes Engine fornecerá uma. No entanto, como você não terá a chave privada correspondente, não terá acesso SSH aos nós de trabalho. Observe que não é possível usar SSH para acessar diretamente nenhum nó de trabalho em sub-redes privadas (consulte Estabelecendo Conexão com Nós Gerenciados em Sub-redes Privadas Usando SSH).
  8. Se você selecionou Virtual como o Tipo de Nó:
     1. Especifique os detalhes de configuração do pool de nós virtuais:
        • Configuração de Posicionamento de Nó:
          • Domínio de disponibilidade: Um domínio de disponibilidade no qual serão colocados os nós virtuais.
          • Domínios de falha: (Opcional) Um ou mais domínios de falha no domínio de disponibilidade no qual colocar nós virtuais.

          Opcionalmente, clique em Outra Linha para selecionar domínios e sub-redes adicionais nos quais colocar nós virtuais.

          Quando os nós virtuais são criados, eles são distribuídos o mais uniformemente possível pelos domínios de disponibilidade e pelos domínios de falha selecionados. Se você não selecionar nenhum domínio de falha para um determinado domínio de disponibilidade, os nós virtuais serão distribuídos o mais uniformemente possível em todos os domínios de falha nesse domínio de disponibilidade.

        • Contagem de nós: O número de nós virtuais a serem criados no pool de nós virtuais, colocados nos domínios de disponibilidade selecionados e na sub-rede regional (recomendado) ou na sub-rede específica do AD especificada para cada domínio de disponibilidade.

        • Forma do pod: A forma a ser usada para pods em execução em nós virtuais no pool de nós virtuais. A forma determina o tipo de processador no qual o pod será executado.

          Somente as formas disponíveis em sua tenancy que são suportadas pelo Kubernetes Engine são mostradas. Consulte Imagens Suportadas (Incluindo Imagens Personalizadas) e Formas para Nós de Trabalho.

          Observe que você especifica explicitamente os requisitos de recursos de CPU e memória para nós virtuais na especificação de pod (consulte Designar Recursos de Memória a Contêineres e Pods e Designar Recursos de CPU a Contêineres e Pods na documentação do Kubernetes).

        • Comunicação de nó virtual:
          • Sub-rede: Uma sub-rede regional (recomendada) ou uma sub-rede específica do AD configurada para hospedar nós virtuais. Se você especificou subnets de balanceador de carga, as subnets de nó virtual deverão ser distintas. As sub-redes especificadas podem ser privadas (recomendado) ou públicas e podem ser regionais (recomendado) ou específicas do AD. Recomendamos que a sub-rede de pod e a sub-rede de nó virtual sejam a mesma sub-rede (nesse caso, a sub-rede de nó virtual deve ser privada). Consulte Configuração da Sub-rede.
          • Usar regras de segurança no Grupo de Segurança de Rede (NSG): Controle o acesso à sub-rede do nó virtual usando regras de segurança definidas para um ou mais grupos de segurança de rede (NSGs) que você especificar (até cinco, no máximo). Você pode usar regras de segurança definidas para NSGs em vez das definidas para listas de segurança (NSGs são recomendados). Para obter mais informações sobre as regras de segurança a serem especificadas para o NSG, consulte Regras de Segurança para Nós de Trabalho e Pods.
        • Comunicação de pod: os pods em execução nos nós virtuais usam a rede de pod nativa da VCN. Especifique como os pods no pool de nós se comunicam entre si usando uma sub-rede de pods:
          • Sub-rede: Uma sub-rede regional configurada para hospedar pods. A sub-rede de pod especificada para nós virtuais deve ser privada. Recomendamos que a sub-rede do pod e a sub-rede do nó virtual sejam a mesma sub-rede (nesse caso, a Oracle recomenda definir regras de segurança em grupos de segurança de rede em vez de em listas de segurança). Consulte Configuração da Sub-rede.
          • Usar regras de segurança no Grupo de Segurança de Rede (NSG): Controle o acesso à sub-rede do pod usando regras de segurança definidas para um ou mais grupos de segurança de rede (NSGs) que você especifica (até cinco no máximo). Você pode usar regras de segurança definidas para NSGs em vez de, ou também, aquelas definidas para listas de segurança (NSGs são recomendados). Para obter mais informações sobre as regras de segurança a serem especificadas para o NSG, consulte Regras de Segurança para Nós de Trabalho e Pods.

          Para obter mais informações sobre comunicação de pod, consulte Rede de Pod.

     2. Aceite os padrões para opções avançadas de pool de nós virtuais ou clique em Mostrar opções avançadas e especifique alternativas, da seguinte maneira:

        • Tags do pool de nós: (Opcional) Uma ou mais tags a serem adicionadas ao pool de nós virtuais. O serviço Tagging permite que você agrupe recursos diferentes entre compartimentos e também permite anotar recursos com seus próprios metadados. Consulte Marcando Recursos Relacionados ao Cluster do Kubernetes.
        • Label e taints do Kubernetes: (Opcional) Ative o direcionamento de cargas de trabalho em pools de nós específicos adicionando labels e taints a nós virtuais:
          • Labels: Um ou mais labels (além de um label padrão) a serem adicionados a nós virtuais no pool de nós virtuais para ativar o destino de cargas de trabalho em pools de nós específicos.
          • Dicas: Uma ou mais dicas a serem adicionadas aos nós virtuais no pool de nós virtuais. As dicas permitem que nós virtuais repelem pods, garantindo assim que os pods não sejam executados em nós virtuais em um pool de nós virtual específico. Observe que você só pode aplicar taints a nós virtuais.

          Para obter mais informações, consulte Designando Pods a Nós na documentação do Kubernetes.

  9. Clique em Adicionar para criar o novo pool de nós.

• Use o comando oci ce node-pool create e os parâmetros necessários para expandir um cluster adicionando um pool de nós gerenciado:

  Copiar

  oci ce node-pool create --cluster-id <cluster-ocid> --compartment-id <compartment-ocid> --name <node-pool-name> --node-shape <shape>

  Use o comando oci ce virtual-node-pool create e os parâmetros necessários para expandir um cluster adicionando um pool de nós virtuais:

  Copiar

  oci ce virtual-node-pool create \
  --cluster-id <cluster-ocid> \
  --compartment-id <compartment-ocid> \
  --display-name <node-pool-name> \
  --kubernetes-version <kubernetes-version> \
  --placement-configurations "[{\"availabilityDomain\":\"<ad-name>\",\"faultDomain\":[\"FAULT-DOMAIN-<n>\"],\"subnetId\":\"<virtualnode-subnet-ocid>\"}]" \
  --nsg-ids "[\"<virtual-node-nsg-ocid>\"]" \
  --pod-configuration "{\"subnetId\":\"<pod-subnet-ocid>\",\"nsgIds\":[\"<pod-nsg-ocid>\"],\"shape\":\"<shape-name>\"}" \
  --size <number-of-nodes>

  em que:

  • <ad-name> é o nome do domínio de disponibilidade no qual colocar nós virtuais. Para descobrir o nome do domínio de disponibilidade a ser usado, execute:
    Copiar

    oci iam availability-domain list

  • <shape-name> é um de Pod.Standard.E3.Flex, Pod.Standard.E4.Flex.

  Para obter uma lista completa dos parâmetros e valores dos comandos da CLI, consulte a Referência de Comandos da CLI.

• Execute a operação CreateNodePool para ampliar um cluster adicionando um pool de nós gerenciados.

  Execute a operação CreateVirtualNodePool para ampliar um cluster adicionando um pool de nós virtuais.