Domain 5: Migrate Containerized Applications to OCI (10%)
Domain 5 of the 1Z0-1123-25 Oracle Cloud Infrastructure 2025 Migration Architect Professional exam covers migrating containerized workloads to OCI Container Engine for Kubernetes (OKE). At 10% of the exam, expect approximately 5 questions. These questions test practical knowledge of OKE architecture, OCIR registry operations, Kubernetes migration mechanics, and the specific OCI-native features that differentiate OKE from other managed Kubernetes platforms.
1. OCI Container Engine for Kubernetes (OKE) Architecture
OKE is Oracle's fully managed, CNCF-certified Kubernetes service. Oracle manages the control plane (API server, etcd, scheduler, controller manager); you manage or delegate management of worker nodes depending on the node type chosen. (OKE Overview)
Cluster Types: Basic vs Enhanced
This distinction is heavily testable. Understand it cold.
| Feature | Enhanced Cluster | Basic Cluster |
|---|---|---|
| Virtual node pools | Yes | No |
| Self-managed nodes | Yes | No |
| Managed node pools | Yes | Yes |
| Node cycling (auto cordon/drain/replace) | Yes | No |
| Cluster add-on management (enable/disable/version) | Yes | No |
| Workload identity (pod-level IAM policies) | Yes | No |
| Cloud Guard Container Security | Yes | No |
| Can request cluster/node limit increases | Yes | No |
| Financially-backed SLA | Yes | No (SLO only) |
| Upgrade path | N/A | Can upgrade to enhanced |
| Downgrade path | Cannot downgrade to basic | N/A |
| Default when creating via Console | Yes | No |
| Default when creating via CLI/API | No | Yes |
Source: Comparing Enhanced with Basic Clusters
Exam trap: The default cluster type differs by creation method. Console defaults to enhanced; CLI and API default to basic. If a question describes creating a cluster via the API without specifying the type, the answer is a basic cluster.
Exam trap: You cannot downgrade an enhanced cluster to basic. This is a one-way upgrade. If a question asks about reverting from enhanced to basic, the answer is "not possible."
Node Types
OKE supports three node types, each with different management responsibilities:
| Node Type | Who Manages | Key Use Case | Cluster Type Required |
|---|---|---|---|
| Virtual nodes | Oracle (serverless) | Eliminate node management entirely; auto-scaling, patching, upgrades handled by Oracle | Enhanced only |
| Managed nodes | Shared (you choose shape/image, Oracle handles provisioning) | Standard workloads; you control compute shape, OS image, placement | Basic or Enhanced |
| Self-managed nodes | You (full control) | GPU workloads, high-performance cluster networking, custom images | Enhanced only |
Source: OKE Overview
Exam trap: Virtual nodes and self-managed nodes require enhanced clusters. If a question presents a basic cluster and asks about virtual nodes, the answer involves upgrading to enhanced first.
Key limit: Maximum 110 pods per single managed node (Kubernetes-imposed limit).
2. Pod Networking: Flannel vs VCN-Native
The CNI plugin choice is made at cluster creation and cannot be changed afterward. This is a critical architectural decision for migration planning.
| Aspect | Flannel Overlay CNI | VCN-Native Pod Networking CNI |
|---|---|---|
| Pod IP source | Virtual overlay network (not from VCN CIDR) | VCN subnet CIDR (real VCN IPs) |
| Pod reachability | Only from within the cluster | Routable across VCN, peered VCNs, FastConnect, IPSec VPN |
| IP planning | Minimal (large internal /16 CIDR) | Requires careful subnet sizing; risk of IP exhaustion |
| Latency | Baseline | ~25% lower pod-to-pod latency across nodes |
| Network policy enforcement | Via Calico | Via Calico + OCI NSGs applied directly to pods |
| Virtual node support | No | Yes |
| Managed node support | Yes | Yes |
| Self-managed node support | Yes | Yes |
| Default (Console, K8s 1.22+) | No | Yes (since July 2022) |
| Default (CLI/API) | Yes | No |
| Pod density per node | Higher (overlay IPs are unlimited by VCN) | Limited by VNICs and secondary IPs per shape |
Sources: Pod Networking, Flannel CNI, VCN-Native CNI
Exam trap: CNI cannot be changed after cluster creation. If a question describes needing to switch from flannel to VCN-Native, the answer is to create a new cluster and migrate workloads. There is no in-place CNI change.
Exam trap: Flannel does not support virtual nodes. If a question combines virtual nodes with flannel, the configuration is invalid.
When to choose each: Use VCN-Native when pods need to be reachable from outside the cluster (on-premises via FastConnect, other VCNs) or when you need NSG-level security on pods. Use flannel when you need high pod density and do not need direct pod addressability from outside the cluster.
3. Oracle Cloud Infrastructure Registry (OCIR)
OCIR is Oracle's managed, OCI-compliant container registry for storing Docker images, manifest lists (multi-arch), and Helm charts. (OCIR Overview)
Authentication and Image Operations
| Item | Details |
|---|---|
| Registry URL format | <region-key>.ocir.io (e.g., phx.ocir.io, lhr.ocir.io) |
| Username (unfederated) | <tenancy-namespace>/<username> |
| Username (federated/IDCS) | <tenancy-namespace>/oracleidentitycloudservice/<username> |
| Password | OCI Auth Token (not your console password) |
| Image path | <region-key>.ocir.io/<tenancy-namespace>/<repo-name>:<tag> |
| Private access | Via Service Gateway (no internet gateway needed) |
| Repository limit | 500 per region |
| Storage limit | 500 GB per region (increase via support request) |
| Images per repository | 100,000 |
Source: Logging in to OCIR, Preparing for Container Registry
Exam trap: The password for docker login to OCIR is an OCI Auth Token, not your OCI console password or API signing key. Questions about OCIR authentication failures often hinge on this distinction.
Exam trap: The tenancy namespace in the username is the auto-generated Object Storage namespace string, not the tenancy name. These are different values.
Image Security
OCIR integrates with OCI Vulnerability Scanning to automatically scan images for CVEs. Repositories with scanning enabled rescan when new vulnerabilities are published. Images can be signed using master encryption keys from OCI Vault, and OKE enhanced clusters can enforce image verification policies that reject unsigned or incorrectly signed images. (Enforcing Signed Images)
4. Cluster Creation and Networking
Creation Workflows
| Workflow | Network Resources | Control Level | Use Case |
|---|---|---|---|
| Quick Create | Creates new VCN, subnets, security lists, internet/NAT/service gateways | Minimal (defaults) | Proofs of concept, quick starts |
| Custom Create | Uses existing VCN and subnets | Full control over all cluster properties | Production migrations |
Source: Creating Clusters
Quick Create provisions three regional subnets: one for the Kubernetes API endpoint, one for worker nodes, and one public subnet for load balancers. You choose whether the API endpoint and worker node subnets are public or private.
Exam trap: For production migration targets, Custom Create is the correct answer because you need to integrate with existing VCN topology, security lists, and route tables. Quick Create builds throwaway networking.
Load Balancers
OKE provisions OCI load balancers automatically when you create Kubernetes services of type LoadBalancer. Two types are available:
| Type | Layer | Key Annotation |
|---|---|---|
| OCI Load Balancer | Layer 7 (HTTP/HTTPS) | Default (no special annotation) |
| OCI Network Load Balancer | Layer 4 (TCP/UDP) | oci.oraclecloud.com/load-balancer-type: "nlb" |
Source: Configuring Load Balancers
Available load balancer shapes: 100 Mbps, 400 Mbps, 8000 Mbps, and flexible. Ingress controllers (e.g., NGINX Ingress) can run inside the cluster behind an OCI load balancer to handle routing for multiple services.
5. Persistent Storage on OKE
OKE includes CSI drivers for OCI storage services. These are the primary storage options for persistent workloads:
| Storage Type | CSI Provisioner | Storage Class | Access Mode | Use Case |
|---|---|---|---|---|
| OCI Block Volume | blockvolume.csi.oraclecloud.com |
oci-bv |
ReadWriteOnce | Databases, stateful apps (single-node attach) |
| OCI File Storage (NFS) | fss.csi.oraclecloud.com |
Custom (user-defined) | ReadWriteMany | Shared storage across pods/nodes |
| OCI Object Storage | Via S3-compatible or FUSE mount | Custom | ReadWriteMany | Large datasets, backups, archives |
Source: Setting Up Storage for Kubernetes Clusters
Exam trap: Block Volumes are ReadWriteOnce -- they can only attach to a single node at a time. If a question describes shared storage across multiple pods on different nodes, the answer is File Storage Service (FSS), not Block Volumes.
Oracle recommends using the CSI volume plugin over the legacy FlexVolume plugin. New functionality is only added to CSI.
6. Autoscaling
Horizontal Pod Autoscaler (HPA)
Scales the number of pod replicas based on CPU, memory, or custom metrics. Works with both managed and virtual node pools. This is standard Kubernetes HPA functionality running on OKE. (Using the HPA)
Cluster Autoscaler
Automatically adds or removes worker nodes from managed node pools based on pending pod scheduling. When HPA scales pods beyond current node capacity, the Cluster Autoscaler provisions new nodes. When utilization drops, it removes underused nodes. (Using the Cluster Autoscaler)
Exam trap: The Cluster Autoscaler does NOT work with virtual node pools. Virtual nodes scale automatically by design (serverless), so the Cluster Autoscaler is unnecessary and unsupported for them. If a question pairs the Cluster Autoscaler with virtual nodes, the configuration is invalid.
How they work together: HPA increases replicas -> pods become unschedulable -> Cluster Autoscaler adds nodes -> pods schedule. Traffic drops -> HPA reduces replicas -> nodes underutilized -> Cluster Autoscaler removes nodes.
7. Migrating Containerized Workloads to OKE
Migration Phases
| Phase | Activities |
|---|---|
| Assessment | Inventory existing containers, registries, Kubernetes manifests, storage classes, networking configs, external dependencies, and CI/CD pipelines |
| Planning | Select OKE cluster type (enhanced/basic), CNI (flannel/VCN-Native), node type, target VCN topology, storage class mappings, and RBAC strategy |
| Migration | Push images to OCIR, translate Kubernetes manifests (storage classes, annotations, load balancer configs), migrate persistent data, deploy workloads |
| Validation | Verify pod health, service connectivity, persistent volume binding, external access, autoscaling behavior, and monitoring integration |
Velero-Based Migration (EKS/AKS/GKE to OKE)
Velero is the Oracle-documented tool for migrating Kubernetes workloads from other cloud platforms to OKE. It backs up cluster resources and persistent volume data, stores them in OCI Object Storage (using S3-compatible API), and restores to the target OKE cluster. (AKS/EKS to OKE Migration with Velero)
What Velero migrates: Deployments, services, PVCs, secrets, ConfigMaps, and persistent volume data (via filesystem backup).
Critical step -- storage class mapping: Source platforms use different storage class names. You must create a Velero ConfigMap to translate them before restore:
| Source Platform | Source Storage Class | Target (OKE) |
|---|---|---|
| AKS | managed-premium |
oci-bv |
| EKS | gp2, ebs-sc |
oci-bv |
| GKE | standard, premium-rwo |
oci-bv |
Without this ConfigMap, PVCs will not bind and pods will stay in Pending state.
Velero uses OCI Object Storage as the intermediate store via the AWS S3-compatible endpoint: https://<tenancy>.compat.objectstorage.<region>.oraclecloud.com. The --provider aws flag is correct because OCI's S3 compatibility layer handles the protocol.
SWIFT (RackWare) Migration
SWIFT is a commercial migration-as-a-service tool that supports migration from local Kubernetes, OpenShift, EKS, AKS, GKE, and IKS to OKE. It automatically discovers dependencies and associated objects (deployments, PVCs, PVs) and migrates them. (Oracle Blog: SWIFT Migration)
Key Manifest Changes When Migrating to OKE
| What Changes | From (Example) | To (OKE) |
|---|---|---|
| Storage class name | gp2, managed-premium |
oci-bv (Block Volume), custom FSS class |
| Load balancer annotations | AWS ALB/NLB annotations | oci.oraclecloud.com/load-balancer-type, service.beta.kubernetes.io/oci-load-balancer-shape |
| Ingress class | alb, azure/application-gateway |
nginx or OCI-native ingress |
| Container registry | ECR, ACR, GCR | <region>.ocir.io/<namespace>/<repo> |
| IAM/RBAC | AWS IAM roles for service accounts, Azure AD | OCI IAM policies + Kubernetes RBAC; workload identity (enhanced clusters) |
8. OKE Security
Access Control Layers
OKE uses two complementary authorization systems:
- OCI IAM: Controls who can manage OKE resources (create/delete clusters, manage node pools). Uses policies like
Allow group KubeAdmins to manage clusters in compartment X. - Kubernetes RBAC: Controls what authenticated users can do within the cluster (create pods, read secrets). Uses Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings.
The OKE Webhook Token authenticator bridges these: it retrieves OCI IAM group membership and passes it to the Kubernetes RBAC authorizer. (About Access Control and OKE)
Workload Identity (Enhanced Clusters Only)
Workload identity allows individual pods to authenticate to OCI services using IAM policies scoped to the specific combination of cluster, namespace, and service account. This replaces the coarser instance principal approach where all pods on a node share the same identity. (Granting Workloads Access to OCI Resources)
Network Policies
Kubernetes network policies (via Calico) control pod-to-pod communication. With VCN-Native CNI, OCI Network Security Groups (NSGs) can also be applied directly to pod traffic for defense-in-depth.
Key Exam Traps Summary
- CNI is immutable -- cannot change flannel to VCN-Native or vice versa after cluster creation.
- Cluster Autoscaler does not work with virtual nodes -- virtual nodes auto-scale natively.
- Virtual nodes require enhanced clusters -- basic clusters only support managed nodes.
- Console defaults to enhanced cluster; CLI/API defaults to basic.
- OCIR auth uses Auth Tokens, not console passwords or API keys.
- Storage class mapping is mandatory when migrating from EKS/AKS/GKE -- without it, PVCs will not bind.
- Block Volumes are ReadWriteOnce -- use File Storage for ReadWriteMany.
- Image verification policies require enhanced clusters and OCI Vault keys.
- Velero uses the AWS provider plugin to talk to OCI Object Storage via S3-compatible API -- this is correct, not a misconfiguration.
- Workload identity is enhanced-only -- basic clusters use instance principals (all pods on a node share identity).
References
- OKE Overview
- OCIR Overview
- Creating Clusters Using OKE
- Enhanced vs Basic Clusters
- Pod Networking
- Flannel CNI Plugin
- VCN-Native Pod Networking CNI Plugin
- Configuring Load Balancers and Network Load Balancers
- Setting Up Storage for Kubernetes Clusters
- Using the Kubernetes Cluster Autoscaler
- Using the Kubernetes Horizontal Pod Autoscaler
- AKS/EKS to OKE Migration with Velero
- About Access Control and OKE
- Granting Workloads Access to OCI Resources
- Enforcing Signed Images from Registry
- Logging in to OCIR
- SWIFT Migration Tool
- Autoscaler Best Practices
- Storage Best Practices