Atualizando um Pool de Nós

• Console
• CLI
• API

• Para modificar as propriedades de pools de nós e de nós de trabalho dos clusters existentes do Kubernetes:

  1. Abra o menu de navegação e clique em Serviços ao Desenvolvedor. Em Contêineres e Artefatos, clique em Clusters do Kubernetes (OKE).
  2. Selecione o compartimento que contém o cluster.
  3. Na página Lista de Clusters, clique no nome do cluster que você deseja modificar.
  4. Na página Detalhes do cluster, em Recursos, clique em Pools de nós.
  5. Clique no nome do pool de nós que você deseja modificar.

  6. Use a guia Detalhes do pool de nós para exibir informações sobre o pool de nós, incluindo:

     • O status do pool de nós.
     • OCID do pool de nós.
     • O tipo dos nós de trabalho no pool de nós (gerenciado ou virtual).
     • A configuração usada no momento ao iniciar novos nós de trabalho no pool de nós, incluindo:
       • a versão do Kubernetes a ser executada nos nós de trabalho
       • a forma a ser usada para nós de trabalho
       • a imagem a ser usada nos nós de trabalho
     • Os domínios de disponibilidade, domínios de falha e diferentes sub-redes regionais (recomendadas) ou sub-redes específicas do AD que hospedam nós de trabalho.

     O tipo de nós de trabalho no pool de nós (gerenciado ou virtual) determina qual pool de nós e as propriedades do nó de trabalho você pode alterar.

  7. (opcional) No caso de um pool de nós gerenciados e nós gerenciados, altere as propriedades da seguinte forma:

     1. Clique em Editar e especifique:
        • Nome: Outro nome para o pool de nós. Evite fornecer informações confidenciais.

        • Versão: Outra versão do Kubernetes a ser executada nos novos nós de trabalho do pool de nós ao fazer um upgrade no local. A versão do Kubernetes nos nós de trabalho deve ser a mesma 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.

          Para iniciar novos nós de trabalho que estão executando a versão do Kubernetes especificada, 'drene' os nós de trabalho existentes no pool de nós (para evitar que novos pods sejam iniciados e excluir os pods existentes) e, em seguida, encerre cada um dos nós de trabalho existentes.

          Você também pode especificar outra versão do Kubernetes a ser executada nos novos nós de trabalho executando um upgrade fora do local. Para obter mais informações sobre como fazer upgrade dos nós de trabalho, consulte Upgrading Managed Nodes to a Newer Kubernetes Version.

        • Contagem de nós: Um número diferente de nós no pool de nós. Consulte Dimensionando Pools de Nós.
        • 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, observe 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 gerenciados devem corresponder ao tipo de instância, ao domínio de disponibilidade e ao 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ó: Outra 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: Outra 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, 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.

        • 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: Altere 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 de Volume em Blocos 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, altere 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 pode ser pública ou 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.
          • Grupo de Segurança de Rede: 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 valores existentes para opções avançadas de pool de nós ou clique em Mostrar Opções Avançadas e especifique alternativas, da seguinte maneira:

        • Cordon e drenagem: Altere 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 diferente para o cloud-init ser executado em instâncias que hospedam 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).
        • Chave SSH Pública: (Opcional) Outra parte da chave pública do par de chaves que você deseja usar para acesso SSH aos nós do 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).
     3. Clique em Salvar Alterações para salvar as propriedades atualizadas.

  8. (opcional) No caso de um pool de nós virtuais e nós virtuais, altere as propriedades da seguinte forma:

     1. Clique em Editar e especifique:
        • Nome: Outro nome para o pool de nós. Evite fornecer informações confidenciais.
        • Contagem de nós: Um número diferente 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 (recomendável) ou na sub-rede específica do AD especificada para cada domínio de disponibilidade. Consulte Dimensionando Pools de Nós.
        • 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 mais domínios e sub-redes 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.

        • Comunicação de Nó Virtual:
          • Sub-rede: Outra 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). Para obter mais informações, consulte Configuração de 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ê 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.
        • Comunicação do Pod:
          • Sub-rede: Outra 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). Para obter mais informações, consulte Configuração de 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.

        • 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 e, portanto, garantem que os pods não sejam executados em nós virtuais em um pool de nós virtual específico. 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.

     2. Clique em Salvar Alterações para salvar as propriedades atualizadas.
  9. Use as guias Tags de pool de nós e Tags de nó para adicionar ou modificar tags aplicadas ao pool de nós e tags aplicadas a 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.
  10. Em Recursos:
      • Clique em Nós para ver informações sobre nós de trabalho específicos em um pool de nós gerenciados. Se preferir, edite os detalhes da configuração de um nó de trabalho específico clicando no nome do nó.
      • Clique em Nós Virtuais para ver informações sobre nós de trabalho específicos em um pool de nós virtuais.
      • Clique em Métricas para monitorar a integridade, a capacidade e o desempenho de um pool de nós gerenciado. Para obter mais informações, consulte Métricas do Kubernetes Engine (OKE).
      • Clique em Solicitações de serviço para:
        • Obtenha os detalhes de uma solicitação de serviço específica para o recurso do pool de nós.
        • Liste as solicitações de serviço para o recurso do pool de nós.

        Para obter mais informações, consulte Exibindo Solicitações de Serviço.

• Use o comando oci ce node-pool update e os parâmetros necessários para atualizar um pool de nós gerenciados:

  oci ce node-pool update --node-pool-id <node-pool-ocid> [OPTIONS]

  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 UpdateNodePool para atualizar um pool de nós gerenciados.