Usando a Console para criar um Cluster com Definições Configuradas Explicitamente no workflow 'Criação Personalizada'

Descubra como usar o workflow 'Criação Personalizada' para criar um cluster do Kubernetes com definições definidas explicitamente e recursos de rede existentes usando o Kubernetes Engine (OKE).

Para criar um cluster com definições explicitamente definidas e recursos de rede existentes no workflow 'Criação Personalizada' usando o Kubernetes Engine:

1. Na página da lista Clusters, selecione Criar cluster. Se precisar de ajuda para localizar a página de lista, consulte Listando Clusters.
2. No diálogo Criar cluster, selecione Criação personalizada e selecione Continuar.

3. Na páginaCriar cluster, aceite os detalhes de configuração padrão do novo cluster ou especifique alternativas conforme a seguir:

   • Nome: O nome do novo cluster. Aceite o nome padrão ou digite um nome à sua escolha. Evite fornecer informações confidenciais.
   • Compartimento: O compartimento no qual o novo cluster será criado.

   • versão do Kubernetes: A versão do Kubernetes a ser executada nos nós do plano da cluster. Aceite a versão padrão ou selecione uma versão à sua escolha. Entre outras coisas, a versão do Kubernetes selecionada determina o conjunto padrão de controladores de admissão que são ativados no cluster criado (consulte Controladores de Admissão Suportados).

     Os números de versão disponíveis do Kubernetes são mostrados no formato x.y, em que x é uma versão principal e y é uma versão secundária. Depois de selecionar uma versão do Kubernetes no formato x.y, você pode selecionar Mostrar versões de patch e especificar uma versão de patch suportada para a versão major.minor selecionada. No entanto, recomendamos que você simplesmente selecione uma versão do Kubernetes no formato x.y, para permitir que o Kubernetes Engine selecione automaticamente a versão de patch suportada mais recente para a versão secundária. Para obter mais informações, consulte Versões do Kubernetes e Kubernetes Engine (OKE).

     Observe que a lista de versões do Kubernetes inclui versões de visualização fornecidas apenas para fins de teste e validação de acesso antecipado. Estas versões de pré-visualização têm ".0" como o número de versão do patch (por exemplo, 1.34.0). As versões de visualização não se destinam a cargas de trabalho de produção e podem conter problemas sem soluções alternativas conhecidas. Não recomendamos o uso de versões de visualização para cargas de trabalho de produção.

