Design the Components of Your Topology

Design the Network

Decide the traffic-access requirements of your containerized applications, and determine the networking resources that you need.

Consider the scaling requirements of your workload when you decide the network size; that is the CIDR ranges for the VCN and the subnets.

Attach the worker nodes to a distinct subnet within the VCN. Use separate subnets for the other resources, such as the load balancer nodes, the bastion host, and the admin host.

The recommended approach is to attach the Kubernetes worker nodes to a private subnet. Each worker node has only a private IP address. Use a load balancer (internal or public) to distribute traffic to the worker nodes. To enable the worker nodes to initiate access to hosts in the public internet, use a NAT gateway.

If you intend to create services of the type NodePort, then attach the Kubernetes worker nodes to a public subnet. Traffic to and from the nodes is routed through the internet gateway. Each worker node has a public IP address and a private address. You must explicitly configure security rules to allow access to the worker nodes from the public internet.

You can use a service gateway to route any traffic from the worker nodes to the other Oracle Cloud services (such as Oracle Cloud Infrastructure Object Storage) within the region.

Restrict Administrative Access

Consider using a bastion host and an admin host to access and manage your topology in the cloud.

To protect the Kubernetes worker nodes against unauthorized access from outside the cloud, isolate them in a subnet that doesn't have a route to and from the public internet.

Deploy a bastion host and use it as the sole entry point for SSH connections to the other compute instances in the topology, including to the worker nodes. For enhanced security, consider allowing SSH access to the bastion host to only a known set of IP addresses outside the cloud.

For administrative operations on your Kubernetes topology in the cloud, consider creating an admin host in the cloud, with the required tools such as kubectl and the Oracle Cloud Infrastructure CLI installed on it. Use the bastion host as a jump server for SSH connections to the admin host.

Design the Node Pools

A node pool is a group of identically configured compute instances within a Kubernetes cluster. Node pools enable you to deploy and manage applications with different resource requirements efficiently. You can, for example, create a separate node pool for each containerized application or service.

Decide the number of node pools to be created and the number of worker nodes in each pool based on the number and size of your containerized workloads. A minimum of three worker nodes are created in each pool. All the worker nodes within a given pool are created using the same shape, which you specify.

Ensure High Availability

Ensure that your containerized workloads in the cloud are not affected by any outages in the data center.

Oracle Cloud Infrastructure regions contain one or more multiple fault-tolerant availability domains. Availability domains don't share infrastructure such as power, cooling, and the internal network. A failure in one availability domain is unlikely to affect the others within the same region. In a region that contains multiple availability domains, the worker nodes are distributed across the availability domains. You can attach the nodes to regional subnets, which span all the availability domains.

Every availability domain contains three fault domains, each an isolated grouping of hardware and infrastructure. A hardware failure or maintenance event that affects one fault domain does not affect the resources in the other fault domains. In regions that have a single availability domain, the worker nodes are distributed across the fault domains in the data center.