Enable External Registration of IKS Workers as VPC NLB Pool Members

## Summary

VPC Network Load Balancers (NLB) currently only accept pool members identified by VPC instance `id`, `href`, or `crn`. IKS worker nodes are not exposed as standard VPC instances through the VPC Instance API, making it impossible to register them as NLB backends via the VPC API, CLI, or SDK. The only path is through the Kubernetes Cloud Controller Manager (CCM), which limits integration with external load balancer controllers.

This issue does not affect Application Load Balancers (ALB), which support IP-based member targets (`target.address`) and can therefore accept IKS workers directly.

## Problem Statement

When using IBM Kubernetes Service (IKS) with VPC Gen2, worker nodes are managed by the IKS control plane and are **not visible** through the VPC Instance API (`GET /v1/instances`). Combined with NLB's target type restrictions, this creates a dead end:

- Adding an IKS worker to an NLB pool via `target.id` fails with `member_not_found`, because the worker ID is not a valid VPC instance ID.

- Adding an IKS worker to an NLB pool via `target.address` (IP) fails with `member_invalid_nlb_target`, because NLB does not support IP-based member targets.

- The only way to bind IKS workers to an NLB is through the Kubernetes Cloud Controller Manager (CCM) by creating a `type: LoadBalancer` Service.

The root cause is a combination of two constraints:

1. **NLB side**: NLB only accepts VPC instance references (`id`/`href`/`crn`) as member targets — it does not support raw IP addresses like ALB does.

2. **IKS side**: IKS worker nodes are not registered in the VPC Instance API, so they have no valid instance `id`/`href`/`crn` that NLB can resolve.

Either constraint alone would not be a problem. Together they block all external registration paths.

## Impact

This limitation affects any deployment model where an external controller (outside of CCM) manages load balancer configuration programmatically. Specifically:

- **UDP services on IKS are blocked** from using custom ingress controllers that manage pre-created load balancers and bind backends via the VPC SDK. Since ALB does not support UDP, NLB is the only option for UDP traffic, but NLB cannot be managed externally with IKS workers.

- **TCP services are unaffected**, as they can use ALB which supports IP-based member targets.

- **Advanced load balancing features** provided by custom controllers — such as port pooling, multi-backend sharing on a single LB, and custom health check logic — become unavailable for UDP workloads on IKS. Users are forced to fall back to CCM-managed LoadBalancer Services, which offer less flexibility.

- **Workaround requires self-managed clusters**: To use NLB with external controllers, users must deploy self-managed Kubernetes clusters on standard VPC VSIs instead of using IKS, losing the operational benefits of a managed Kubernetes service.

## Proposed Solutions

Either of the following approaches would resolve the issue. They are independent — implementing one is sufficient.

### Option A: NLB supports IP address as member target (NLB-side fix)

Add `target.address` (IP address) as a valid member target type for VPC NLB, consistent with ALB behavior.

**API example:**

```json

POST /v1/load_balancers/{nlb_id}/pools/{pool_id}/members

{

"port": 80,

"target": {

"address": "10.240.0.17"

}

}

```

**CLI example:**

```bash

ibmcloud is load-balancer-pool-member-create <NLB_ID> <POOL_ID> 80 10.240.0.17

```

**Pros:** Achieves full parity with ALB; benefits all NLB users, not just IKS.

**Cons:** May require changes to NLB's internal forwarding path.

### Option B: Expose IKS worker nodes as VPC instances (IKS-side fix)

Make IKS worker nodes visible through the VPC Instance API (`GET /v1/instances`) so that their instance `id`/`href`/`crn` can be used as valid NLB member targets.

**API example:**

```json

POST /v1/load_balancers/{nlb_id}/pools/{pool_id}/members

{

"port": 80,

"target": {

"id": "<iks-worker-vpc-instance-id>"

}

}

```

**CLI example:**

```bash

ibmcloud is load-balancer-pool-member-create <NLB_ID> <POOL_ID> 80 <IKS_WORKER_INSTANCE_ID> --target-type instance

```

**Pros:** No changes needed to NLB; works with existing NLB API contract.

**Cons:** May expose IKS-managed infrastructure details that were intentionally abstracted; requires coordination between IKS and VPC teams.

## Verification Evidence

The following tests were performed against a live IKS cluster (`bcs-test`, region `us-south`) to confirm the current limitation:

| Test | LB Type | Target | Result |

|------|---------|--------|--------|

| `target.id` = IKS worker ID | NLB | instance | `member_not_found` |

| `target.address` = worker private IP | NLB | IP | `member_invalid_nlb_target` |

| `target.address` = worker private IP | ALB | IP | **Success** |

| `ibmcloud is instances` | — | — | 0 instances (IKS workers not listed) |

## Business Justification

- Unblocks UDP service exposure on IKS through custom ingress controllers

- Eliminates the need to maintain separate self-managed clusters solely for NLB compatibility

- Enables feature parity between NLB and ALB (Option A) or between IKS and self-managed clusters (Option B)

- Aligns with hybrid and multi-cluster architectures where external controllers manage load balancer backends across heterogeneous compute targets