4. Aceite os padrões para opções de cluster avançadas ou selecione Opções avançadas e defina as opções da seguinte forma:

   1. Verificação de imagem: Especifique se só será permitida a implantação de imagens do Oracle Cloud Infrastructure Registry que tenham sido assinadas por chaves de criptografia mestras específicas. Para impor o uso de imagens assinadas, selecione Ativar políticas de verificação de imagem neste cluster e, em seguida, especifique a chave de criptografia e o vault que a contém. Consulte Impondo o Uso de Imagens Assinadas do Registro.

   2. Criptografia de segredos do Kubernetes: Especifique como criptografar segredos do Kubernetes em repouso no armazenamento de chave/valor do etcd para o cluster:

      • Criptografar usando uma chave gerenciada pela Oracle: Criptografe segredos do Kubernetes no armazenamento de chave/valor do etcd usando uma chave de criptografia mestra gerenciada pela Oracle.

      • Criptografar usando uma chave que você gerencia: Criptografe os segredos do Kubernetes no armazenamento de chave/valor do etcd usando uma chave de criptografia mestra (armazenada no serviço Vault) que você gerencia. Se você selecionar esta opção, especifique:

        • Escolher um vault: O vault que contém a chave mestra de criptografia, na lista de vaults no compartimento especificado. Por padrão, o compartimento é aquele no qual você estiver criando o cluster, mas pode selecionar outro compartimento.
        • Escolher uma chave: O nome da chave de criptografia principal, na lista de chaves do compartimento especificado. Por padrão, o compartimento é aquele no qual você estiver criando o cluster, mas pode selecionar outro compartimento. Observe que não é possível alterar a chave de criptografia mestra após a criação do cluster.

      Observe que, se você quiser gerenciar a chave de criptografia mestra, uma chave adequada, um grupo dinâmico e uma política já deverão existir para que você possa criar o cluster. Para obter mais informações, consulte Criptografando Segredos do Kubernetes em Repouso no Etcd.

   3. Políticas de Segurança do Pod:(versões do Kubernetes anteriores à 1,25) Especifique se deve controlar as operações que os pods têm permissão para executar no cluster, impondo políticas de segurança do pod:

      • Não Imposto: Não impõe políticas de segurança de pod.
      • Imposta: Impõe políticas de segurança de pod, ativando o controlador de admissão PodSecurityPolicy. Apenas pods que atendam às condições em uma política de segurança de pod são aceitos pelo cluster. Para obter mais informações, consulte Usando Políticas de Segurança de Pod com o Kubernetes Engine (OKE).
      Cuidado
      
      

      É muito importante observar que, quando você ativa o controlador de admissão PodSecurityPolicy de um cluster, nenhum pod de aplicativo pode iniciar no cluster, a menos que existam políticas de segurança de pod adequadas, juntamente com atribuições (ou clusterroles) e rolebindings (ou clusterrolebindings) para associar pods a políticas. Você não poderá executar pods de aplicativos em um cluster com um controlador de admissão PodSecurityPolicy ativado, a menos que esses pré-requisitos sejam atendidos.

      Recomendamos que você use os controladores de admissão PodSecurityPolicy da seguinte forma:

      • Sempre que você criar um novo cluster, ative o Controlador de Admissão de Segurança do Pod.
      • Imediatamente após criar um novo cluster, crie as políticas de segurança do pod, com atribuições (ou clusterroles) e rolebindings (ou clusterrolebindings).
   4. Configurar complementos de cluster: (Somente clusters aprimorados) Ative ou desative complementos específicos, escolha versões de complementos, aceite e desative atualizações automáticas pela Oracle e gerencie personalizações específicas de complementos. Selecione Editar no menu Ações (três pontos) ao lado de um complemento de cluster e defina as opções de configuração conforme apropriado. Consulte Configurando Complementos de Cluster.
   5. Descoberta do OpenID Connect (OIDC): (Somente clusters aprimorados) Especifique se o cluster será ativado para Descoberta do OIDC. Selecione Ativar descoberta do OIDC para permitir que os pods de aplicativos em execução no cluster sejam autenticados usando a Descoberta do OIDC ao acessar APIs hospedadas em um provedor de nuvem externo. Consulte Autorizando Pods para Acessar Recursos Não OCI Usando a Descoberta do OpenID Connect (OIDC).
   6. Tag: Especifique se serão adicionadas Tags de cluster ao cluster, Tags iniciais do balanceador de carga aos balanceadores de carga criados pelos serviços do Kubernetes do tipo LoadBalancer e Tags iniciais do volume em blocos aos volumes em blocos criados por reivindicações de volume persistente do Kubernetes. A marcação permite agrupar recursos diferentes entre compartimentos e também permite anotar recursos com seus próprios metadados. Consulte Marcando com Tag Recursos Relacionados ao Cluster do Kubernetes.

