Crie os Componentes de sua Topologia

Revise as opções de arquitetura para projetar a rede para a topologia do Kubernetes, decida se precisa de hosts bastion e admin e projetar os pools de nós.

Projetar a Rede

Decida os requisitos de acesso à equipe de suas aplicações conteinerizadas e determine os recursos de rede necessários.

Considere os requisitos de escala da sua carga de trabalho ao decidir o tamanho da rede, ou seja, as faixas de CIDR para a VCN e as sub-redes.

Anexe os nós worker a uma sub-rede distinta na VCN. Use sub-redes separadas para os outros recursos, como os nós do balanceador de carga, o host bastion e o host admin.

A abordagem recomendada é anexar os nós de trabalho do Kubernetes a uma sub-rede privada. Cada nó do colaborador tem apenas um endereço IP privado. Use um balanceador de carga (interno ou público) para distribuir o tráfego aos nós do worker. Para ativar os nós do colaborador para iniciar o acesso aos hosts na internet pública, use um gateway NAT.

Se você pretende criar serviços do tipo NodePort, anexe os nós worker do Kubernetes a uma sub-rede pública. O tráfego de/para os nós é roteado por meio do gateway de internet. Cada nó do colaborador tem um endereço IP público e um endereço privado. Você deve configurar explicitamente as regras de segurança para permitir o acesso aos nós do colaborador pela internet pública.

Você pode usar um gateway de serviço para rotear qualquer tráfego dos nós de trabalho para os outros serviços do Oracle Cloud (como o Oracle Cloud Infrastructure Object Storage ) dentro da região.

Restringir Acesso Administrativo

Considere usar um host bastion e um host admin para acessar e gerenciar sua topologia na nuvem.

Para proteger os nós de trabalho do Kubernetes contra acesso não autorizado de fora da nuvem, isolemos em uma sub-rede que não tem uma rota para e da internet pública.

Implante um host bastion e use-o como o único ponto de entrada para conexões SSH com outras instâncias de computação da topologia, incluindo os nós do colaborador. Para segurança aprimorada, convém permitir que o acesso SSH ao host bastion apenas a um conjunto conhecido de endereços IP fora da nuvem.

Para operações administrativas em sua topologia do Kubernetes na nuvem, considere criar um host admin na nuvem, com as ferramentas necessárias, como kubectl e Oracle Cloud Infrastructure CLI instaladas nele. Use o host bastion como um servidor jump para conexões SSH com o host admin.

Projetar os Pools de Nós

Um pool de nós é um grupo de instâncias de computação configuradas de forma idêntica em um cluster do Kubernetes. Os pools de nós permitem implantar e gerenciar aplicativos com diferentes requisitos de recursos de maneira eficiente. Você pode, por exemplo, criar um pool de nós separado para cada aplicativo ou serviço conteinerizado.

Decida o número de pools de nós a serem criados e o número de nós de trabalhadores em cada pool com base no número e no tamanho de suas cargas de trabalho conteinerizadas. No mínimo três nós worker são criados em cada pool. Todos os nós worker dentro de um determinado pool são criados usando a mesma forma, que você especifica.

Verificar Alta Disponibilidade

Certifique-se de que suas cargas de trabalho conteinerizadas na nuvem não sejam afetadas por quaisquer paralisações no data center.

As regiões do Oracle Cloud Infrastructure contêm um ou mais domínios de disponibilidade de tolerância a falhas. Os domínios de disponibilidade não compartilham infraestrutura como energia, refrigeração e rede interna. Uma falha em um domínio de disponibilidade provavelmente não afetará os outros dentro da mesma região. Em uma região que contém vários domínios de disponibilidade, os nós do colaborador são distribuídos pelos domínios de disponibilidade. Você pode anexar os nós a sub-redes regionais, que se estendem a todos os domínios de disponibilidade.

Cada domínio de disponibilidade contém três domínios de falha, cada um agrupamento isolado de hardware e infraestrutura. Um evento de falha ou manutenção de hardware que afeta um domínio de falha não afeta os recursos em outros domínios de falha. Nas regiões que têm um único domínio de disponibilidade, os nós do colaborador são distribuídos entre os domínios de falha no centro de dados.