Creating an Oracle Kubernetes Engine (OKE) cluster requires a balance between deployment speed and architectural precision. Whether you are a tenancy administrator or a DevOps engineer with specific policy permissions, OCI offers multiple paths to get your environment live.
In this guide, we will explore the different creation workflows and dive deep into the networking “bedrock” required for a secure, custom deployment.
Part 1: Choosing Your Deployment Workflow
Oracle provides two primary paths in the console, plus automated options for power users.
1. The Quick Create Workflow
Designed for swift deployment, this method gets a cluster running with just a few clicks.
- Automatic Provisioning: It creates the VCN, regional subnets (API, workers, and load balancers), and all necessary gateways automatically.
- Simplicity: Best for testing or rapid prototyping. You only need to decide if your API and nodes should be public or private.
2. The Custom Create Workflow
This workflow provides maximum control and is the standard for production environments.
- Granular Control: Tailor encryption, security rules, and existing network resources.
- The “Node-Pool Free” Strategy: You can create a cluster without node pools initially. This is a best practice if you plan to install Calico or other network policy providers first, as it avoids the need to recreate pods later.
3. Automation: CLI, API, and Terraform
For repeatable infrastructure, you can bypass the console:
- CLI & API: Use the OCI Command Line or SDKs (Python, Java, Go) to script your deployments.
- Terraform: Using Oracle’s GitHub-hosted Terraform modules makes setting up an OKE cluster a “breeze,” allowing for version-controlled Infrastructure as Code (IaC).
Part 2: The Networking Bedrock (Custom Setup)
If you choose the Custom Create path, you must manually configure several key network resources to ensure a smooth deployment.
VCN and Subnet Configuration
Your Virtual Cloud Network (VCN) is the foundation. It must have a CIDR block (like 10.0.0.0/16) large enough to accommodate the API endpoint, worker nodes, pods, and load balancers.
Recommended Subnet Layout:
- Kubernetes API Subnet: For control plane communication.
- Worker Node Subnet: Where your compute power resides.
- Pod Subnet: Required if using the OCI VCN-native pod networking CNI.
- Load Balancer Subnet: Usually a public regional subnet for external traffic.
Best Practice: Use Regional Subnets rather than AD-specific ones to simplify failover across Availability Domains.
Gateway and Routing Logic
The choice between public and private subnets dictates your gateway requirements:
- Internet Gateway (IGW): Essential for public subnets (API, Workers, or LBs) to communicate with the internet. Set
0.0.0.0/0→ IGW. - NAT Gateway: Required for private subnets so they can reach the internet for updates without being exposed to inbound traffic. Set
0.0.0.0/0→ NAT Gateway. - Service Gateway: Mandatory for private subnets to access Oracle Services (like Container Registry) without using the public internet.
DHCP and DNS
For your VCN, ensure DNS Resolution is enabled. The default DHCP options (Internet and VCN Resolver) are perfectly suited for OKE, ensuring the cluster can resolve names efficiently.
Part 3: Security Rules and Traffic Control
Security is enforced via Network Security Groups (NSGs) or Security Lists. NSGs are the recommended approach as they provide more granular control at the resource level.
- Rule Application: If you use both NSGs and Security Lists, OCI applies a union of all rules.
- Component Specifics: The API endpoint, worker nodes, and pods all have distinct ingress/egress requirements.
- Reference: Because these rules are extensive, always consult the official Oracle documentation under “Network Resource Configuration for Cluster Creation and Deployment” for the latest port requirements.
Conclusion
Whether you need a sandbox in minutes via Quick Create or a high-security enterprise environment via Custom Create, understanding the interplay between gateways, route tables, and subnets is key. By following the “Node-Pool Free” installation for network providers and utilizing regional subnets, you ensure a smoother, more efficient OKE deployment.
Recent Comments