Does the IBM Cloud Kubernetes Service Ingress annotation for public IP type work identically in local kind and production clusters?

No, the service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: public annotation does not produce identical behavior in a local kind cluster and an IBM Cloud Kubernetes Service (IKS) production cluster.

Likely explanation

• Cloud provider scope: IKS clusters use IBM Cloud infrastructure to provision load‑balancer IPs; the annotation signals the IBM Cloud Ingress controller to request a public IP from the VPC pool. A local kind cluster has no cloud provider, so the annotation is ignored or treated as a no‑op unless a local shim (e.g., Metallb) is installed.
• Annotation processing: In IKS the Ingress controller translates the annotation into IBM Cloud API calls (e.g., CreateLoadBalancer). In kind, without a cloud‑provider integration, those calls cannot be made, leaving the service in a pending state or falling back to node‑port.
• IAM and resource‑group boundaries: Successful IP allocation in IKS requires the service account bound to the Ingress controller to hold the Container Service Operator role scoped to the cluster’s resource group and VPC. Missing or mis‑scoped permissions cause the controller to stall the request.

Confirmed facts

1. The IBM Cloud ALB provisions public IPs exclusively through IBM Cloud infrastructure; there is no automatic fallback to internal IP or node‑port unless explicitly configured.
2. In a kind environment, a service of type LoadBalancer without an external load‑balancer shim remains pending or receives a node‑port, and IBM‑specific annotations are not processed.
3. Events on the Ingress or service resource in IKS will show IBM Cloud API activity (e.g., CreateLoadBalancer) when the annotation is valid; in kind, events reference the local shim or show no cloud‑provider action.

Steps to diagnose and resolve in IKS

1. Verify the annotation key matches the IKS runtime version; check the Ingress controller logs for any deprecation warnings.
2. Ensure the service account used by the Ingress controller has the Container Service Operator role scoped to the cluster’s resource group and VPC.
3. Confirm the worker‑node subnets have a public gateway enabled and that the VPC allows outbound access to IBM Cloud load‑balancer APIs.
4. If you are unsure, verify that the service account bound to the Ingress controller has the Container Service Operator role scoped to the cluster's resource group and VPC.