Saiba Mais sobre a Configuração de um Cluster do Kubernetes na Nuvem

Uma topologia baseada em Kubernetes na nuvem contém vários componentes, incluindo recursos de rede, instâncias de computação e nós Kubernetes. Para implantar e gerenciar essa topologia complexa de maneira eficiente, defina sua infraestrutura de nuvem como código (IaC) nos arquivos de configuração do Terraform.

Para alterar a topologia, faça a versão dos módulos Terraform apropriados, atualize as definições de recursos e aplique a configuração revisada. Quando necessário, você pode reverter para uma versão anterior da infraestrutura facilmente.

Use os blocos de construção do Terraform fornecidos nesta solução para implantar a infraestrutura necessária para um ambiente Kubernetes baseado na nuvem.

Antes de Começar

Antes de começar a criar sua topologia do Kubernetes no Oracle Cloud, saiba as opções de arquitetura e compreender os componentes da arquitetura.

Consulte Saiba mais sobre a criação de uma topologia do Kubernetes para aplicativos conteinerizados na nuvem.

Arquitetura

A topologia de amostra que esta solução fornece o código Terraform para conter uma rede virtual na nuvem (VCN) única com os recursos necessários de rede e Kubernetes, tudo em uma única região do Oracle Cloud Infrastructure.

A arquitetura consiste nos seguintes componentes.

Observação:

O código Terraform inclui variáveis de entrada, que podem ser usadas para ajustar a arquitetura de acordo com os requisitos de rede das suas cargas de trabalho conteinerizadas, o tamanho e o número de pools de nós necessários, suas restrições de tolerância a falhas, e assim por diante.

• Rede virtual na nuvem (VCN)

  Todos os recursos da topologia estão em uma única rede. Você define o prefixo CIDR da rede (padrão: 10.0.0.0/16).

• Sub-redes
  A VCN na topologia de amostra contém quatro sub-redes. Defina os tamanhos das sub-redes.

  Sub-rede	Prefixo CIDR Padrão	Descrição
  Sub-rede Bastion	10.0.1.0/29	Uma sub-rede pública para o host bastion opcional.
  Sub-rede do balanceador de carga	10.0.2.32/27 se for público (10.0.2.0/27 se privado)	Uma sub-rede para os nós do balanceador de carga. Você escolhe se a sub-rede é pública ou privada.
  Sub-rede admin.	10.0.1.8/29	Uma sub-rede privada para o host admin opcional, que contém as ferramentas necessárias para gerenciar o cluster do Kubernetes, como kubectl, helm e a CLI do Oracle Cloud Infrastructure.
  Sub-rede de nós de trabalho	10.0.64.0/18	Uma sub-rede para os nós de trabalho do Kubernetes. Você escolhe se a sub-rede é pública ou privada.

  Todas as sub-redes são regionais; ou seja, elas abrangem todos os domínios de disponibilidade da região, abreviados como AD1, AD2 e AD3 no diagrama de arquitetura. Portanto, eles são protegidos contra falha no domínio de disponibilidade. É possível usar uma sub-rede regional para os recursos que você implanta para qualquer domínio de disponibilidade da região.

• Gateways de rede
  • Gateway de serviço (opcional)

    O gateway de serviço permite que os recursos da VCN acessem os serviços do Oracle, como Oracle Cloud Infrastructure Object Storage, Oracle Cloud Infrastructure File Storage e Oracle Cloud Infrastructure Database privadamente; ou seja, sem expor o tráfego à internet pública. As conexões por meio do gateway de serviço podem ser iniciadas dos recursos dentro da VCN e não dos serviços com os quais os recursos se comunicam.

  • Gateway NAT (opcional)

    O gateway NAT permite que instâncias de computação conectadas a sub-redes privadas na VCN acessem a internet pública. As conexões por meio do gateway NAT podem ser iniciadas dos recursos dentro da VCN, e não da internet pública.

  • Gateway da Internet

    O gateway de internet permite a conectividade entre a internet pública e quaisquer recursos em sub-redes públicas dentro da VCN.

