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 explicitamente definidas e recursos de rede existentes usando o Serviço Container Engine for Kubernetes (OKE).

Para criar um cluster com definições configuradas explicitamente e recursos existentes de rede no worlkflow 'Criação Personalizada' usando o Container Engine for 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. Escolha um Compartimento no qual você tem permissão para trabalhar.
3. Na página Lista de Clusters, clique em Criar Cluster.
4. Na caixa de diálogo Criar Cluster, selecione Criação personalizada e clique em Submeter.

5. Na página Criar cluster, aceite os detalhes de configuração padrão para o novo cluster ou especifique alternativas da seguir:

   • Nome: O nome do novo cluster. Aceite o nome padrão ou digite um nome à sua escolha. Evite digitar 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 de plano de controle do 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).

6. Aceite os padrões para opções avançadas de cluster ou clique em Mostrar opções avançadas e defina as opções, conforme a seguir:

   1. Especifique se só permitirá a implantação de imagens do Oracle Cloud Infrastructure Registry que foram assinadas por chaves de criptografia principais 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. Especifique como criptografar os segredos do Kubernetes em armazenamento de valores-chave etcd do cluster:

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

      • Criptografe usando uma chave que você gerencia: Criptografe 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 em <compartment-name>: O vault que contém a chave de criptografia principal, na lista de vaults no compartimento especificado. Por padrão, <compartment-name> é o compartimento no qual você está criando o cluster, mas você pode selecionar outro compartimento clicando em Alterar compartimento.
        • Escolher uma chave em <compartment-name>: O nome da chave de criptografia principal, na lista de chaves no compartimento especificado. Por padrão, <compartment-name> é o compartimento no qual você está criando o cluster, mas você pode selecionar outro compartimento clicando em Alterar 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 principal, 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. (Versões do Kubernetes anteriores à 1.25) Especifique se deseja controlar as operações que os pods podem executar no cluster impondo políticas de segurança de 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 Serviço Container Engine for Kubernetes.
      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. (Somente clusters aprimorados) Especifique como gerenciar complementos de cluster. Selecione Configurar complementos de cluster para ativar ou desativar complementos específicos, selecionar versões de complementos, aceitar e desativar atualizações automáticas da Oracle e gerenciar personalizações específicas de complementos. Selecione o complemento de cluster apropriado e defina opções conforme apropriado. Consulte Configurando Complementos do Cluster.
   5. Especifique se deseja adicionar Tags de cluster ao cluster, Tags de balanceador de carga inicial aos balanceadores de carga criados pelos serviços Kubernetes do tipo LoadBalancer e Tags de volume em blocos iniciais aos volumes em blocos criados pelas reivindicações de volume persistentes do Kubernetes. O Tagging permite que você agrupe recursos diferentes entre compartimentos e também permite que você anote recursos com seus próprios metadados. Consulte Marcando Recursos Relacionados ao Cluster do Kubernetes.

7. Clique em Próximo e especifique os recursos de rede existentes a serem usados para o novo cluster na página Configuração de rede:

   • Tipo de rede: Especifique como os pods em execução nos nós do cluster se comunicam entre si, com os nós de 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 essa opção para conectar nós em um cluster do Kubernetes a sub-redes de pod em uma VCN do Oracle Cloud Infrastructure. Como resultado, os endereços IP de pod dentro de uma VCN são roteáveis diretamente de outras VCNs conectadas (pareadas) para essa VCN, de redes locais e da internet. Você poderá criar nós virtuais e nós gerenciados se selecionar essa opção. Consulte Usando o plug-in CNI da Rede de Pods Nativa da VCN do OCI para a rede de pods.
     • Sobreposição de canal: Selecione esta opção para encapsular a comunicação entre pods na rede de sobreposição de canal, uma rede virtual de sobreposição privada simples que atende aos requisitos do modelo de rede do Kubernetes anexando endereços IP a contêineres. Os pods na rede de sobreposição privada só estão acessíveis de outros pods do mesmo cluster. Você poderá criar nós gerenciados (mas não nós virtuais) se selecionar essa opção. Consulte Usando o plug-in CNI flannel para a rede de pods.
   • VCN em <compartment-name>: A rede virtual na nuvem existente que foi configurada para criação e implantação de clusters. Por padrão, <compartment-name> é o compartimento no qual você está criando o cluster, mas você pode selecionar outro compartimento clicando em Alterar Compartimento. Consulte Configuração da VCN.

   • Sub-redes LB de serviços do Kubernetes em <compartment-name>: Como opção, as sub-redes existentes que foram configuradas para hospedar balanceadores de carga. 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.

   • Sub-rede de ponto final da API do Kubernetes em <compartment-name>: Uma sub-rede regional para host do ponto final da API do Kubernetes do cluster. A sub-rede especificada pode ser pública ou privada. O ponto final da API do Kubernetes sempre recebe um endereço IP privado. Se você especificar uma sub-rede pública, terá a opção de expor o ponto final da API do Kubernetes à internet designando um endereço IP público ao ponto final (e também ao 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 NSGs ou para aquelas definidas para listas de segurança (Recomendamos NSGs). Para obter mais informações sobre as regras de segurança a serem especificadas para o NSG, consulte Regras de Segurança para o Ponto Final da API do Kubernetes.
   • Designar um endereço IP público ao ponto final da API: Se você selecionou uma sub-rede pública para o ponto final da API do Kubernetes, tem a opção de 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).

