Implemente Kubernetes sem Servidor com Nós Virtuais do OCI Kubernetes Engine
Ambos os modos de operação podem oferecer suporte a aplicativos básicos até o mais essencial. Com Nós Virtuais, as operações do Kubernetes são simplificadas e fornecem o melhor desempenho de preço. A troca entre Nós Gerenciados e Nós Virtuais é com Nós Gerenciados; você tem maior controle sobre sua infraestrutura de nós. Você pode configurar seus recursos do Kubernetes para usar HostPort e HostNetwork ou executar DaemonSets e outras opções que possam ser necessárias para seus aplicativos ou ferramentas. Na maioria dos casos de uso, essas opções não são necessárias.
Os Nós Virtuais fazem mais sentido quando você não precisa ajustar o controle sobre a execução e o gerenciamento de seus contêineres. Se seus aplicativos exigirem a configuração da infraestrutura do nó que está indisponível com Nós Virtuais, use Nós Gerenciados.
Arquitetura
Para integrar o cluster do OKE ao OCI Vault, o Operador de Segredos Externos é implantado no cluster do OKE. Isso permite que você defina um recurso SecretStore mapeado para o OCI Vault para conter a senha do banco de dados. Depois que o recurso SecretStore for mapeado, o cluster do OKE poderá acessar a senha como segredo do Kubernetes. Uma atribuição do OCI Identity and Access Management com permissão para ler no OCI Vault permite que o pod acesse o segredo. A atribuição está associada à conta de serviço do Kubernetes usada na definição do pod para conceder a ele acesso para leitura no OCI Vault.
O diagrama a seguir ilustra essa arquitetura de referência.
Descrição da ilustração k8n-virtual-nodes.png
A arquitetura tem os seguintes componentes:
- Tenancy
Uma tenancy é uma partição segura e isolada que a Oracle configura no Oracle Cloud quando você se inscreve no Oracle Cloud Infrastructure. Você pode criar, organizar e administrar seus recursos no Oracle Cloud em sua tenancy. Uma tenancy é sinônimo de uma empresa ou organização. Normalmente, uma empresa terá uma única locação e refletirá sua estrutura organizacional dentro dessa locação. Uma única tenancy geralmente é associada a uma única assinatura, e uma única assinatura geralmente só tem uma tenancy.
- Região
Região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, denominada domínios de disponibilidade. As regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou até mesmo continentes).
- Compartimento
Os compartimentos são partições lógicas entre regiões em uma tenancy do Oracle Cloud Infrastructure. Use compartimentos para organizar seus recursos no Oracle Cloud, controlar o acesso aos recursos e definir cotas de uso. Para controlar o acesso aos recursos em um determinado compartimento, você define políticas que especificam quem pode acessar os recursos e quais ações eles podem executar.
- Domínios de disponibilidade
Domínios de disponibilidade são data centers stand-alone e independentes dentro de uma região. Os recursos físicos de cada domínio de disponibilidade são isolados dos recursos de outros domínios de disponibilidade, o que oferece tolerância a falhas. Os domínios de disponibilidade não compartilham infraestrutura como energia ou refrigeração ou a rede interna do domínio de disponibilidade. Portanto, uma falha em um domínio de disponibilidade não deve afetar os outros domínios de disponibilidade na região.
- Domínios de falha
Um domínio de falha é um agrupamento de hardware e infraestrutura dentro de um domínio de disponibilidade. Cada domínio de disponibilidade tem três domínios de falha com energia e hardware independentes. Quando você distribui recursos entre vários domínios de falha, seus aplicativos podem tolerar falha no servidor físico, manutenção do sistema e falhas de energia dentro de um domínio de falha.
- Rede virtual na nuvem (VCN) e sub-redes
Uma VCN é uma rede personalizável definida por software que você configura em uma região do Oracle Cloud Infrastructure. Como as redes tradicionais de data center, as VCNs oferecem controle sobre seu ambiente de rede. Uma VCN pode ter vários blocos CIDR não sobrepostos que você pode alterar após a criação da VCN. Você pode segmentar uma VCN em sub-redes, com escopo definido para uma região ou para um domínio de disponibilidade. Cada sub-rede consiste em um intervalo contíguo de endereços que não se sobrepõem a outras sub-redes da VCN. Você pode alterar o tamanho de uma sub-rede após a criação. Uma sub-rede pode ser pública ou privada.
- Balanceador de carga
O serviço Oracle Cloud Infrastructure Load Balancing fornece distribuição automatizada de tráfego de um único ponto de entrada para vários servidores no back-end.
- Gateway de internet
O gateway de internet permite o tráfego entre as sub-redes públicas em uma VCN e a internet pública.
- Gateway de conversão de endereço de rede (NAT)
Um gateway NAT permite que recursos privados em uma VCN acessem hosts na internet, sem expor esses recursos a conexões de internet de entrada.
- Gateway de serviço
O gateway de serviço fornece acesso de uma VCN a outros serviços, como o Oracle Cloud Infrastructure Object Storage. O tráfego da VCN para o serviço Oracle percorre a malha da rede Oracle e não passa pela internet.
- Vault
O Oracle Cloud Infrastructure Vault permite gerenciar centralmente as chaves de criptografia que protegem seus dados e as credenciais secretas usadas para proteger o acesso aos seus recursos na nuvem. Você pode usar o serviço Vault para criar e gerenciar vaults, chaves e segredos.
- Registro
O Oracle Cloud Infrastructure Registry é um registro gerenciado pela Oracle que permite simplificar seu desenvolvimento para o workflow de produção. O registro facilita o armazenamento, o compartilhamento e o gerenciamento de artefatos de desenvolvimento, como imagens do Docker. A arquitetura altamente disponível e escalável do Oracle Cloud Infrastructure garante que você possa implantar e gerenciar seus aplicativos de forma confiável.
- Lista de segurança
Para cada sub-rede, você pode criar regras de segurança que especifiquem a origem, o destino e o tipo de tráfego que deve ser permitido dentro e fora da sub-rede.
- Tabela de roteamento
As tabelas de roteamento virtual contêm regras para rotear o tráfego de sub-redes para destinos fora de uma VCN, geralmente por meio de gateways.
- Mecanismo do Kubernetes do OCI
O Oracle Cloud Infrastructure Kubernetes Engine (Kubernetes Engine ou OKE) é um serviço totalmente gerenciado, escalável e altamente disponível que você pode usar para implantar seus aplicativos em contêineres na nuvem. Você especifica os recursos de computação necessários, e o serviço Kubernetes Engine os provisiona no Oracle Cloud Infrastructure em uma tenancy existente. O OKE usa o Kubernetes para automatizar a implantação, o dimensionamento e o gerenciamento de aplicativos em contêineres entre clusters de hosts.
- Oracle MySQL Database Service
O Oracle MySQL Database Service é um serviço de banco de dados da Oracle Cloud Infrastructure (OCI) totalmente gerenciado que permite aos desenvolvedores desenvolver e implementar rapidamente aplicativos seguros e nativos na nuvem. Otimizado e disponível exclusivamente na OCI, o Oracle MySQL Database Service é 100% construído, gerenciado e suportado pelas equipes de engenharia da OCI e da MySQL.
O Oracle MySQL Database Service tem um mecanismo de análise integrado de alto desempenho (HeatWave) para executar análises sofisticadas em tempo real diretamente em um banco de dados MySQL operacional.
- Controlador de entrada
Um controlador de Entrada (ing) é um componente que é executado em um cluster do Kubernetes e gerencia os recursos de Entrada. Ele recebe tráfego da rede externa, o roteia para o serviço correto e executa balanceamento de carga e terminação SSL. O controlador de Entrada normalmente é executado como um pod separado no cluster e pode ser dimensionado independentemente dos serviços que gerencia.
- Segredos do Kubernetes
Os segredos do Kubernetes podem incluir dados de configuração confidenciais, como tokens de autenticação, senhas e chaves SSH. Os segredos permitem que você controle dados confidenciais e reduz o risco de expor os dados a usuários não autorizados. O Oracle Container Engine for Kubernetes suporta a criptografia de segredos do Kubernetes em repouso.
- Operador de Segredos Externos
O Kubernetes External Secrets Operator integra o Oracle Container Engine for Kubernetes ao Oracle Cloud Infrastructure Vault. O operador lê informações de APIs externas e injeta automaticamente os valores em um Segredo do Kubernetes.
- SecretStore
O plano de controle do cluster do Kubernetes armazena dados de configuração confidenciais (como tokens de autenticação, certificados e credenciais) como objetos secretos do Kubernetes em
etcd.Etcdé um armazenamento de chave/valor distribuído de código-fonte aberto que o Kubernetes usa para coordenação de cluster e gerenciamento de estado. Nos clusters do Kubernetes criados pelo Container Engine for Kubernetes, oetcdgrava e lê os dados de/para volumes de armazenamento em blocos no serviço Oracle Cloud Infrastructure Block Volumes. Por padrão, a Oracle criptografa dados em volumes em blocos em repouso, incluindo segredosetcde Kubernetes. A Oracle gerencia essa criptografia padrão usando uma chave de criptografia mestra, sem exigir nenhuma ação da sua parte. Para obter controle adicional sobre o ciclo de vida da chave de criptografia principal e como ela é usada, você mesmo pode optar por gerenciar a chave de criptografia principal, em vez de fazer com que a Oracle a gerencie para você.Quando você cria um novo cluster, pode especificar que os segredos do Kubernetes em
etcdsejam criptografados usando o Oracle Key Management Cloud Service. - Podologia
Um pod é um grupo de um ou mais contêineres e seu armazenamento compartilhado, além de quaisquer opções específicas sobre como eles devem ser executados juntos. Normalmente, os contêineres em um pod compartilham a mesma rede e espaço de memória e podem acessar volumes compartilhados para armazenamento. Esses recursos compartilhados permitem que os contêineres em um pod se comuniquem internamente de forma integrada, como se estivessem instalados em um único host lógico.
- Nó Virtual
Um Nó Virtual é uma abstração de software de um nó real. Os Nós Virtuais são implantados na tenancy da OCI e são totalmente monitorados e gerenciados pela OCI.
Recomendações
- VCN
Ao criar uma VCN, determine o número de blocos CIDR necessários e o tamanho de cada bloco com base no número de recursos que você planeja anexar a sub-redes na VCN. Use blocos CIDR que estejam dentro do espaço de endereço IP privado padrão.
Selecione blocos CIDR que não se sobreponham a nenhuma outra rede (no Oracle Cloud Infrastructure, em seu data center local ou em outro provedor de nuvem) para a qual você pretende configurar conexões privadas.
Depois de criar uma VCN, você poderá alterar, adicionar e remover seus blocos CIDR.
Ao projetar as sub-redes, considere seus requisitos de fluxo de tráfego e segurança. Anexe todos os recursos dentro de uma camada ou atribuição específica à mesma sub-rede, que pode servir como um limite de segurança.
Usar sub-redes regionais.
- Grupos de segurança de rede (NSGs)
Você pode usar NSGs para definir um conjunto de regras de entrada e saída que se aplicam a VNICs específicas. Recomendamos o uso de NSGs em vez de listas de segurança, porque os NSGs permitem que você separe a arquitetura de sub-rede da VCN dos requisitos de segurança do seu aplicativo.
Você pode usar NSGs para definir um conjunto de regras de entrada e saída que se aplicam a VNICs específicas. Recomendamos o uso de NSGs em vez de listas de segurança, porque os NSGs permitem que você separe a arquitetura de sub-rede da VCN dos requisitos de segurança do seu aplicativo.
- Largura de banda do balanceador de carga
Ao criar o balanceador de carga, você pode selecionar uma forma predefinida que forneça uma largura de banda fixa ou especificar uma forma personalizada (flexível), na qual você define uma faixa de largura de banda e permite que o serviço dimensione a largura de banda automaticamente com base nos padrões de tráfego. Com qualquer uma das abordagens, você pode alterar a forma a qualquer momento após criar o balanceador de carga.
Considerações
Considere o seguinte ao trabalhar com Nós Virtuais.
Para começar com Nós Virtuais, primeiro crie um cluster do OCI Kubernetes Engine com um Pool de Nós Virtuais ou adicione um Pool de Nós Virtuais a um cluster existente do Kubernetes Engine (OKE).
- Selecione a forma e o posicionamento dos seus nós virtuais.
-
A forma determina o tipo de processadores, juntamente com a quantidade de recursos de CPU e memória que podem ser alocados para cada pod. Cada pod pode alocar até os limites de memória e CPU da forma selecionada.
-
Os Nós Virtuais dimensionarão os pods com a configuração do Horizontal Pod Autoscaler (HPA). Não há necessidade de configurar o Autoscaler do nó.
-
Você pode colocar seus Nós Virtuais em Domínios de Disponibilidade e Domínios de Falha específicos que sejam os mais ideais para suas necessidades de alta disponibilidade (HA). Para obter o nível máximo de redundância, coloque um Nó Virtual em cada domínio de falha dentro do domínio de disponibilidade do cluster do OKE.
-
Use labels de nó do Kubernetes para especificar o posicionamento de seus pods nos Nós Virtuais. Para obter uma distribuição uniforme de pods entre nós, use a restrição
PodTopologySpread.
-
-
Os Nós Virtuais usam a rede de pods nativos da VCN. O número de pods disponíveis no cluster é limitado pelo número de endereços IP disponíveis na sub-rede.
- O Native Pod Networking fornece a cada pod um endereço IP nativo às sub-redes da VCN, o que permite que cada pod se beneficie de recursos integrados de segurança de rede do OCI, como logs de Fluxo da VCN, políticas de roteamento, VTAP e grupos de segurança.
- Considere o uso de uma faixa de sub-rede que permita o número de pods e nós que você espera usar e dê espaço para crescimento.
- Defina Grupos de segurança de rede (NSGs) para limitar o tipo de tráfego que pode entrar e sair dos pods.
- Use logs de Fluxo da VCN para inspecionar todo o tráfego de rede entre pods ou use VTAP para capturar o tráfego de rede.
- Os pods em Nós Virtuais recebem acesso a outros serviços do OCI com identidade de carga de trabalho.
Há casos em que um pod pode precisar de acesso a outros serviços na OCI.
- Use a Identidade de Carga de Trabalho para conceder privilégios a pods em Nós Virtuais. O Workload Identity associa as atribuições do OCI Identity and Access Management a contas de serviço do Kubernetes designadas a pods.
- Os Nós Virtuais fornecem isolamento no nível do hipervisor para seu pod.
Vulnerabilidades de segurança podem potencialmente permitir que processos maliciosos dentro de um contêiner "escape" e afetem o kernel do nó, potencialmente derrubando o nó. O código malicioso também pode acessar dados na memória ou no armazenamento e exfiltrar os dados. Os dados exfiltrados podem potencialmente pertencer a outro tenant em um ambiente multitenant.
- O Virtual Node fornece isolamento no nível do hipervisor para seus pods. Um pod não compartilha computação, memória e rede com outros pods no cluster, mitigando a possibilidade de um nó inativo ou dados exfiltrados pertencentes a outro tenant causados por código malicioso.