Saiba como Criar uma Topologia do Kubernetes na Nuvem

As empresas estão cada vez mais implantando cargas de trabalho nativas da nuvem em contêineres leves. Em um ambiente de produção, você precisa de uma forma para gerenciar os containers e assegurar que não haja período de indisponibilidade. O Kubernetes é um mecanismo de orquestração de código aberto para gerenciar aplicativos e serviços conteinerizados.

O Oracle Cloud Infrastructure Container Engine for Kubernetes é um serviço gerenciado, escalável e altamente disponível que você pode usar para implantar seus aplicativos conteinerizados para clusters do Kubernetes na nuvem.

Arquitetura

A arquitetura de uma topologia baseada em Kubernetes na nuvem depende de fatores como se as cargas de trabalho conteinerizadas devem estar acessíveis pela internet pública, do tamanho e do número de pools de nós, e dos requisitos de tolerância a falhas de suas cargas de trabalho.

O diagrama a seguir mostra uma arquitetura de referência de um cluster do Kubernetes em uma região do Oracle Cloud Infrastructure que contém vários domínios de disponibilidade.

A arquitetura contém os seguintes componentes:

• Rede virtual na nuvem (VCN): Todos os recursos da topologia estão em uma única VCN.
• Sub-redes:

  A VCN nesta arquitetura contém quatro sub-redes, dois públicos e duas privadas. Uma das sub-redes públicas é para o host bastion; a outra é para o balanceador de carga com acesso à Internet. Das duas sub-redes privadas, uma é para um host admin que contém as ferramentas necessárias para gerenciar o cluster do Kubernetes. A outra sub-rede privada é para os nós do cluster do Kubernetes.

  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. Você pode usar as sub-redes para recursos que implantar em 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:

  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 mostra dois nós do balanceador de carga, cada um em um domínio de disponibilidade distinto.

• 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. Na arquitetura de referência, o host admin 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 worker do Kubernetes:

  Os nós de trabalho do Kubernetes são instâncias de computação nas quais você pode implantar seus aplicativos conteinerizados. Todos os nós worker nesta arquitetura de referência estão em um único pool de nós e estão anexados a uma sub-rede privada. É possível criar vários pools de nós, se necessário.

  Os nós worker na arquitetura de referência não estão acessíveis diretamente da internet pública. Os usuários dos aplicativos conteinerizados podem acessá-los por meio do balanceador de carga. Os administradores podem acessar os nós dos colaboradores 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. Os nós mestres do Kubernetes são executados na tenancy do Oracle e não são mostrados.

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, conforme mostrado na arquitetura a seguir.

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.