Infraestrutura de Clusters OKE - Homologação

Introdução

O cluster OKE-STH-HML é dedicado ao ambiente de homologação, onde as aplicações são testadas e validadas antes de serem promovidas para os ambientes de produção. Este ambiente permite a validação completa de funcionalidades, desempenho e segurança das aplicações em condições próximas às de produção.

Cluster OKE-STH-HML – Arquitetura e Configuração

A seguir, está representada a arquitetura do cluster OKE-STH-HML, implantado na região sa-saopaulo-1 da OCI. A infraestrutura foi desenhada para garantir alta disponibilidade e resiliência, aproveitando múltiplos domínios de falha (Fault Domains) dentro da região.

Figura 1: Arquitetura Cluster OKE-STH-HML

×

Infraestrutura e Rede

O cluster OKE-STH-HML está implantado na região sa-saopaulo-1 da OCI, utilizando a VCN VCN-OKE-HML-STH (10.151.16.0/24). A arquitetura foi projetada seguindo as melhores práticas da OCI para Kubernetes, com recursos distribuídos entre três domínios de falha (FD1, FD2, FD3) para garantir alta disponibilidade e tolerância a falhas.

Subnets do Cluster OKE-STH-HML

Subnet	CIDR	Propósito
workers-STH-HML	10.151.16.0/26	Nós de trabalho Kubernetes (worker nodes)
ilb-STH-HML	10.151.16.64/28	Load balancer interno
operator-STH-HML	10.151.16.88/30	Operações de gestão do cluster
bastion-STH-HML	10.151.16.96/29	Acesso seguro ao cluster via bastion host
cp-STH-HML	10.151.16.104/29	Kubernetes Control Plane
fss-STH-HML	10.151.16.112/28	File Storage Service

Especificações do Kubernetes

• Versão do Kubernetes: v1.34.1
• Endpoint API privado: 10.151.16.108:6443
• Plugin de Rede (CNI): FLANNEL_OVERLAY

Capacidade Computacional

O cluster OKE-STH-HML possui dois node pools com as seguintes especificações:

Node Pool - workers

• Tipo de instância: VM.Standard.E5.Flex
• Capacidade computacional: 2 OCPUs (4 vCPUs)
• Memória RAM: 32 GB por nó
• Volume de boot: 100 GB
• Sistema Operacional: Oracle Linux 8
• Auto-scaling:
  • Habilitado
  • Tamanho inicial: 3 nós
  • Tamanho mínimo: 3 nós
  • Tamanho máximo: 5 nós

Node Pool - autoscaler

• Tipo de instância: VM.Standard.E5.Flex
• Capacidade computacional: 2 OCPUs (4 vCPUs)
• Memória RAM: 32 GB por nó
• Tamanho: 1 nó
• Propósito: Dedicado para o Cluster Autoscaler

Acesso ao Cluster

O endpoint da API do Kubernetes é privado e só pode ser acessado através de: - Um host bastion configurado - Uma estação de trabalho autorizada com acesso à subnet do endpoint da API

Configuração do acesso ao Cluster

Pré-requisitos

Para acessar o cluster OKE-STH-HML, é necessário atender aos seguintes requisitos:

• Ferramentas necessárias

  • Oracle Cloud Infrastructure CLI (versão 2.24.0 ou superior)
  • Kubectl - ferramenta de linha de comando para Kubernetes

• Acessos e permissões

  • Conexão VPN estabelecida com a rede corporativa
  • Credenciais OCI com permissões IAM adequadas para o cluster
  • Acesso de rede liberado para a subnet do Kubernetes API endpoint

• Verificações

  • Confirme a versão do OCI CLI com o comando: oci -v
  • Verifique se sua máquina consegue resolver o endpoint privado do cluster

Geração do kubeconfig

