OCI Kubernetes Engine (OKE) continues to make day-to-day operations simpler and safer. We know that many of you rely on load balancers and network load balancers in your day-to-day operations in OKE. That’s why we released the four load balancer capabilities featured in this blog. These four updates bring you stronger security defaults and steadier endpoints for applications on OKE.  

 Here’s what you can do now:    

  • Set a cluster-level default backend Network Security Group (NSG) and opt into NSG rule management via annotation.
  • Assign a reserved public IP (IPv4 or IPv6) address with a dedicated annotation.  
  • Request specific private IPv4 or IPv6 addresses for Network Load Balancers (NLBs).
  • Specify the compartment in which the load balancer or network load balancer is created.

Let’s look at each update and distill how you might start incorporating them in your OKE deployments.

Cluster-level default backend NSG (governance by default)

You can now define one or more default backend network security groups (NSGs) at the cluster level. When a Kubernetes Service of type LoadBalancer (Service) includes the annotation oci.oraclecloud.com/security-rule-management-mode: “NSG”, OKE programs the rules on the cluster’s default backend NSG(s) and on the load balancer or network load balancer NSG to allow backend traffic. OKE does not attach the cluster’s default backend NSG(s) to the load balancer; it manages the rules, so you don’t have to hardcode backend NSGs in every Service. If a workload needs to use a different NSG for backends, you can override the defaults in that Service’s manifest. Rule management remains limited to the cluster’s default backend NSG(s).

Adopting cluster-level default backend NSG helps prevent configuration drift (and who doesn’t love that?). Setting a security baseline once means every new load balancer created by your Services starts with a known-good posture— because OKE manages the necessary rules on the cluster’s default backend NSG(s) and the load balancer NSG, without per‑Service NSG hardcoding. NSGs work well with infrastructure-as-code, so intent stays clear, auditable, and reusable as environments grow.

Before you begin acting to use this release, take a moment to ensure you have the correct configurations and privileges to follow along and adopt the updates.

  • Check your IAM access: Confirm that OKE is allowed to read and attach Network Security Groups and IP resources (both public and private). If in doubt, review your policies for cluster creation and deployment.
  • Availability and limits: Quotas apply to reserved public IPs and to how many NSGs you can attach to a resource—check these before rollout.

Adopt NSG management in three steps

  1. Create a new backend NSG. Then, associate it with the desired node pools and configure the backend NSG as the default at the cluster level.
  2. In your Service manifests, set the security-rule-management-node annotation to NSG.
  3. For exceptions, specify backend NSGs at the Service level.

Example 1- Without NSG Annotation: Default NSG is Inferred from the Cluster Level

#Example (illustrative only)
apiVersion: v1
kind: Service
metadata:
  name: my-nginx-Service
Labels:
app: nginx
  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

Example 2- With NSG Annotation:  Customers can still use the NSG annotation to override the cluster default

#Example (illustrative only)
apiVersion: v1
kind: Service
metadata:
  name: my-nginx-Service
Labels:
app: nginx
  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

Advice going into adopting NSG management

  • Turning on NSG mode changes how OKE manages the necessary rule on the cluster’s default backend NSG(s) and on the load balancer. Try it in a staging cluster first, confirm traffic still flows as expected, and then roll it into production with a short maintenance window or a blue/green cutover.
  • Make sure the cluster identity can read and attach the NSGs you plan to use; missing IAM access is the most common setup hiccup.
Where does this fit with Kubernetes networking on OCI?
Kubernetes NetworkPolicies are great for shaping pod to pod traffic inside the cluster. Application teams use them to say which pods can talk on which ports.  The cluster‑level default backend NSG feature operates at the OCI network layer. When a Service of type LoadBalancer opts into NSG mode, OKE manages the necessary rules in two places: on the load balancer’s NSG and on the cluster’s default backend NSG(s), enabling the required backend flows. OKE does not attach the cluster’s default backend NSG(s) to the load balancer. Use both layers for least privilege: NetworkPolicies inside the cluster, and NSG rules at the edge before traffic reaches workloads.

Reserved public IPs via annotation (predictable public endpoints)

You can now assign a reserved public (IPv4 or IPv6)  to an OKE‑created Load Balancer or Network Load Balancer by adding the oci.oraclecloud.com/reserved-ips annotation to your Service. This keeps IP selection alongside your other OKE annotations and is the recommended way to express this intent going forward. The older spec.loadBalancerIP still works today but use the annotation for new and updated manifests.

A reserved public IP turns a moving target into a stable endpoint. When the load balancer is recreated, the address stays the same—avoiding repeated firewall updates, partner allow‑list changes, and DNS churn. Making the choice explicit in one annotation also keeps manifests readable and ownership clear in code review, which helps rollouts and rollbacks move faster.

How to adopt Reserved public IPs (IPv4 or IPv6)  in three steps

  1. Start by choosing the address. Decide which reserved public IP you want to use and ensure it’s already reserved and taken out of the dynamic pool.
  2. Next, set the annotation. Add the oci.oraclecloud.com/reserved-ips annotation to your Kubernetes Service of type LoadBalancer and provide the IP address value. 
  3. Finally, apply and verify. Deploy the manifest and verify the load balancer or network load balancer comes up with the expected IP.  

