Evolução no OKE: Governança, IPs previsíveis e nova gestão de Load Balancers na OCI

O OCI Kubernetes Engine (OKE) continua a evoluir para tornar as operações do dia a dia mais simples e seguras. Para empresas brasileiras que operam workloads críticos na Oracle Cloud Infrastructure (OCI), o gerenciamento de rede e exposição de serviços é um ponto de atenção constante.

A Oracle lançou recentemente quatro novos recursos para Load Balancers e Network Load Balancers (NLB) que trazem defaults de segurança mais robustos e endpoints mais estáveis.

Aqui está o que muda na prática:

• Definição de Network Security Group (NSG) padrão para o backend no nível do cluster e gestão via annotation.
• Atribuição de IP público reservado (IPv4 ou IPv6) via annotation dedicada.
• Solicitação de endereços IPv4 ou IPv6 privados específicos para Network Load Balancers (NLBs).
• Especificação do compartment onde o Load Balancer ou NLB será provisionado.

Vamos analisar como esses updates impactam sua estratégia de infraestrutura e como incorporá-los aos seus deployments.

NSG padrão no nível do cluster (Governança por Default)

Agora é possível definir um ou mais NSGs de backend padrão diretamente no nível do cluster. Quando um Service Kubernetes do tipo LoadBalancer inclui a annotation oci.oraclecloud.com/security-rule-management-mode: "NSG", o OKE programa as regras automaticamente.

Isso elimina a necessidade de codificar manualmente os NSGs de backend em cada manifesto de Service. O OKE gerencia as regras para permitir o tráfego entre o load balancer e os nodes do cluster, garantindo que o baseline de segurança seja mantido sem intervenção manual repetitiva em cada novo serviço exposto.

Adotar esse modelo reduz o configuration drift. Para times de DevOps no Brasil, isso significa menos erros de abertura de portas em firewall e uma postura de segurança auditável via Infrastructure-as-Code (IaC).

Como adotar em 3 passos:

1. Crie um novo NSG de backend, associe-o aos Node Pools e configure-o como padrão no cluster.
2. Nos manifestos de Service, utilize a annotation security-rule-management-mode: NSG.
3. Para casos de exceção, você ainda pode sobrescrever o NSG no nível do Service.

Exemplo 1 – Sem override (infere o padrão do cluster):

CopiarapiVersion: v1
kind: Service
metadata:
  name: my-nginx-service
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/security-rule-management-mode: "NSG"
spec:
  type: LoadBalancer
  ports:
    - port: 443
  selector:
    app: api

Exemplo 2 – Com override de NSG específico:

CopiarapiVersion: v1
kind: Service
metadata:
  name: my-nginx-service
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/security-rule-management-mode: "NSG"
    oci.oraclecloud.com/oci-backend-network-security-group: <nsg-ocid>
spec:
  type: LoadBalancer
  ports:
    - port: 443
  selector:
    app: api

IPs Públicos Reservados via Annotation

Até então, a definição de IPs estáticos seguia padrões que podiam variar. Agora, você pode atribuir um IP público reservado (IPv4 ou IPv6) adicionando a annotation oci.oraclecloud.com/reserved-ips. Isso mantém a seleção do IP integrada às demais configurações do OKE.

Para empresas que possuem parceiros com allow-lists rígidas ou integrações de VPN/DNS que não toleram mudanças de IP, essa funcionalidade é vital. Mesmo que o Load Balancer seja recriado, o endpoint permanece o mesmo, evitando downtime operacional por atualizações de DNS ou firewall externo.

Dica técnica: IPs reservados devem ser criados previamente no painel da OCI ou via Terraform para estarem disponíveis no pool antes da aplicação do manifesto.

Endpoints Privados Previsíveis para NLBs

Para cenários de conectividade interna (Leste-Oeste) entre VCNs ou via FastConnect, agora você pode solicitar um endereço IPv4 ou IPv6 privado exato para o seu NLB.

Isso permite que você faça o "pinning" de endpoints internos. Em arquiteturas complexas de microserviços, ter um IP privado fixo facilita o roteamento e o peering entre subnets, permitindo inclusive estratégias de Blue/Green onde o tráfego é virado apenas alterando o apontamento interno, mantendo as regras de segurança intactas.

Especificação de Compartment para Isolamento

Por padrão, o OKE cria recursos de rede no mesmo compartment do cluster. Com a nova annotation oci.oraclecloud.com/compartment-id, você pode direcionar o Load Balancer para um compartment específico.

Essa é uma excelente notícia para a governança de FinOps e SecOps. Você pode separar os custos de tráfego de rede por unidade de negócio ou aplicar políticas de IAM restritivas, onde o time de Network pode gerenciar os Load Balancers em um compartment isolado, enquanto os desenvolvedores gerenciam as workloads no compartment do cluster.

Exemplo de uso de Compartment:

CopiarapiVersion: v1
kind: Service
metadata:
  name: my-nginx-service
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/compartment-id: ocid1.compartment.oc1..aaaa_______t6q
spec:
  type: LoadBalancer
  ports:
    - port: 80
  selector:
    app: nginx

Conclusão e Próximos Passos

Essas mudanças refletem a maturidade do OKE em lidar com requisitos Enterprise. A transição para o uso de NSGs ao invés de Security Lists e a capacidade de fixar IPs (públicos e privados) são passos essenciais para qualquer operação que busca escala e estabilidade na nuvem da Oracle.

Ao implementar essas novidades, recomendamos testar primeiro em ambientes de staging, especialmente a mudança para o modo NSG, que altera a forma como as regras de tráfego são injetadas na infraestrutura de rede da OCI.

---

Artigo originalmente publicado por Jordan Spore em cloud-infrastructure.