```bash # Criar diretório para o arquivo kubeconfig mkdir -p $HOME/.kube

# Gerar e baixar o arquivo kubeconfig oci ce cluster create-kubeconfig \ --cluster-id \ --file $HOME/.kube/config \ --region sa-saopaulo-1 \ --token-version 2.0.0 \ --kube-endpoint PRIVATE_ENDPOINT

# Configurar variável de ambiente export KUBECONFIG=$HOME/.kube/config ```

Observação: Para encontrar o OCI ID do cluster, acesse o Console OCI, navegue até "Developer Services" > "Kubernetes Clusters (OKE)", selecione o cluster desejado e o ID será exibido nos detalhes do cluster como "Cluster Id" ou copiável através do botão "Copy" ao lado do identificador.

Figura 2: Console OCI - Detalhes do Cluster HML

Componentes de Infraestrutura Avançada

O cluster OKE-STH-HML conta com componentes avançados para gerenciamento de tráfego, segurança e observabilidade:

Service Mesh com Istio

O cluster utiliza Istio como plataforma de service mesh, oferecendo:

• Gerenciamento de tráfego avançado: Roteamento baseado em conteúdo, canary deployments e testes A/B
• Políticas de segurança: mTLS automático entre serviços, autorização e autenticação
• Rastreamento distribuído: Integração com OpenTelemetry para visibilidade dos fluxos de requisições
• Resiliência: Circuit breakers, retries e timeouts configuráveis para comunicações entre serviços

Os detalhes de instalação, Gateway API, wildcard TLS e papel do lb_publlic_ip estão centralizados em Networking & Service Mesh.

Visualização de Mesh com Kiali

O Kiali fornece uma interface visual para o service mesh Istio:

• Topologia da malha: Visualização gráfica dos serviços e suas conexões
• Health checks: Monitoramento de saúde dos serviços e endpoints
• Análise de tráfego: Visualização de métricas de desempenho e padrões de comunicação
• Validação de configuração: Verificação de erros nas configurações do Istio

O fluxo de publicação, URL, Ingress e autenticação OIDC do Kiali está documentado na página dedicada da nova seção de networking.

Kubernetes Gateway API

O cluster implementa o Gateway API, a próxima geração de APIs de roteamento do Kubernetes que substitui o Ingress tradicional, oferecendo maior flexibilidade e expressividade.

A implementação utiliza os seguintes recursos:

• GatewayClass: Define o tipo de implementação do controlador de Gateway usado
• Gateway: Expõe um ou mais listeners para tráfego de entrada
• HTTPRoute: Define regras de roteamento para tráfego HTTP

O comportamento real do Gateway compartilhado e da integração com ExternalDNS foi movido para a documentação central de networking para evitar duplicação entre HML e NOX.

External Secrets Operator (ESO)

O ESO sincroniza segredos de provedores externos para Kubernetes:

• Integração com Vault: Obtenção segura de credenciais e chaves do HashiCorp Vault
• Rotação automática: Atualização de segredos sem necessidade de redeploy
• Centralização: Gerenciamento de segredos em um local central, distribuído para todos os namespaces necessários

Cluster Autoscaler

O Cluster Autoscaler (versão 9.46.3) gerencia o escalonamento automático de nós do cluster:

• Escalonamento automático: Adiciona ou remove nós baseado na demanda de recursos dos pods
• Node pool dedicado: Executa em um node pool específico (autoscaler) com allow_autoscaler = true
• Integração OKE: Utiliza a API do OCI para gerenciar os node pools do cluster

O ambiente de homologação hospeda versões de pré-produção das aplicações, permitindo testes integrados em condições semelhantes ao ambiente produtivo. As aplicações neste ambiente consomem serviços de:

• Bancos de dados
• APIs externas
• Serviços de armazenamento
• Serviços de mensageria

Conclusão

A arquitetura do cluster OKE-STH-HML proporciona um ambiente robusto para validação de aplicações antes da implantação em produção. O auto-scaling configurado permite que o ambiente se adapte automaticamente às demandas de carga dos testes, otimizando custos ao mesmo tempo que garante performance adequada para os ambientes de teste e homologação.