Example – Reserved IP Annotation

#Example (illustrative only)
apiVersion: v1
kind: Service
metadata:
  name: my-lb-Service
  annotations:
    oci.oraclecloud.com/reserved-ips: “reserved_ipv4_address”
    oci.oraclecloud.com/Load-balancer-type: “lb”
spec:
  type: LoadBalancer
  ports:
    port: 80
    targetport: 80
  selector:
    app: my-api
    targetport: 80
  selector:
    app: my-api

Advice for adopting reserved public IP

  • When moving from spec.LoadBalancerIP to the reserved-ips annotation, the load balancer’s IP assignment behavior can change. Test in non-production and plan a brief cutover for production.
  • Provide an IP address value in the reserved-ips annotation. IP identifiers/OCIDs are not supported for reserved-ips, so supplying anything other than an IP address will fail.  
  • Reserve the IPs you plan to use ahead of time (IPv4 or IPv6), so they are taken out of the dynamic pool and remain available for assignment. Keep a small, preapproved pool per environment to speed roll-forward and rollback.
  • If a non-reserved IP is already in use by another resource, your IP assignment will fail. Use reserved IPs to avoid contention and to ensure the address persists across redeployments.

Specific private IPv4/IPv6 for NLBs (predictable private endpoints)

For Network Load Balancers (NLBs) created by a Service, you can request an exact private IPv4 address, an IPv6 address, or both. Requests depend on two conditions;  the target subnet supports the address family (IPv4‑only, IPv6‑only, or dual stack), and the IP is not allocated to any other resources. Requesting an exact, private address pins internal endpoints to known addresses during provisioning instead of accepting the next free IP.

Being able to assign specific private IPv4 and IPv6 addresses to NLBs gives you predictable internal connectivity. You can pin an NLB to known addresses that match your routing, peering, and security policies, or use distinct addresses for blue/green to flip traffic without touching downstream dependencies. If your organization is adopting IPv6, you can provision dual-stack endpoints from day one and migrate clients on your own timeline, all while keeping routes and rules stable.

How to adopt in specific private IPs for NLBs in three steps

  1. Start by checking the subnet. Confirm the subnet is IPv4, IPv6, or dual‑stack as needed, and that the specific address(es) you want are available.
  2. Next, it’s time to specify the address. Provide the exact set of private IPv4 and/or IPv6 in your Service configuration using the documented fields/annotation for NLBs.
  3. Finally, apply and verify the new settings. You can deploy the Service and confirm the NLB was created with the expected address(es).

What to expect during rollout

  • Plan for replacement when changing addresses. Assigning a different specific private IP can result in a new NLB being provisioned. If your app is sensitive to interruptions, run a parallel Service, validate health checks, and then switch traffic.
  • Validate end‑to‑end paths. After assignment, confirm health checks, route tables, and NSG rules still allow intended traffic—especially for IPv6, where egress paths and gateways may differ.
  • Manage address availability. If the requested private IP isn’t available in the subnet (or IPv6 isn’t enabled), provisioning will fail. You should choose an address that’s free in the target subnet CIDR and keep an alternate address plan per environment to avoid delays.

Specify the compartment for load balancers and NLBs
You can direct OKE to create the load balancer or network load balancer in a specific compartment by adding the oci.oraclecloud.com/compartment-id annotation to a Kubernetes Service of type LoadBalancer. By default, OKE creates the resource in the same compartment as the cluster.

Example – Specify the Load Balancer Compartment Annotation

#Example (illustrative only)
apiVersion: v1
kind: Service
metadata:
  name: my-nginx-Service
  Labels:
    app: nginx
  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


If you’re new to OCI, compartments are how you organize and isolate cloud resources in OCI. They’re tenancy‑wide (available in every subscribed region) and form the backbone for access control, audit, and operational ownership. Placing load balancers and NLBs in the right compartment helps you:

  • Enforce least‑privilege access. Policies are written against compartments, so you can grant only the teams who own an application the rights to view or change its load balancers—without opening the entire cluster’s resources.
  • Align ownership and ops. Network, platform, and app teams can split duties cleanly: for example, keep clusters in a platform compartment while creating load balancers in an application or environment compartment that the app team controls.
  • Improve visibility and governance. The Console organizes views by compartment, making it easier for operators and auditors to find the right resources quickly. You can also associate compartments with security zones for additional guardrails.
  • Support cost tracking and segmentation. Many organizations use compartment boundaries (alongside tags) to separate development, staging, and production, or to align resources to business units for reporting.
  • Keep multi‑region management sane. Because compartments span regions, you can get a cross‑region view of load balancers within a compartment using tenancy explorer tools.

Advice on how to adopt Containers for load balancers and NLB in OKE

  • When creating a new load balancer or network load balancer, choose the target compartment. Confirm it aligns with your ownership model (environment, app, or business unit) and that it’s the right place for network resources.
  • For new and existing load balancers and network load balancers,  confirm they are created in the intended compartment and that operators with access to that compartment can see and manage them as expected.
  • Be deliberate about your container selection. OKE does not support the moving of a load balancer or network load balancer between compartments after it has been created.

Resources