5. Selecione Próximo e especifique os recursos existentes de rede a serem utilizados para o novo cluster na página Configuração da rede:

   • Tipo de rede: Especifique como os pods em execução nos nós do cluster se comunicam entre si, com os nós do plano de controle do cluster, com pods em outros clusters, com outros serviços (como serviços de armazenamento) e com a internet (consulte Rede de Pod). Selecione uma das seguintes opções:
     • Rede de pod nativo da VCN: Selecione esta opção para conectar nós em um cluster do Kubernetes a sub-redes de pods em uma VCN do Oracle Cloud Infrastructure. Como resultado, os endereços IP de pod dentro de uma VCN podem ser diretamente roteados de outras VCNs conectadas (pareadas) para essa VCN e de redes locais. Você pode criar nós virtuais e nós gerenciados se selecionar essa opção. Consulte Usando o plug-in CNI de Rede VCN-Native Pod do OCI para rede de pod.
     • Sobreposição de flannel: Selecione esta opção para encapsular a comunicação entre pods na rede de sobreposição de flannel, uma rede virtual simples de sobreposição privada que atende aos requisitos do modelo de rede Kubernetes, anexando endereços IP a contêineres. Os pods na rede de sobreposição privada só podem ser acessados de outros pods no mesmo cluster. Você pode criar nós gerenciados (mas não nós virtuais) se selecionar essa opção. Consulte Usando o plug-in CNI de flannel para rede de pod.
   • VCN: Selecione na lista de VCNs do compartimento especificado a rede virtual na nuvem existente que foi configurada para criação e implantação de clusters. Por padrão, o compartimento é aquele no qual você estiver criando o cluster, mas pode selecionar outro compartimento. Consulte Configuração da VCN.
   • Sub-rede de ponto final da API do Kubernetes: Selecione uma sub-rede regional para hospedar o ponto final da API do Kubernetes do cluster, na lista de sub-redes do compartimento especificado. Por padrão, o compartimento é aquele no qual você estiver criando o cluster, mas pode selecionar outro compartimento. A sub-rede especificada pode ser pública ou privada. O ponto final de API do Kubernetes sempre recebe um endereço IP privado. Se você especificar uma sub-rede pública, poderá opcionalmente expor o ponto final da API do Kubernetes à internet designando um endereço IP público ao ponto final (bem como o endereço IP privado). Para simplificar o gerenciamento de acesso, a Oracle recomenda que o ponto final da API do Kubernetes esteja em outra sub-rede para nós de trabalho e balanceadores de carga. Para obter mais informações, consulte Plano de Controle de Cluster do Kubernetes e API do Kubernetes.
   • Usar regras de segurança no Grupo de Segurança de Rede (NSG): Controle o acesso ao ponto final da API do Kubernetes do cluster usando regras de segurança definidas para um ou mais grupos de segurança de rede (NSGs) que você especificar. Você pode usar regras de segurança definidas para NSGs em vez de, ou também, aquelas definidas para listas de segurança (os NSGs são recomendados). Para obter mais informações sobre as regras de segurança que devem ser especificadas para o NSG, consulte Regras de Segurança do Ponto Final da API do Kubernetes.
   • Designar automaticamente o endereço IPv4 público: Se você tiver selecionado uma sub-rede pública para o ponto final da API do Kubernetes, poderá opcionalmente expor o ponto final à internet designando um endereço IP público ao ponto final. Se você não designar um endereço IP público, atualize as regras de roteamento e as regras de segurança para permitir o acesso ao ponto final usando um gateway de serviço e um gateway NAT (consulte Configuração da Sub-rede de Ponto Final da API do Kubernetes).
   • Designe automaticamente o endereço IPv6 dos prefixos de sub-rede: Se você tiver selecionado uma sub-rede de pilha dupla IPv4/IPv6 para o ponto final da API do Kubernetes, poderá, opcionalmente, designar um endereço IPv6 ao ponto final para tornar o cluster um cluster de pilha dupla. Se você selecionar essa opção, o endereço IPv6 do ponto final será escolhido automaticamente no primeiro prefixo IPv6 designado à sub-rede. Para obter mais informações, consulte Ativando Clusters para IPv4 e IPv6.

   • Sub-redes do balanceador de carga: Opcionalmente, selecione as sub-redes existentes que foram configuradas para hospedar balanceadores de carga, na lista de sub-redes do compartimento especificado. Por padrão, o compartimento é aquele no qual você estiver criando o cluster, mas pode selecionar outro compartimento. As sub-redes de balanceadores de carga devem ser distintas das sub-redes de nó de trabalho, podem ser públicas ou privadas e podem ser regionais (recomendado) ou específicas do AD. Não é necessário especificar sub-redes de balanceadores de carga. No entanto, se você especificar sub-redes de balanceadores de carga, o número de sub-redes de balanceadores de carga a serem especificadas dependerá da região em que você está criando o cluster e se as sub-redes são regionais ou específicas do AD.

     Se você estiver criando um cluster em uma região com três domínios de disponibilidade, poderá especificar:

     • Zero ou uma sub-rede regional de balanceador de carga (recomendado).
     • Zero ou duas sub-redes específicas do AD de balanceador de carga. Se você especificar duas sub-redes específicas do AD, as duas sub-redes deverão estar em domínios de disponibilidade distintos.

     Se você estiver criando um cluster em uma região com um único domínio de disponibilidade, poderá especificar:

     • Zero ou uma sub-rede regional de balanceador de carga (recomendado).
     • Zero ou uma sub-rede específica do AD de balanceador de carga.

     Consulte Configuração da Sub-rede.

