Creating OKE Network Resources
Some network resources used by Kubernetes Engine (OKE) On a Roving Edge device must be configured in specific ways.
The resource definitions in the following sections create a working example set of network resources for workload clusters. Use this configuration as a guide when you create these resources. You can change the values of properties such as CIDR blocks and IP addresses. Don't change the values of properties such as the network protocol, the stateful setting, or the private/public setting.
For subnets used to create or run an OKE cluster (including node pool, load balancer, and pod subnets), don’t configure custom DNS servers in the subnet’s DHCP options. OKE depends on the default DNS resolver for reliable name resolution to required Kubernetes and platform services (including the on-rack region registry used to pull images during cluster and node provisioning). Using custom DHCP resolvers can cause cluster provisioning failures and ongoing node or add-on connectivity issues. If you need custom name resolution, use supported OCI DNS capabilities (for example, Private DNS) without overriding the subnet DHCP DNS settings.
See Workload Cluster Network Ports (Flannel Overlay) and Workload Cluster Network Ports (VCN-Native Pod) for specific ports that must be open for specific purposes.
If the appliance administration network is enabled, ask your system administrator to verify that the administration network and the data center network are configured to allow traffic to and from the cluster control plane.
You can create network resources for two networking types:
Public and Private Clusters summarizes which network resources you need to create a public cluster and which network resources you need to create a private cluster.
Pod Networking
The Kubernetes networking model assumes containers (pods) have unique and routable IP addresses within a cluster. In the Kubernetes networking model, pods use those IP addresses to communicate with other pods on the same node in a cluster or on a different node, with pods on other clusters, with the cluster's control plane nodes, with other services (such as storage services), and with the internet.
By default, pods accept traffic from any source. To enhance cluster security, control access to and from pods using security rules defined as part of network security groups (recommended) or security lists. The security rules apply to all pods in all the worker nodes connected to the pod subnet specified for a node pool. See Controlling Traffic with Network Security Groups and Controlling Traffic with Security Lists.