Permit-API Pods must be reachable as native addresses from a peered VCN that already routes the application subnet. Which OKE network type gives pods routable VCN IPs?
Select an answer to reveal the explanation.
Short Explanation
VCN-native puts each Pod on a pod subnet with a real VCN IP—reachable the same way other VCN addresses are, including from peered VCNs. That is how the app attaches, not a request to redesign hub-and-spoke CIDRs.
Full Explanation
VCN-native pod networking attaches Pods to a pod subnet so each Pod receives a routable VCN IP. That is how permit-API Pods become reachable as native addresses from a peered VCN that already routes the application path—pod IPs participate in VCN routing and security lists/NSGs like other VCN addresses rather than living only inside an overlay. Flannel overlay exclusively keeps pod IPs cluster-internal via encapsulation; those addresses are not generally advertised as native IPs into every peered VCN. Overlay is the wrong choice when the requirement is native VCN reachability from a peer. Putting a public LoadBalancer Service on each Pod IP is not how you replace CNI addressing. LoadBalancer Services front stable Service VIPs; they do not make every Pod IP a VCN-native address and do not eliminate the need to choose the correct cluster network type. HostNetwork on every Pod forces sharing the host network namespace and is not a substitute for VCN-native CNI design. It does not mean kubelet replaces the VCN with Docker bridge addressing as a supported multi-tenant pod networking model. Exam caveat: VCN-native requires adequately sized pod subnets and correct route table/NSG rules for peered traffic—choosing VCN-native without routing the pod CIDR still yields unreachable Pods. Operational check: deploy a permit Pod, note its Pod IP in the pod subnet range, and verify connectivity from a test endpoint in the peered VCN using NSG-allowed ports before cutting over production traffic.