6. Aceite os padrões para opções de rede avançadas ou selecione Opções avançadas e especifique alternativas da seguinte forma:

   • Atributos de segurança do ponto final: Um ou mais (até cinco no máximo) atributos de segurança ZPR a serem adicionados ao ponto final da API do Kubernetes do cluster.

     Se você tiver permissões para criar um recurso, também poderá ter permissões para adicionar atributos de segurança a esse recurso. Para adicionar um atributo de segurança, você deve ter permissões para usar o namespace do atributo de segurança. Para obter mais informações sobre atributos de segurança e namespaces de atributo de segurança, consulte Roteamento de Pacote de Confiança Zero. Se você não tiver certeza se deseja adicionar atributos de segurança, ignore essa opção ou pergunte a um administrador. Você pode adicionar atributos de segurança posteriormente.

     Consulte também Adicionando Atributos de Segurança a Recursos Relacionados a Cluster e Aplicando Políticas de ZPR

   • Bloco CIDR de serviço do Kubernetes: O grupo disponível de endereços de rede IPv4 que podem ser expostos como serviços do Kubernetes (ClusterIPs), expressos como um único bloco IPv4 CIDR contíguo. Por exemplo, 10.96.0.0/16. O bloco IPv4 CIDR especificado não deve se sobrepor ao bloco IPv4 CIDR da VCN. Para um cluster de pilha dupla, você também pode especificar um prefixo IPv6 do serviço Kubernetes. Consulte Blocos IPv4 CIDR e o Kubernetes Engine (OKE).
   • Prefixo IPv6 do serviço Kubernetes: Ao criar um cluster de pilha dupla, o grupo disponível de endereços de rede IPv6 que podem ser expostos como serviços Kubernetes (ClusterIPs), expresso como um bloco CIDR IPv6 único e contíguo. Por exemplo, fd00:eeee:eeee:0001::/108. O bloco CIDR IPv6 especificado não deve se sobrepor ao bloco CIDR IPv6 da VCN. Para um cluster de pilha dupla, você também pode especificar um bloco CIDR de serviço do Kubernetes. Consulte Ativando Clusters para IPv4 e IPv6.
   • Bloco CIDR de Pods: Se você selecionou Substituição de canal: como o Tipo de Rede, o grupo disponível de endereços de rede que podem ser alocados para pods em execução no cluster, expressos como um bloco IPv4 CIDR único e contíguo. Por exemplo, 10.244.0.0/16. O bloco CIDR especificado não deve se sobrepor aos blocos CIDR para sub-redes na VCN e pode estar fora do bloco CIDR da VCN. Para um cluster de pilha dupla, você pode especificar um bloco IPv4 CIDR e um bloco CIDR IPv6 (separado por uma vírgula). Não especifique um bloco CIDR se você tiver selecionado Rede de pods nativa da VCN como o Tipo de rede do cluster. Consulte Blocos IPv4 CIDR e o Kubernetes Engine (OKE).