8. Aceite os padrões para opções avançadas de cluster ou clique em Mostrar Opções Avançadas e especifique alternativas, da seguinte maneira:

   • Bloco CIDR de serviço Kubernetes: O grupo disponível de endereços de rede que podem ser expostos como serviços Kubernetes (ClusterIPs), expresso como um único bloco IPv4 CIDR contíguo. Por exemplo, 10.96.0.0/16. O bloco CIDR especificado não deve se sobrepor ao bloco CIDR da VCN. Consulte Blocos CIDR e o Serviço Container Engine for Kubernetes.
   • Bloco CIDR de Pods: O grupo disponível de endereços de rede que podem ser alocados para pods em execução no cluster, expresso como um único bloco CIDRIPv4 CIDR de IPv4 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. Não especifique um bloco CIDR se você tiver selecionado rede de pod nativo da VCN como o Tipo de rede do cluster. Consulte Blocos CIDR e o Serviço Container Engine for Kubernetes.

9. Clique em Próximo e especifique os detalhes da configuração do primeiro pool de nós do cluster na páginaPools de Nós:

   • Nome: um nome à sua escolha para o novo pool de nós. Evite digitar informações confidenciais.
   • Compartimento: O compartimento no qual criar o novo pool de nós.
   • 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 pelo gerenciamento de nós gerenciados, tem a flexibilidade de configurá-los para atender aos seus requisitos específicos. Você é responsável por fazer upgrade do Kubernetes nos nós gerenciados e por gerenciar a capacidade do cluster.
     • Virtual: Selecione essa opção quando quiser se beneficiar de uma experiência 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 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 Container Engine for Kubernetes.

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

10. Se você tiver selecionado rede de pod nativo da VCN como Tipo de Rede e Gerenciado como Tipo de Nó ou se tiver selecionado Sobreposição de canal: como Tipo de Rede:

    1. Especifique detalhes de configuração para o pool de nós gerenciados:
       • Configuração de Posicionamento do 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 configuração do nó, o domínio de disponibilidade e o domínio de falha na configuração de posicionamento do pool de nós gerenciado 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.

         Opcionalmente, 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 do modo mais uniforme possível entre os domínios de disponibilidade e os 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 da forma mais uniforme possível em todos os domínios de falha desse domínio de disponibilidade.

       • 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.

         Somente as formas disponíveis em sua tenancy que são suportadas pelo Serviço Container Engine for Kubernetes 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 no pool de nós gerenciados. Uma imagem é um modelo de uma unidade de disco rígido virtual que determina o sistema operacional e outros softwares para o pool de nós gerenciado.

         Para alterar a imagem padrão, clique em Alterar imagem. Na janela Procurar todas as imagens, escolha uma Origem de 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 quando comparados às imagens da plataforma e às imagens personalizadas.

           Os nomes de imagem do OKE incluem o número 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 só contêm um sistema operacional Oracle Linux. Selecione uma imagem de plataforma se quiser que o Container Engine for Kubernetes 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 gerenciados, colocados nos domínios de disponibilidade selecionados e na sub-rede regional (recomendado) ou na 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 NSGs ou para aquelas definidas para listas de segurança (Recomendamos NSGs). 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ó gerenciados:

         • 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 precisará 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 que contêm a chave principal de criptografia que você deseja usar e, em seguida, selecione o compartimento 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 volumes de criptografia com chaves criptografadas usando o algoritmo Rivest-Shamir-Adleman (RSA). 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: Se você selecionou rede de pod nativo da VCN como 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:
         • Sub-rede: Uma sub-rede regional configurada para hospedar pods. A sub-rede de pod especificada pode ser privada (recomendada) ou pública. 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 NSGs ou para aquelas definidas para listas de segurança (Recomendamos NSGs). 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 e Pods de Trabalho.

         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 gerenciado, 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 de 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 gerenciados ou clique em Mostrar opções avançadas e especifique alternativas, da seguinte maneira:

       • Cordon e drenagem: Especifique quando e como colocar e drenar nós gerenciados 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 essa opção se não quiser que os nós de trabalho que não foram conectados e drenados com sucesso sejam encerrados no final do período de tolerância de despejo. 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 desligamento é definido como Falha e a operação de desligamento é 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 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 escrito 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ê não tiver escrito scripts cloud-init anteriormente para inicializar nós de trabalho em clusters criados pelo Container Engine for Kubernetes, talvez seja útil clicar em Fazer Download do Modelo de Script Personalizado Cloud-Init. O arquivo baixado contém a lógica padrão fornecida pelo Container Engine for Kubernetes. Você pode adicionar sua própria lógica personalizada antes ou depois da lógica padrão, mas não modificar a lógica padrão. Para obter exemplos, consulte Exemplos de Casos de Uso para Scripts Personalizados de Inicialização da Nuvem.

       • 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 em 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ó: (Opcional) Uma ou mais tags a serem adicionadas ao pool de nós e para calcular instâncias que hospedam nós de trabalho no pool de nós. O Tagging permite que você agrupe recursos diferentes entre compartimentos e também permite que você anote 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 Serviço Container Engine for Kubernetes 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 quaisquer nós de trabalho em sub-redes privadas (consulte Estabelecendo Conexão com Nós Gerenciados em Sub-redes Privadas Usando SSH).