• Host de Bastion (opcional)

  O host bastion é uma instância de computação que serve como ponto de entrada para a topologia de fora da nuvem.

  O host bastion é provisionado normalmente em um DMZ. Ele permite que você proteja recursos confidenciais colocando-os em redes privadas que não podem ser acessadas diretamente de fora da nuvem. Você expõe um único ponto de entrada conhecido que pode auditar regularmente. Portanto, você evita expor os componentes mais confidenciais da topologia, sem comprometer o acesso a eles.

  O host bastion na amostra de topologia é anexado a uma sub-rede pública e tem um endereço IP público. Uma regra de segurança de entrada está configurada para permitir que as conexões SSH com o host bastion da internet pública. Para fornecer um nível adicional de segurança, você pode limitar o acesso SSH ao host bastion a partir de apenas um bloco específico de endereços IP.

  Você pode acessar instâncias do Oracle Cloud Infrastructure em sub-redes privadas por meio do host bastion. Para fazer isso, ative o encaminhamento de ssh-agent, que permite estabelecer conexão com o host bastion, em seguida, acesse o próximo servidor encaminhando as credenciais do computador. Você também pode acessar as instâncias na sub-rede privada usando o tunelamento SSH dinâmico. O túnel dinâmico fornece um proxy SOCKS na porta local, mas as conexões se originam do host remoto.

• Nós do balanceador de carga (não incluídos no código de amostra)

  Os nós do balanceador de carga interceptam e distribuem o tráfego para os nós disponíveis do Kubernetes executando seus aplicativos conteinerizados. Se os aplicativos tiverem que ser acessíveis pela internet pública, use balanceadores de carga públicos; caso contrário, use balanceadores de carga privados, que não têm um endereço IP público. A arquitetura não mostra nenhum nó do balanceador de carga.

• Host Admin (opcional)

  Usando um host administrativo, você pode evitar a instalação e a execução de ferramentas de gerenciamento de infraestrutura, como kubectl, helm e a CLI Oracle Cloud Infrastructure fora da nuvem. O host admin na amostra de topologia está em uma sub-rede privada e pode ser acessado por meio do host bastion. Para poder executar a CLI do Oracle Cloud Infrastructure no host admin, você deve designá-la como um principal da instância.

• nós de trabalho do Kubernetes

  Os nós de trabalho do Kubernetes são instâncias de computação nas quais você pode implantar seus aplicativos conteinerizados. Na topologia de amostra, todos os nós do worker estão em um único pool de nós e estão anexados a uma sub-rede privada. É possível personalizar o número de pools de nós, o tamanho de cada pool e se deseja usar uma sub-rede pública com base em seus requisitos.

  Se os nós do colaborador estiverem anexados a uma sub-rede privada, eles não poderão ser acessados diretamente da internet pública. Os usuários podem acessar as aplicações conteinerizadas por meio do balanceador de carga.

  Se você ativar o acesso SSH aos nós do worker, os administradores poderão criar conexões SSH nos nós do worker por meio do host bastion.

  A arquitetura mostra três nós do colaborador, cada um em um domínio de disponibilidade distinto na região: AD1, AD2 e AD3.

  Observação:

  Se a região na qual você deseja implantar seus aplicativos conteinerizados contiver um domínio de disponibilidade único, os nós trabalhadores serão distribuídos entre os domínios de falha (FD) dentro do domínio de disponibilidade.

Sobre Serviços e Permissões Necessários

Essa solução requer os seguintes serviços e permissões:

Serviço	Permissões Obrigatórias
Oracle Cloud Infrastructure Identity and Access Management	Gerenciar grupos e políticas dinâmicos.
Rede Oracle Cloud Infrastructure	Gerenciar VCNs, sub-redes, gateways de internet, gateways NAT, gateways de serviço, tabelas de rota e listas de segurança.
Oracle Cloud Infrastructure Compute	Gerenciar instâncias de computação.
Oracle Cloud Infrastructure Container Engine for Kubernetes	Gerenciar clusters e pools de nós. Consulte Configuração de Política para Criação e Implantação do Cluster.