7. Selecione Próximo e especifique os detalhes de configuração do primeiro pool de nó no cluster na página Pools de Nó:

   • Nome: um nome à sua escolha para o novo pool de nós. Evite fornecer informações confidenciais.
   • Compartimento: O compartimento no qual o novo pool de nós será criado.
   • Tipo de Nó: Se você tiver selecionado Rede de pod nativo da VCN: como Tipo de Rede, especifique o tipo de nós de trabalho nesse 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 a responsabilidade de gerenciar os nós de trabalho no pool de nós. Nós gerenciados são executados em instâncias de computação (bare metal ou máquina virtual) em sua tenancy. Como você é responsável por gerenciar 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 do Kubernetes: (Somente pools de nós gerenciados) A versão do Kubernetes a ser executada em cada nó gerenciado no 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).

     Os números de versão disponíveis do Kubernetes são mostrados no formato x.y, em que x é uma versão principal e y é uma versão secundária. Depois de selecionar uma versão do Kubernetes no formato x.y, você pode selecionar Mostrar versões de patch e especificar uma versão de patch suportada para a versão major.minor selecionada. No entanto, recomendamos que você simplesmente selecione uma versão do Kubernetes no formato x.y, para permitir que o Kubernetes Engine selecione automaticamente a versão de patch suportada mais recente para a versão secundária. Para obter mais informações, consulte Versões do Kubernetes e Kubernetes Engine (OKE).

     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.

     Observe que a lista de versões do Kubernetes inclui versões de visualização fornecidas apenas para fins de teste e validação de acesso antecipado. Estas versões de pré-visualização têm ".0" como o número de versão do patch (por exemplo, 1.34.0). As versões de visualização não se destinam a cargas de trabalho de produção e podem conter problemas sem soluções alternativas conhecidas. Não recomendamos o uso de versões de visualização para cargas de trabalho de produção.