11. Se você selecionou Virtual como o Tipo de Nó:

    1. Especifique os detalhes de configuração do pool de nós virtuais:
       • 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 de 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 Serviço Container Engine for Kubernetes 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 Pod: Os pods em execução em nós virtuais usam a 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 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 NSGs ou para aquelas definidas para listas de segurança (Recomendamos NSGs). 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 e Pods de Trabalho.

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

       • Comunicação de nó virtual:
         • Sub-rede: Uma sub-rede regional (recommended) ou sub-rede específica do AD configurada para hospedar nós virtuais. Se você especificou sub-redes de balanceador de carga, as sub-redes de nó virtual deverão ser diferentes. As sub-redes especificadas podem ser privadas (recommended) ou públicas, e podem ser regionais (recommended) 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.
       • Configuração de Posicionamento do 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 nas quais colocar nós virtuais.

         Quando os nós virtuais são criados, eles são distribuídos da maneira mais uniforme possível nos domínios de disponibilidade e 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 da maneira mais uniforme possível em todos os domínios de falha desse domínio de disponibilidade.

    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 Tagging permite que você agrupe recursos diferentes entre compartimentos e também permite que você anote recursos com seus próprios metadados. Consulte Marcando Recursos Relacionados ao Cluster do Kubernetes.
       • Rótulos e restrições do Kubernetes: (Opcional) Ative o direcionamento de cargas de trabalho em pools de nós específicos adicionando labels e restrições 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 direcionamento de cargas de trabalho em pools de nós específicos.
         • Dicas: Uma ou mais dicas para adicionar a nós virtuais no pool de nós virtuais. Os túneis permitem que nós virtuais repelam 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 restrições a nós virtuais.

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

12. (Opcional) Clique em Outro pool de nós e especifique os detalhes de configuração para um segundo pool de nós e pools de nós subsequentes no cluster.

    Se você definir vários pools de nós em um cluster, poderá hospedar todos eles em uma única sub-rede específica do AD. No entanto, a melhor prática é hospedar pools de nós distintos para um cluster em uma sub-rede regional (recomendado) ou em sub-redes específicas do AD (uma em cada domínio de disponibilidade da região).

13. Clique em Próximo para revisar os detalhes informados para o novo cluster.
14. Se você não tiver selecionado nenhum dos recursos de cluster aprimorados e quiser criar o novo cluster como cluster básico, em vez de como cluster aprimorado, escolha a opção Criar um cluster Básico na página Revisar. Consulte Trabalhando com Clusters Aprimorados e Clusters Básicos.

15. Clique em Criar cluster para criar o novo cluster agora.

    O serviço Container Engine for Kubernetes 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 Container Engine for Kubernetes criará:

    • pools de nós com os nomes especificados
    • nós de trabalho com nomes gerados automaticamente (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>, 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, clicando em Salvar como pilha para salvar a definição do 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 com Base em uma Página de Criação de Recurso.

16. Clique em Fechar 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 Container Engine for Kubernetes também cria um arquivo de configuração kubeconfig do Kubernetes que é usado para acessar o cluster suando o kubectl.