8. Se você selecionou Rede de pod nativo da VCN como o Tipo de Rede e Gerenciado como o Tipo de Nó ou se selecionou Substituição de canal: como o Tipo de Rede:

   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 disponibilização no qual serão colocados nós de trabalho.
        • Sub-rede do nó de trabalho: Uma sub-rede regional (recomendada) ou uma sub-rede específica do AD configurada para hospedar nós de trabalho da lista de sub-redes no compartimento especificado. Por padrão, o compartimento é aquele no qual você estiver criando o cluster, mas pode selecionar outro compartimento. 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 (recomendadas) 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 os nós de trabalho serão colocados.

        Opcionalmente, selecione 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 você especificar um grupo de hosts de computação, o grupo de hosts de computação deverá estar ativo, deverá usar a mesma forma que o pool de nós e deverá estar no mesmo domínio de disponibilidade que a configuração de posicionamento. Consulte Usando Grupos de Hosts de Computação para Provisionar Nós Gerenciados.

        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.

        Se o pool de nós usar um cluster de computação, não especifique domínios de falha. Todos os nós de trabalho no pool de nós gerenciados são criados no domínio de disponibilidade que contém o cluster de computação. Consulte Usando Clusters de Computação para Provisionar Nós Gerenciados.

      • Tipo de Ativação de Rede: Opcionalmente, selecione o tipo de ativação de rede para a rede do nó de trabalho. Se você não selecionar um valor, PARAVIRTUALIZED será usado como o padrão.

        Na maioria dos casos, selecione PARAVIRTUALIZED. Selecione VFIO somente quando a forma e a imagem selecionadas suportarem a rede SR-IOV assistida por hardware e sua carga de trabalho exigir isso. Selecione E1000 somente quando necessário para compatibilidade com uma imagem ou carga de trabalho que não suporte rede paravirtualizada. O suporte para cada tipo de inicialização depende da forma e da imagem de computação selecionadas.

      • VNIC Principal: (Somente rede de pods nativa da VCN) Opcionalmente, especifique um ou mais (até cinco no máximo) atributos de segurança ZPR a serem adicionados à VNIC principal de nós de trabalho no pool de nós.

        Se você tiver permissões para criar um recurso, também poderá ter permissões para adicionar atributos de segurança a esse recurso. Para adicionar um atributo de segurança, você deve ter permissões para usar o namespace do atributo de segurança. Para obter mais informações sobre atributos de segurança e namespaces de atributo de segurança, consulte Roteamento de Pacote de Confiança Zero. Se você não tiver certeza se deseja adicionar atributos de segurança, ignore essa opção ou pergunte a um administrador. Você pode adicionar atributos de segurança posteriormente.

        Consulte também Adicionando Atributos de Segurança a Recursos Relacionados a Cluster e Aplicando Políticas de ZPR

      • Configurar VNICs Secundárias para nós: (Somente rede de pods nativa da VCN) Opcionalmente, defina uma ou mais VNICs secundárias. Para obter mais informações, consulte Anexando Várias VNICs Secundárias para Rede de Pods.

      • Forma do nó: A forma a ser usada para nós de trabalho no pool de nós gerenciados. A forma determina o número de CPUs e a quantidade de memória alocada para cada nó gerenciado. Para alterar a forma padrão, selecione Alterar forma.

        Somente as formas disponíveis na 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.

        Se você especificar um cluster de computação para o pool de nós gerenciados, selecione uma forma de nó que suporte RDMA e clusters de computação. Consulte Usando Clusters de Computação para Provisionar Nós Gerenciados.

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

        Para alterar a imagem padrão, selecione 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 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 que contêm apenas um sistema operacional Oracle Linux. Para versões do Kubernetes anteriores à 1.35, 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.

          Em clusters que executam o Kubernetes versão 1.35 (e posterior), o uso de imagens de plataforma (imagens de plataforma OL7 e imagens de plataforma OL8) não é recomendado. Recomendamos enfaticamente o uso de imagens do OKE para todas as novas implantações e upgrades.

        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 ser criado no pool de nó gerenciado, colocado nos domínios de disponibilidade que você seleciona e na sub-rede regional (recomendado) ou sub-rede específica do AD que você especifica 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ê especificar (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 (os 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 volumes de inicialização de nó gerenciado:

        • Para especificar um tamanho personalizado para o volume da inicialização, selecione Especificar um tamanho personalizado de volume da inicialização e 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 da inicialização, também será necessário aumentar o número de partições no volume da inicialização (a partição raiz) para aproveitar o 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 de Nós de Trabalho.

        • Para instâncias da VM, você pode selecionar Usar criptografia em trânsito como opção. 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 de serviço do Vault para o volume de inicialização, essa chave também é 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ê pode usar sua própria chave de criptografia do serviço Vault para criptografar os dados nesse volume. Para usar o serviço Vault para suas necessidades de criptografia, selecione Criptografar este volume com uma chave que você gerencia. Selecione o compartimento do vault e o vault que contêm a chave de criptografia principal que você deseja usar e, em seguida, selecione o compartimento da chave de criptografia principal e a chave de criptografia principal. 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 do pod: Se você tiver selecionado Rede de pods nativa da VCN como o Tipo de Rede e Gerenciado como o Tipo de Nó, especifique como os pods no pool de nós gerenciados se comunicam entre si usando uma sub-rede de pod:
        • Compartimento de sub-rede: O compartimento no qual reside a sub-rede do 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ê especificar (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 (os 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, selecione 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 gerenciados, até um limite de 256. O limite de 256 é o número máximo de endereços IP que podem ser atribuídos a um nó de trabalho. Selecione uma forma que suporte anexos de VNIC suficientes e certifique-se de que a capacidade do IP do pod seja dimensionada corretamente usando os valores ipCount configurados para os perfis de VNIC secundários. Se você definir Recursos do Aplicativo em perfis de VNIC secundários, um pod poderá solicitar um único Recurso do Aplicativo para fixar em um perfil selecionado e deverá incluir a tolerância necessária para a mancha do nó. Se você implantar pods com várias interfaces, anexe interfaces adicionais usando Multus e NADs e não combine anotações de rede Multus com solicitações de Recurso de Aplicativo no nível do pod na mesma especificação do pod. Para obter mais informações, consulte Número Máximo de VNICs e Pods Suportados por Diferentes Formas e Anexando Várias VNICs Secundárias para Rede de Pods.

        Observe que os pools de nós que expõem os Recursos do Aplicativo são contaminados para impedir que pods sem solicitações explícitas do Recurso do Aplicativo sejam programados nesses nós. Os pods que solicitam um Recurso de Aplicativo devem incluir uma tolerância correspondente.

        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 gerenciados ou selecione Opções avançadas e especifique alternativas da seguinte forma:

      • Cordão e drenagem: Especifique quando e como conectar e drenar nós gerenciados antes de fazer shutdown ou encerrá-los.

        • Período de tolerância (minutos) da remoção: o período de tempo que permite conectar e drenar nós de trabalho antes de fazer shutdown ou encerrá-los. Aceite o padrão (60 minutos, que é o máximo) 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 conectar nós de trabalho e drená-los de suas cargas de trabalho. Para desligar ou encerrar nós de trabalho imediatamente, sem cordonamento e drenagem, especifique 0 minutos.
        • Forçar encerramento após o período de tolerância: ao substituir nós ou excluir nós no pool de nós, se os nós de trabalho devem ser encerrados no final do período de tolerância de remoção, mesmo que eles não tenham sido conectados e drenados com sucesso. Por padrão, esta opção não está selecionada.
        • Forçar ação após o período de tolerância: ao executar tarefas de manutenção em nós de trabalho (como reinicializar um nó e substituir o volume de inicialização de um nó), se a ação deve ser executada no final do período de tolerância de remoção, mesmo que o nó de trabalho não tenha sido conectado e drenado com sucesso. Por padrão, esta opção não está selecionada.

        Os pools de nós que contêm nós de trabalho que não podem ser submetidos a shutdown ou 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 shutdown ou encerramento é definido como Com falha e a operação é cancelada. Para obter mais informações, consulte Monitorando Clusters.

        Para obter mais informações, consulte Cordonando e Drenando Nós Gerenciados Antes de Encerrar ou Encerrar.

      • Script de inicialização: (Opcional) Um script para cloud-init a ser executado em cada instância que hospeda nós gerenciados 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 da seguinte forma:
        • 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 selecionar Fazer Download para fazer download de um modelo de script cloud-init. O arquivo submetido a download 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.

      • Rótulos do Kubernetes: (Opcional) um ou mais rótulos (além de um rótulo padrão) para adicionar a nós de trabalhador no pool para ativar o direcionamento de cargas de Trabalho em pools de nó 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 de pool de nós e Tags de nós: (Opcional) Uma ou mais tags para adicionar ao pool de nós e para calcular instâncias que hospedam nós de trabalho no pool de nós. A marcação permite agrupar recursos diferentes entre compartimentos e também permite anotar recursos com seus próprios metadados. Consulte Marcando com Tag Recursos Relacionados ao Cluster do Kubernetes.
      • Adicionar uma chave SSH: (Opcional) Gere um par da chave ou faça upload da parte da chave pública que você deseja usar para acesso SSH a cada nó no pool do nó. 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 você não pode usar SSH para acessar diretamente qualquer nó de trabalho em sub-redes privadas (consulte Estabelecendo Conexão com Nós Gerenciados em Sub-redes Privadas Usando SSH).
      • Cluster de computação: (Opcional) Especifique um cluster de computação para o pool de nós gerenciados. Selecione o compartimento que contém o cluster de computação e selecione o cluster de computação. O cluster de computação deve estar ativo. Você só pode especificar um cluster de computação ao criar o pool de nós gerenciados. Você não pode adicionar, remover ou alterar o cluster de computação posteriormente. Consulte Usando Clusters de Computação para Provisionar Nós Gerenciados.

9. 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 disponibilização no qual serão colocados nós virtuais.
        • Domínios de falha: (Opcional) Um ou mais domínios de falha no domínio de disponibilidade no qual os nós virtuais serão colocados.

        Quando os nós virtuais são criados, eles são distribuídos o mais uniformemente possível nos domínios da disponibilidade e nos domínios da falha selecionados. Considere as seguintes recomendações:

        • Defina Contagem de nós como no mínimo três. Em regiões com vários domínios de disponibilidade, distribua nós entre os domínios de disponibilidade. Em regiões com um único domínio de disponibilidade, distribua nós entre os domínios de falha.
        • Não especifique domínios de falha (em outras palavras, deixe Domínios de falha vazios) para permitir que os nós virtuais criem pods em qualquer domínio de falha que tenha capacidade de computação disponível. Essa abordagem é recomendada se você não precisar de controle detalhado sobre o posicionamento e quiser evitar possíveis restrições de capacidade.
        • Para suportar alta disponibilidade, especifique três linhas para configuração de posicionamento do nó. Em regiões com vários domínios de disponibilidade, tenha uma linha por domínio de disponibilidade. Em regiões com um único domínio de disponibilidade, tenha uma linha por domínio de falha.
      • Contagem de nós: O número de nós virtuais a criar no pool de nó virtual, colocado nos domínios de disponibilidade que você seleciona e na sub-rede regional (recomendado) ou sub-rede específica do AD que você especifica 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 na 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:
        • Compartimento de sub-rede: O compartimento no qual reside a sub-rede do nó virtual.
        • Sub-rede: Uma sub-rede regional (recomendada) ou sub-rede específica do AD configurada para hospedar nós virtuais. Se você especificou sub-redes de balanceadores de carga, as sub-redes de nó virtual deverão ser diferentes. As sub-redes especificadas podem ser privadas (recomendadas) ou públicas e podem ser regionais (recomendadas) 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 de 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 de, ou também, aquelas definidas para listas de segurança (os 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 em nós virtuais usam a rede de pods nativa da VCN. Especifique como os pods no pool de nós se comunicam entre si usando uma sub-rede de pod:
        • Compartimento de sub-rede: O compartimento no qual reside a sub-rede do pod.
        • 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 de pod e a sub-rede de 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ê especificar (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 (os 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 selecione Opções avançadas e especifique alternativas da seguinte forma:

      • Tags de pool de nós: (Opcional) Uma ou mais tags para adicionar ao pool de nós virtuais. A marcação permite agrupar recursos diferentes entre compartimentos e também permite anotar recursos com seus próprios metadados. Consulte Marcando com Tag Recursos Relacionados ao Cluster do Kubernetes.
      • Rótulos do Kubernetes: (Opcional) um ou mais labels (além de um label padrão) a serem acrescentados a nós virtuais no pool do nó virtual para ativar o direcionamento de cargas de Trabalho em pools de nó específicos, Para obter mais informações, consulte Atribuindo Pods a Nós na documentação do Kubernetes.
      • Taints do Kubernetes: (Opcional) Um ou mais taints a serem adicionados a nós virtuais no pool de nós virtuais. Os taints permitem que os nós virtuais repelem pods, garantindo assim que os pods não sejam executados em nós virtuais em um pool de nós virtuais específico. Observe que você só pode aplicar taints a nós virtuais. Para obter mais informações, consulte Atribuindo Pods a Nós na documentação do Kubernetes.
10. Selecione Próximo para revisar os detalhes informados para o novo cluster.
11. Se você não tiver selecionado nenhum dos recursos de cluster aprimorados e quiser criar o novo cluster como um cluster básico em vez de como um cluster aprimorado, escolha a opção Criar um cluster Básico na página Revisar e criar. Consulte Trabalhando com Clusters Aprimorados e Clusters Básicos.

12. Selecione Criar cluster para criar o novo cluster agora.

    O Kubernetes Engine começa a criar o cluster com o nome especificado.

    Se você tiver especificado detalhes para um ou mais pools de nós, o Serviço Kubernetes Engine criará:

    • pools de nós com os nomes especificados
    • nós de trabalho com nomes gerados automaticamente (os nomes de nós gerenciados têm o formato oke-c<part-of-cluster-OCID>-n<part-of-node-pool-OCID>-s<part-of-subnet-OCID>-<slot>; os nomes de nós virtuais são iguais ao endereço IP privado do nó)

    Não altere os nomes dos nós de trabalhogerados automaticamente.

    Observe que, em vez de criar o novo cluster imediatamente, você pode criá-lo posteriormente usando o Resource Manager e o Terraform, selecionando Salvar como pilha para salvar a definição de recurso como uma configuração do Terraform. Para obter mais informações sobre como salvar pilhas de definições de recursos, consulte Criando uma Pilha em uma Página de Criação de Recursos.

13. Selecione Close para retornar à Console.

Inicialmente, o novo cluster aparece na Console com o status Criando. Quando o cluster tiver sido criado, ele terá o status Ativo.

O Kubernetes Engine também cria um arquivo de configuração kubeconfig do Kubernetes que é usado para acessar o cluster usando o kubectl.